<zmatt>
means there's an uncleared error in the uart, probably an overrun
<mattb0ne>
ok
<mattb0ne>
is there a way to flush the uart
<mattb0ne>
on start up
<zmatt>
simplest way is by just reinitializing it after you've sent the reset command (or stop auto-transmit command, whatever you're using) to the thing
<mattb0ne>
ok
<mattb0ne>
brb
mattb0ne has quit [Read error: Connection reset by peer]
mattb0ne has joined #beagle
vagrantc has joined #beagle
mattb0ne has quit [Ping timeout: 272 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
starblue1 has joined #beagle
starblue has quit [Ping timeout: 244 seconds]
Shadyman has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 268 seconds]
mastermind_ has joined #beagle
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #beagle
<set_>
10:00!
Guest64 has joined #beagle
Guest64 is now known as zero88
mastermind_ has quit [Ping timeout: 244 seconds]
m-atoms has quit [Ping timeout: 250 seconds]
<set_>
Making automatic locks w/ the MotorCape!
vagrantc has quit [Quit: leaving]
russ_ is now known as russ
waldo323_ has joined #beagle
waldo323 has quit [Ping timeout: 244 seconds]
zero88 has quit [Ping timeout: 250 seconds]
rob_w has joined #beagle
ikarso has joined #beagle
LetoThe2nd has joined #beagle
philenotfound has joined #beagle
otisolsen70 has joined #beagle
<otisolsen70>
Where can I see what the meaning of the blue blinking LEDs are? (assuming it has not been changed from the defaults)
<otisolsen70>
zmatt, and if they all blink in tandem?
alan_o has quit [Ping timeout: 244 seconds]
<zmatt>
that's normally only used by the flasher (to indicate failure)
<zmatt>
most commonly happens when people try to reflash their beaglebone but messed things up (e.g. their sd card isn't bootable (either because it's broken or because the flasher image has been written to it incorrectly) or they're trying to reflash an old beaglebone black pre-rev-C (with only 2 GB of eMMC) with an image that doesn't fit)
<zmatt>
*their sd card isn't bootable and they managed to modify eMMC to attempt to reflash itself
<zmatt>
can you give more context on what you're doing exactly?
alan_o has joined #beagle
<zmatt>
(sorry for the slow response, my attention is mostly elsewhere at the moment)
xet7 has quit [Quit: Leaving]
Guest6449 has joined #beagle
Guest6449 is now known as zero88
mastermind_ has joined #beagle
<otisolsen70>
zmatt, that would make sense... I have dd'ed the image onto an microsd card and put it into the sd card reader of the bbg. Then I boot it up. But it just starts flashing. What am I doing wrong?
<zmatt>
which image?
<otisolsen70>
zmatt, this is a debian buster image
<zmatt>
no, which image _exactly_? (full filename preferably)
<otisolsen70>
zmatt, it is a custom image. I changed it and thus made the filename myself.
<otisolsen70>
zmatt, sorry I am a total beginner regarding beagleboards. So I am not too familiar with the terminology. What does flasher mean here?
<zmatt>
just to clarify, what's the progression of led activity?
<otisolsen70>
zmatt, right now they are all lit up constantly.
<otisolsen70>
A few minutes ago they were sweeping from side to side. Previoysly, they ware all blinking in tandem.
<otisolsen70>
So I have seen these three states.
<zmatt>
a flasher is an sd card image configured to boot into the eMMC flasher, which will reflash eMMC
<otisolsen70>
Then after yet more time, they just turn off completely. I think the BBG just powers off.
<zmatt>
sweeping side to side is the flasher in operation
<zmatt>
all leds on followed by poweroff is flasher completion
<otisolsen70>
zmatt, oh. So does that mean I need to take out the mmc and then just boot it up?
<otisolsen70>
I was not aware that it would transfer the image ONTO the bbg. Is that what you are saying it is doing?
<zmatt>
*take out the sd card
<otisolsen70>
I guess that makes sense...
<zmatt>
that's what the behaviour you're describing is suggesting it's doing yes
<zmatt>
the only oddity is all leds flashing together, which indicates a flasher failure
<otisolsen70>
Not it blinks more "organically" in what looks like disk activity, etc.
xet7 has joined #beagle
<zmatt>
(I'm not aware of any condition that could lead to flasher failure that would resolve by retrying, the usual reason is the sd card image not fitting on eMMC)
<otisolsen70>
zmatt, yeah! Now it actually booted up!
<otisolsen70>
Wow. I spent way too long on this....
<otisolsen70>
zmatt, thanks a lot!
<zmatt>
btw, generally speaking it's a good idea to verify the contents of an sd card after writing an image to it, or writing the sd card using a tool that will automatically do so for you (like Etcher).
<zmatt>
sd cards are not always reliable, and corruption occurring on the sd card can result in the flashed system being subtly broken
<otisolsen70>
zmatt, ok. I typically just write to the sd card and then run "sync". Then I think it should be ok?
<zmatt>
that doesn't verify the contents in any way
<otisolsen70>
zmatt, of course, I could read back the sd card into sha256sum and compare with the image sha256sum
<zmatt>
that's the manual way yes, be sure to read the correct number of blocks
<zmatt>
and that you're not reading it from disk cache
<otisolsen70>
zmatt, yeah. So will I brick the bbg if I put a corrupt image on it?
<zmatt>
(but that's usually not a problem since the image is almost certainly much bigger than the disk cache)
<zmatt>
no
<zmatt>
it's not possible to brick a beaglebone by flashing a broken image, you can always just reflash it again (worst case if you break the bootloader in a weird way you may need to hold the S2 button during power-up to bypass the bootloader on eMMC)
<otisolsen70>
zmatt, ok. Good to know
rob_w has quit [Quit: Leaving]
xet7 has quit [Remote host closed the connection]
thinkfat has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
tigerxyz has joined #beagle
<tigerxyz>
Hi, GoodMorning: How to generate and apply patches for kernel building?
<zmatt>
if you have a patch that cleanly applies then I suggest saving that in a new directory patches/local/ and adding dir 'local' to patch.sh; if you then run ./build_deb.sh you should get a deb-packaged kernel with the patch
<zmatt>
(like I say in line 11, it's a good idea to configure a custom version suffix for your custom kernel)
<zmatt>
yeah don't do that, that will just make your life much harder
<zmatt>
using the build repo makes it trivially easy to maintain a custom patchset, and the build script takes care of the entire process with ready-to-install debian packages as end product
<tigerxyz>
I was following Robert's instructions, using his building scripts.
<zmatt>
so it's not in it, you just put it in it yourself
<tigerxyz>
I was told by him
<zmatt>
it presumably detects if the parent directory is linux-stable-rcn-ee and uses that are source tree (or at least as local git repo)
<tigerxyz>
I guess so. I just want to apply patches for bluetooth fix, and rebuild the kernel.
<zmatt>
anyway, the procedures seem to be the same, it looks like the difference is that https://github.com/RobertCNelson/ti-linux-kernel-dev/ will pull the upstream TI linux kernel source tree and apply rcn's patchset on top (and this is also where this patchset is maintained afaik) while yakbuild will grab that already-patched source tree from linux-stable-rcn-ee and only apply local patches on top
<zmatt>
either should work fine for this purpose
<tigerxyz>
Let me try. If I have troubles I'll be back to ask you for help
<zmatt>
I'm guessing it still creates a KERNEL subdirectory with the source tree?
<zmatt>
if so, apply your patch there and run tools/rebuild_deb.sh like my notes mentioned
<tigerxyz>
Under linux-stable-rcn-ee it contains kernel folder with source code
<zmatt>
it works in that directory directly?
<zmatt>
it doesn't clone it?
<tigerxyz>
the kernel folder is created when checking out the version
<zmatt>
???
<zmatt>
hmm it's also not clear how to configure a custom version suffix when using yakbuild, that seems annoying
<tigerxyz>
cd ./linux-stable-rcn-ee/
<tigerxyz>
git checkout 4.19.50-ti-r20 -b tmp
<zmatt>
looking at the script it should definitely create a KERNEL subdirectory (in yakbuild)
<tigerxyz>
You are right. KERNEL is under yakbuilt. I think its binaries during compiling. kernel contains source
<zmatt>
I don't think it uses the parent directory at all, or at most it uses it as a place to clone the linux tree from
<zmatt>
I'm wondering if you misunderstood what he said
<tigerxyz>
under yakbuild, it contains patches folder
<tigerxyz>
You may be right. I don't know kernel (has .c files) is acutally used or not.
<zmatt>
yes, those are applied to the source tree in KERNEL after it's checked out, whenever you do a full rebuild (i.e. ./build_deb.sh rather than tools/rebuild_deb.sh)
<zmatt>
what do you mean by "kernel"
<zmatt>
are you talking about the "kernel" subdirectory of the linux kernel source tree? because that's just one small portion of the linux kernel, it's not relevant in this context (other than simply being part of the linux kernel source tree)
<tigerxyz>
kernel is (all small cases) is the folder under linux-stable-rcn-ee root folder
<zmatt>
yeah that's just one of many subdirectories
<zmatt>
that you'll also find in KERNEL/
<zmatt>
can you share what exactly robert said? I'm wondering if you just misunderstood something
<zmatt>
you first asked where to download the source code of 4.19.50-ti-r20, which he answered
<zmatt>
you then asked about building a kernel, he then pointed you to yakbuild as the easy way to build a specific kernel version
<zmatt>
those sets of instructions are otherwise unrelated
<rcn-ee>
tigerxyz, what issue are you having? yakbuild was setup to build "really old" tags, as the normal repo, if you checkout a specific commit, it may only work with ancient distro's..
<zmatt>
he did not instruct you to clone yakbuild inside linux-stable-rcn-ee
<zmatt>
hi robert
<rcn-ee>
hey zmatt
<tigerxyz>
so for patching. Do I have to diff the KERNEL folder with bluetooth-next?
<zmatt>
he doesn't want an ancient build, he just wants to test a patch on top of current 4.19-ti
<zmatt>
tigerxyz: do you stlil have the link to the commit?
<rcn-ee>
ah this is the bluetooth-next thing..
<zmatt>
maybe rcn can just drop it into his patchset, problem solved :P it sounded like a useful thing to have anyway
<rcn-ee>
was it a bluez issue that was resolved in kernel land?
<zmatt>
no it's a kernel issue solved in kernel land
<zmatt>
nothing to do with bluez
<zmatt>
it looks like it should cleanly apply to 4.19
<zmatt>
it just suppresses spam
<rcn-ee>
(had another bluetooth question pop up over the weekend while working in the brewery... something about bluez broke something..)
<tigerxyz>
Ok. So apply the patches after a clean build and rebuild?
<rcn-ee>
tigerxyz, ./build_kernel.sh (wait for makeconfig to pop up..), ctrl-c/ctrl-c... cd ./KERNEL/ ; patch -p1 <... ; cd ../ ; ../tools/rebuild_deb.sh
<zmatt>
meh, error: net/bluetooth/hci_event.c: patch does not apply
<tigerxyz>
Thank you, let me try.
<zmatt>
why doesn't it apply
<rcn-ee>
it's not clean......
<zmatt>
git-am doesn't use any fuzz? maybe the offset is just too big
<tigerxyz>
patch just for hci_event.c as posted by zmatt?
<zmatt>
tigerxyz: to save your disk space, you can toss the linux-stable-rcn-ee directory you have (including the yakbuild checkout you did inside it)
<tigerxyz>
Nice. Save me headache, too
<zmatt>
rcn-ee: does yakbuild have a way to add a custom version suffix, like BUILD+=-custom0 in version.sh in ti-linux-kernel-dev ?
<zmatt>
yakbuild's version.sh has no BUILD variable
<rcn-ee>
we could just add it.. main goal was to rebuild an old tag..
<zmatt>
fair, but why would anyone want to rebuild an old tag if not to customize it?
<rcn-ee>
true, we could add the BUILD tag, then sed the patches/defconfig to add the appended build name..
<rcn-ee>
tigerxyz, builds fine..
<zmatt>
maybe even add it by default... I'm personally much in favor of making sure customized builds can't be confused with (or replace) your official packages
<tigerxyz>
@rcn-ee, echo 0 > /var/lib/systemd/rfkill/platform-481a6000.serial:bluetooth”, then it works. but when I reboot the system, the value will be reset to 1 . Why it reset to 1?
<rcn-ee>
so the bootup default is 1... just by setting to 0, doesn't keep it between reboots.
<zmatt>
ew why are you manually poking in /var/lib/ ?
<zmatt>
actually rfkill state is normally persisted across reboot by systemd I think?
<zmatt>
have you tried toggling it the normal way, using rfkill ?
<rcn-ee>
rkill can be a pos.. systemd/rfkill/kernel all play with it..
<tigerxyz>
For some reason, it is automatically reset to 1. We have one board, bluetooth device cannot be reset.
<rcn-ee>
that one isn't related to bluetooth/rfkill..
<zmatt>
rcn-ee: my understanding is; rfkill utility controls the state in the kernel, systemd (specifically systemd-rfkill.service) performs save/restore across reboot
<zmatt>
"bluetoothctl has superseded them and generally supports more functionality and newer reversions of the bluetooth spec"
Guest759 has quit [Client Quit]
<zmatt>
rcn-ee: connman also messes with rfkill
<zmatt>
to add to the fun
<zmatt>
rcn-ee: https://wiki.archlinux.org/title/ConnMan claims "Warning: connman grabs rfkill events. It is most likely impossible to use rfkill or bluetoothctl to (un)block devices"
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
suggesting to use connmanctl enable instead
<zmatt>
sounds like a very connman thing to do :P
<zmatt>
it loves to hog everything it touches
waldo323__ has joined #beagle
<rcn-ee>
haha
<rcn-ee>
zmatt, so maybe a little hackish.. what if we grab an un-used, but pull-ed/pull-down gpio and say that is our "switch" then move rkfill to use a gpio instead of random software state?
<zmatt>
hardware block and software block are independent
<zmatt>
(both need to be unblocked for the device to work)
<rcn-ee>
dang it.. was hoping it would make it easier to unblock..
<rcn-ee>
i should just kill rfkill in the kernel..
<zmatt>
but if connman is the culprit then the fix is enabling it using connmanctl
<zmatt>
(or ditching connman in favor of systemd-networkd, which is what I do on our beaglebones ;)
xet7 has joined #beagle
waldo323_ has quit [Ping timeout: 272 seconds]
calculu5 has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
ikarso has joined #beagle
Stanto has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Duality has quit [Ping timeout: 272 seconds]
pi__ has joined #beagle
Stanto has quit [Remote host closed the connection]
mvaittin has quit [Quit: Client limit exceeded: 10000]
LetoThe2nd has joined #beagle
jkridner[m] has quit [Quit: Client limit exceeded: 10000]
akaWolf has joined #beagle
tigerxyz has quit [Quit: Client closed]
akaWolf has quit [Quit: leaving]
mastermind_ has quit [Remote host closed the connection]
akaWolf has joined #beagle
mastermind_ has joined #beagle
akaWolf has quit [Client Quit]
akaWolf has joined #beagle
akaWolf has quit [Client Quit]
mastermind_ has quit [Ping timeout: 272 seconds]
akaWolf has joined #beagle
mastermind_ has joined #beagle
akaWolf has quit [Client Quit]
Stanto has joined #beagle
akaWolf has joined #beagle
akaWolf has quit [Quit: leaving]
akaWolf has joined #beagle
mastermind_ is now known as mattb0ne
<mattb0ne>
hey zmatt i get this error thrown if I try to initialize the uart more than once
<mattb0ne>
raise RuntimeError( "I/O object should be closed before reinitializing UART" )
<zmatt>
that's because the I/O object should be closed before reinitializing UART
<zmatt>
(it should also be closed before starting PRU, so you should already be doing that anyway)
mvaittin has joined #beagle
<mattb0ne>
how can I close it ?
<zmatt>
with the close method? :P
<zmatt>
on the I/O object
jkridner[m] has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
zero88 has quit [Quit: Client closed]
<mattb0ne>
UART doesnt have a close method
<mattb0ne>
AttributeError: 'Uart' object has no attribute 'close'
<zmatt>
the I/O object (uart.io) does
<zmatt>
(it is implicitly opened the first time you access uart.io)
<mattb0ne>
ok
<mattb0ne>
would a dram call from python interfere with the message streaming
<zmatt>
no idea what you could mean by that
<mattb0ne>
i ask because for some reason when I port to my program i lose the ability to read the position
<mattb0ne>
so I map to core_0 a position variable so I can read it without launching the C code
<mattb0ne>
i am wondering if that is interfering with the core_1 reading it or something
<mattb0ne>
grasping at straws
<mattb0ne>
there is something interfering with the position reading that is always zero when I run it within my program
<mattb0ne>
works fine when I run it as a stand alone scrip
<zmatt>
are you forgetting to start the decoder program on core 0 ? :P
<zmatt>
mapping shared variables in python is just some administrative bookkeeping on python's side, it has no relevance to pru
<mattb0ne>
i start the decoder on startup so should be running let me confirm by running my other method
<zmatt>
also, you changed your code to print outside the loop that reads the messages, be sure to deal with the possibility that there are no messages at all (e.g. return) instead of printing bogus values
<mattb0ne>
the force works fine
<zmatt>
ok
set_ has joined #beagle
<mattb0ne>
it is just the position so I know the messages are being sent correctly
<mattb0ne>
just weird
<zmatt>
well then presumably there's some kind of bug in your code, dunno what you're doing
<mattb0ne>
yeah i am not sure how I can only partially break it
<mattb0ne>
i would expect to bork it
<mattb0ne>
the positive is my old way is borked as well
<mattb0ne>
so it is consistent
<mattb0ne>
now to find the error
<zmatt>
probably just a bug in your c code then?
<mattb0ne>
c code works since the python script you game me works beautifully
<mattb0ne>
so the pru coding is fine for both cores
thinkfat has quit [Quit: Konversation terminated!]
thinkfat_ has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Read error: Connection reset by peer]