On Wed, Oct 14, 2015 at 10:32 PM, Rick Mann <[email protected]> wrote: > >> On Oct 14, 2015, at 20:15 , Robert Nelson <[email protected]> wrote: >> >> On Wed, Oct 14, 2015 at 10:06 PM, <[email protected]> wrote: >>> I'm trying to sync up with the latest & greatest image-builder work by >>> Robert Nelson. So far so good, I have my debian jessie 4.1.10-ti-r21 BBB >>> image built and flashed; I've converted my .dts *back* into an overlay for >>> the 4.1 capemgr with the kernels. >>> >>> The cape EEPROM is properly flashed, but while capemgr detects it, it >>> doesn't seem to be able to load the BB-SERIAL-00A0.dtbo located in >>> /lib/firmware: >>> >>> [ 3.588753] bone_capemgr bone_capemgr: Baseboard: >>> 'A335BNLT,0A6A,xxxxBBBKxxxx' >>> [ 3.588789] bone_capemgr bone_capemgr: >>> compatible-baseboard=ti,beaglebone-black - #slots=4 >>> [ 3.632229] bone_capemgr bone_capemgr: slot #0: 'Serial Util >>> Board,00A0,WinstonSmith,BB-SERIAL' >>> [ 3.688184] bone_capemgr bone_capemgr: slot #1: No cape found >>> [ 3.748178] bone_capemgr bone_capemgr: slot #2: No cape found >>> [ 3.808177] bone_capemgr bone_capemgr: slot #3: No cape found >>> [ 3.814213] bone_capemgr bone_capemgr: initialized OK. >>> ... >>> [ 4.838440] bone_capemgr bone_capemgr: loader: failed to load slot-0 >>> BB-SERIAL:00A0 (prio 0) >>> [ 9.857097] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data >>> mode. Opts: (null) >>> >>> Basically, the .dts simply enables UART1,2,4,5 and a DS1307 RTC. >>> >>> I know the .dts is ok as I can manually load the .dtbo with: >>> >>> echo 'BB-SERIAL' > /sys/devices/platform/bone_capemgr/slots >>> >>> But I can't get it to automatically load, I've tried the EEPROM detection, >>> adding it to uEnv.txt and even /etc/default/capemgr (which used to be the >>> only solution for 3.8). >>> >>> Back in the 3.8 days, there was an issue with the root filesystem not being >>> mounted when the capemgr did it's detection ... is this still an issue (see >>> last line of dmesg output above -- I did try adding rootwait to the kernel >>> cmdline). In 3.8, this was easily resolved by adding CAPE=BB-SERIAL to the >>> /etc/default/capemgr (which doesn't seem to work now). >> >> This isn't an issue anymore.. Make sure your *.dtbo is under >> /lib/firmware then run: >> >> sudo update-initramfs -uk `uname -r` >> >> to make sure the *.dtbo get's copied to the intrd. (it'll still read >> it from the /lib/firmware) > > I'm a little confused. Are they read from /lib/firmware always? Why do they > have to be in initrd? And how does the behavior differ between 3.8 and 4.1?
It's a race... For capes with eeprom, the *.dtbo's need to be inside the initrd (or kernel vmlinuz), as by the time root gets mounted (/lib/firmware) the kernel's already given up trying to load them. (of course once you hit userspace a manual load works fine) Back in the initial 3.8/wheezy day's we had the have the *.dtbo's built-into the kernel for them to work with eeprom devices. Well, earlier this summer we realized we weren't actually loading the *.dtbo's into the initrd.. Now we ship this script: https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/dtbo by default for 3.8-wheezy/4.1-jessie images... So "today" the behavior is the same.. But the big difference, 3.8 99% of the available *.dtbo's are built into the "vmlinuz", with 4.1 they are all loaded from the initrd (or /lib/firmware with no initrd), as none are patched to be built into the kernel.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
