So I have to read more about device trees, but maybe someone can point me in the right direction (and (in-)validate my assumption).
I am trying to get my BeagleG/Bumps cape device overlay dtbo-file read at boot-time, but it does not work. If I manually add it by echoing its name to /sys/devices/bone_capemgr.*/slots, it works and is working properly but if I add it to the kernel commandline ( optargs=capemgr.enable_partno=BeagleG ), it doesn’t.
I don’t have an EEPROM on my cape that helps it to be identified. I assume this is the problem ? Is this checked when when the cape is attempted to be loaded at boot time as opposed to manual ? If so, then I probably do have to provide that in the next hardware version.
Is there any specific reason why loading the overlay while starting the kernel (and not in an rc.local script, for example)? We equip every of our capes with an eeprom, but I must say that I am using it very rarely…
Yes, I am booting from the micro-sdcard, @Pantelis_Antoniou . Does it mean that it essentially can’t read the *.dtbo in /lib/firmware, as it is stored on that card ?
Is the boot process from the build-in flash different ? Or should the firmware stuff be in some initrd ?
I want to make sure to set some GPIO pin pull-ps and pulldowns early in the boot process to have some higher power FETs defined switched off early on in the boot process - which is why I’d like to load the cape information early on in the boot process, @Daniel_Barthels .
to the end of
/boot/uboot/uEnv.txt
did the trick. In Debian anyway. Ubuntu wasn’t too reliable (which was why I moved to Deb) but to get Ubuntu working I modified /etc/rc.local (yeah, bad practice)
to say
The point of doing it in the kernel is that it’s available very early in the boot process, allowing things like putting the root filesystem on a device that’s available only after the cape EEPROM is read.
If I add
optargs=capemgr.enable_partno=BeagleG
to my uEnv.txt, it boots up and reads that kernel command line option and attempts to load the firmware … but then fails, @Hugo_Rune . From dmesg:
[ 2.107154] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware ‘BeagleG-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 2.911423] bone-capemgr bone_capemgr.9: failed to load firmware ‘BeagleG-00A0.dtbo’
So it does all the right things except actually loading the firmware. And I boot from the sdcard. So @Pantelis_Antoniou 's assumption might be right.
All your problems will go away if you just add your cape definition in the kernel’s firmware/capes directory (adding it to the Makefile list of capes to build). If the kernel’s firmware inclusion option is enabled (CONFIG_FIRMWARE_IN_KERNEL) the DTBOs are including in the kernel image so it will work in any point in the boot sequence.
Note that is a consequence of the awkward design choices of the beaglebone black.
I recall a similar DMESG from my own experiments. For me I had to disable the HDMI first as my device tree was attempting to use pins already assigned to HDMI… Don’t know if that will help you though as I appear to spend a lot of my BBB time saying “WTF?”
I tried to limit myself to pins that are not already in use by standard functionality, @Hugo_Rune , so hopefully this is not the case here.
Compiling the cape information into the kernel is some awkward solution, which would not be very end-user-friendly, @Pantelis_Antoniou , so I’ll try to avoid that (in that case, starting it late in some /etc/init.d script is more acceptable).
So next steps: I’ll experiment with booting directly from the internal flash and see if that makes a difference. If not, then adding it to the initrd might be the way to go. It boils down to: I’ll have to study the boot-up process of the BBB more closely I suppose.
Well keep us informed on how it goes. When I got my first one up and running I took an image of it and now simply flash any other BBB’s we need. Good luck!
Ok confirmed, simply putting it in the initial ramdisk root filesystem works.
a) putting optargs=capemgr.enable_partno=BeagleG in /boot/uboot/uEnv.txt
b) copy the *.dtbo file into lib/firmware in uInitrd (you have to unpack it, copy the file there, and mkimage the uInitrd again, but this is of course way simpler than building a kernel).