Custom Device Tree Files

GoogleGroups
1

Hi,

I’m creating a custom device tree file to work with the PRU, and whenever I try to add the name of the part number to the uEnv.txt file, boot will hang for about 3-5 minutes then run correctly. The device tree file works correctly and does not hang after bootup whenever I manually add the part number by calling:

echo BB-BONE-PRU-05 > /sys/devices/bone_capemgr.8/slots

The device tree file I’m using is copied from the BB-BONE-PRU-01-00A0.dts file in the /lib/firmware folder.
Bootup will still hang when values aren’t modified, and It’s just a different part number.

I’m saving the BB-BONE-PRU-05-00A0.dts file in the /lib/firmware folder and compiling the file using:

dtc -O dtb -o BB-BONE-PRU-05-00A0.dtbo -b 0 -@ BB-BONE-PRU-05-00A0.dts

Does anyone know how I can use this custom device tree file without boot hanging?

2

The issue is that when the capemgr tries to load your .dtbo, the emmc overlay hasn’t been loaded and so the rootfs is inaccessible. The default timeout is 60s before it gives up and continues. if you ru dmesg, you’ll see a big gap between 1-2s and 61+s in the messages, for example:

[ 1.249060] bone-capemgr bone_capemgr.9: slot #0: Requesting part number/version based 'BB-TEST-00A0.dtbo

…
[ 1.850280] Waiting for root device /dev/mmcblk0p2…

[ 61.500166] bone-capemgr bone_capemgr.9: failed to load firmware ‘BB-TEST-00A0.dtbo’
[ 61.508320] bone-capemgr bone_capemgr.9: loader: retrying slot-0 BB-TEST:00A0 (prio 0)
[ 61.516641] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware ‘cape-boneblack-hdmi-00A0.dtbo’ for board-name ‘Bone-Black-HDMI’, version ‘00A0’
[ 61.530738] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware ‘cape-bone-2g-emmc1.dtbo’ for board-name ‘Bone-LT-eMMC-2G’, version ‘00A0’
[ 61.544284] bone-capemgr bone_capemgr.9: slot #0: Requesting part number/version based 'BB-TEST-00A0.dtbo

[ 61.554290] bone-capemgr bone_capemgr.9: slot #0: Requesting firmware ‘BB-TEST-00A0.dtbo’ for board-name ‘Test Cape with EEPROM’, version ‘00A0’

See this thread: https://groups.google.com/forum/#!msg/beagleboard/Iem_mHknIUM/NJkw0O7gHQYJ

There were 3 commits in the last 6 months to solve this:

  1. Priority on capemgr.part_no option: https://github.com/pantoniou/linux-bbxm/commit/738e37102bdfbfd065f4f53814df62b896804d90
  2. Retry loading firmware on failure: https://github.com/pantoniou/linux-bbxm/commit/fb99fd668f8baaf4270ce8b2359077dcc9a047aa
  3. Make firmware timeout configuable: https://github.com/pantoniou/linux-bbxm/commit/66166f29c1cfa5035ba4782266d677b908e81f0e

So in theory, according to #1 if you append ::10 to the partno in uEnv.txt, it should load it after the emmc cape has been loaded which should solve your issue.

I have a custom cape with an EEPROM that designates the partno, so I don’t need uEnv.txt, but there’s no way to specify the priority here and I’m stuck with the 60 delay. Supposedly, #2 and #3 fix this, but I haven’t yet discovered where these changes actually get into the Angstrom builds.

I just built Angstrom 13.12 (yocto1.5) today and they don’t appear to be included. In fact I haven’t even figured out where the capemgr is coming from, there are no .c files in drivers/misc/cape/beaglebone in the kernel tree!

If anyone can tell me how to take the Angstrom 13.12/yocto1.5 and update it (preferably via a .bb recipe!) to set the FIRMWARE_LOADING_TIMEOUT to say 1s, that would be great!

Hope this helps,

-W.