Hard to say. But if you’re like me, perhaps you’ll find that you were fixated on something wrongly, and then find something really obvious . . . that causes an instant face->desk.
If you took notes though perhaps it may be faster to just start over from scratch ? Keeping all your necessary files of course.
I think I have a thread synchronization situation going on that just hasn't show up until now.
Okay, with great thanks to Robert for all his help getting my DTB up-and-running, I've now run into a new issue with GPIO and/or ADC access. It seems that if I do it too rapidly, one of the operations never returns.
I sit in a loop in the main thread, polling two ADC channels, and at the start of the loop, and every 5 times through, I poll a GPIO and set a GPIO. At the end of the loop, I sleep for 100 ms.
This has worked very well under 3.8. Over the last few hours I upgraded to 3.14.26-ti-r43 (with CONFIG_USB_TI_CPPI41_DMA disabled and CONFIG_MUSB_PIO_ONLY enabled). I then customized the dtb with this: http://pastebin.com/ksUU07u0
With all that, my GPIOs and ADC seemed to work fine. But then I removed some logging statements from the main loop, and now the behavior seems to be that the main thread loop hangs on some operation (I use sysfs to access the GPIOs and ADCs). The secondary thread, which is decoding MP3s and playing audio, continues to function. If I hit Control-C, that thread stops, but the process doesn't exit. I can't kill the process at all, and I have to reboot the BBB.
I inserted a 100 ms delay before each of my sysfs operations, and it seems to function correctly.
Note that at first I thought it might be a thread synchronization issue between my two threads (the second thread can be paused by the main via a binary semaphore implemented with C++11 mutex and condition variable). But that code only gets executed if the state of one of the GPIOs changes, and that's not happening.
I also commented out all the GPIO-access code and only polled the ADCs, one after the other, with a 100 ms pause after, and that, too locks up.
I tried to attach to the process with GDB, but I can't seem to interrupt it to see the state of things (similar to how I can't Control-C the process itself).
Any ideas? I can probably live with the pre-call delay, but that seems lame.
Thanks!
Oh, I think I forgot to mention: Despite the fact that it's mostly working with the new DTB stuff, I still can't set the mode on the pin:
# cat $PINS | grep 82c
pin 11 (44e1082c.0) 00000027 pinctrl-single
According to my .dts (http://pastebin.com/ksUU07u0), it should end in 0xf (PIN_OUTPUT | MUX_MODE7).
git checkout origin/3.14.26-ti-r43 -b tmp
make ARCH=arm bb.org_defconfig./scripts/config --disable CONFIG_USB_TI_CPPI41_DMA
./scripts/config --enable CONFIG_MUSB_PIO_ONLYfakeroot make ARCH=arm LOCALVERSION=-ti-r43-tmp
CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- KDEB_PKGVERSION=1cross
KBUILD_DEBARCH=armhf deb-pkgcp *.deb to bbb, then run:
sudo dpkg -i linux-image-*
sudo reboot
This worked. Thank you. A couple notes:
arm-linux-gnueabihf packages are in Debian Sid; I didn’t know about the cross-compiling packages at eewiki.net, didn’t look for a backport and was hesitant to pin. So I did everything on the BBB. I needed to set up some swap space (256M) and add some storage (micro SD card). It was also necessary to install packages bc and lzop. It took half a day, of course, but the kernel compiled and package installed. I really appreciated the help.
Oh, yeah. And the sound card works now.
Rick,
Have you run pstree ( psmisc - I think the package is ) yet ? Which is just a simple utility to show you at a glance which processes are running.
But it is kind of weird your changes seem non persistent. Not even sure where I would start to troubleshoot an issue like that . . .
Well, I certainly ran ps to see the processes. Mine is still there when this happens. I'm not sure which of my posts you saw most recently, but it seems related to the rate at which I read the ADCs. I inserted a 50 ms sleep before each read, and it seems solid now. I'll have to troubleshoot that later.