My custom cape's devicetree fails to load at boot, but can be loaded manually

Question

If I load my own device-tree overlay from a shell it loads fine, but if I try to load it at boot, it won't do so. What am I missing?

It is a debian BeagleBone Black that I set up using bone-debian-7.4-2014-04-23-2gb.img.xz
Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux

Here is the change that I made to /boot/uboot/uEnv.txt :

optargs=capemgr.enable_partno=BB-FOO-GPIO

This is the output of dmesg | grep bone-capemgr :

Baseboard: 'A335BNLT,00A5,4049BBBK7400'
compatible-baseboard=ti,beaglebone-black
slot #0: No cape found
slot #1: No cape found
slot #2: No cape found
slot #3: No cape found
slot #4: specific override
bone: Using override eeprom data at slot 4
slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
slot #5: specific override
bone: Using override eeprom data at slot 5
slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
slot #6: specific override
bone: Using override eeprom data at slot 6
slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
enabled_partno part_number 'BB-FOO-GPIO', version 'N/A', prio '0'
slot #7: generic override
bone: Using override eeprom data at slot 7
slot #7: 'Override Board Name,00A0,Override Manuf,BB-FOO-GPIO'
loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
loader: before slot-5 BB-BONELT-HDMI:00A0 (prio 1)
loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
initialized OK.
loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
loader: before slot-7 BB-FOO-GPIO:00A0 (prio 0)
loader: check slot-7 BB-FOO-GPIO:00A0 (prio 0)
loader: after slot-7 BB-FOO-GPIO:00A0 (prio 0)
slot #7: Requesting part number/version based 'BB-FOO-GPIO-00A0.dtbo
slot #7: Requesting firmware 'BB-FOO-GPIO-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
failed to load firmware 'BB-FOO-GPIO-00A0.dtbo'
loader: failed to load slot-7 BB-FOO-GPIO:00A0 (prio 0)
loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
loader: after slot-5 BB-BONELT-HDMI:00A0 (prio 1)
slot #5: Requesting firmware 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
slot #5: dtbo 'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree
slot #5: #4 overlays
loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
slot #4: #2 overlays
slot #4: Applied #2 overlays.
loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
slot #5: Applied #4 overlays.
loader: done slot-5 BB-BONELT-HDMI:00A0 (prio 1)
loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0'
slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree
slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)
slot #6: Failed verification
loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

Here is my source file for the device-tree overlay:

/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* Identification */
    part-number = "BB-FOO-GPIO";
    version = "00A0";

    /* Resources required */
    exclusive-use =
        "P9.27",        /* XXX */
        "P9.23",        /* XXX */
        "gpio3_19",     /* XXX */
        "gpio1_17";     /* XXX */

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            foo_gpio_pins: pinmux_gpio_helper_pins {
                pinctrl-single,pins = <
                    0x1a4 0x0f      /* P9.27 GPIO3_19: MODE7 - OUTPUT */
                    0x044 0x2f      /* P9.23 GPIO1_17: MODE7 - INPUT */
                >;
            };
        };
    };

    fragment@1 {
        target = <&ocp>;    /* On-chip Peripherals */
        __overlay__ {

            foo_gpio_helper {
                compatible = "gpio-of-helper";
                pinctrl-names = "default";
                pinctrl-0 = <&foo_gpio_pins>;
                status = "okay";

                foo_test_output {
                    gpio-name = "foo_test_output";
                    gpio = <&gpio4 19 0x00>;            /* gpio4 => GPIO-3 */
                    output;
                    init-high;
                };

                foo_test_input {
                    gpio-name = "foo_test_input";
                    gpio = <&gpio2 17 0x00>;            /* gpio2 => GPIO-1 */
                    input;
                    count-rising-edge;
                    count-falling-edge;
                };
            };
        };
    };
};

~
(I compiled it so: dtc -O dtb -o BB-FOO-GPIO-00A0.dtbo -b 0 -@ BB-FOO-GPIO-00A0.dts}

Now loading it manually using echo BB-FOO-GPIO > $SLOTS" it loads fine..
dmesg -c gives me:

bone-capemgr bone_capemgr.9: part_number 'BB-FOO-GPIO', version 'N/A'
bone-capemgr bone_capemgr.9: slot #8: generic override
bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,BB-FOO-GPIO'
bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-FOO-GPIO-00A0.dtbo
bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'BB-FOO-GPIO-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
bone-capemgr bone_capemgr.9: slot #8: dtbo 'BB-FOO-GPIO-00A0.dtbo' loaded; converting to live tree
bone-capemgr bone_capemgr.9: slot #8: #2 overlays
of_get_named_gpio_flags exited with status 17
gpio-of-helper foo_gpio_helper.15: Allocated GPIO id=0
of_get_named_gpio_flags exited with status 115
gpio-of-helper foo_gpio_helper.15: Allocated GPIO id=1
gpio-of-helper foo_gpio_helper.15: ready
bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.

And cat /sys/devices/bone_capemgr.9/slots gives me what I desire:

0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-FOO-GPIO

So, what am I missing? Why won't it load at boot time, but it will from a shell? The problem seems related to firmware not being loaded... I don't understand.

*"The problem seems related to firmware not being loaded"* -- FW is loaded by a userspace process, so a driver cannot get its firmware until Busybox is executing. A driver that need FW usually is built as a loadable module (i.e. read from the mounted rootfs) or specified as **late_initcall()** in order to defer execution of its initialization routine. — sawdust, Jun 10 '14 at 21:24
Is there a way for me to tell it that there is no firmware? (I assume that by "firmware" it is referring to some flash chip on a cape that it would normally read?) — handros, Jun 11 '14 at 05:21
Firmware for devices are stored in **/lib/firmware** of the rootfs. If the driver is notified that the firmware does not exist, then the typical driver fails to initialize. See http://lxr.free-electrons.com/source/Documentation/firmware_class/README — sawdust, Jun 12 '14 at 02:08

George · Accepted Answer · 2014-07-12T14:57:13.653

5

This is an issue that has a solution described in the link: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Loading_custom_capes

I hope it helps, George

edited Jul 12 '14 at 14:57

answered Jul 08 '14 at 12:54

George

66
2

2

I guess this should be a comment, unless you give more details and you are sure about the answer responds the question. – Gabriel Petrovay Jul 08 '14 at 13:13
The solution in that link (adding the cape name to /etc/default/capemgr) worked for me (using 3.8.13 kernel). – Ken Shirriff Nov 17 '17 at 19:39

score 2 · Answer 2 · answered May 08 '15 at 20:56

The problem ist caused by the fact that the root filesystem (in my case on the eMMC) is not yet mounted when the kernel tries to load the overlay. I solved the problem by manually modifying the initramfs:

Follow the instructions on e.g. http://backreference.org/2010/07/04/modifying-initrdinitramfs-files/ to unpack the file /boot/uboot/initrd.img
Add the folder /lib/firmware to the unpacked archive and copy your *.dtbo file into this folder
Pack and compress the initrd again and copy it back to /boot/uboot (while keeping a copy of the original file).

On the next reboot, the dtbo should be loaded:

 0: 54:P---L BEAGLE-GO-CAPE,00A0,FH-Aachen/FZJ,cape-beaglego
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

THIS should be the answer! Thanks for saving my day! – Rob Sep 18 '15 at 11:38 — Rob, Sep 18 '15 at 11:38

score 1 · Answer 3 · answered Jun 14 '14 at 18:15

1

I just solved the same problem eliminating the "-b 0" clause in the dtc command. I didn't spend many time to deeper investigate, but -b means "set the physical boot CPU" (as from manual page) and, may be, it conflicts during start-up.

answered Jun 14 '14 at 18:15

Pierluigi

11
1

SGS · Answer 4 · 2014-12-17T14:59:10.630

1

George provided a link with details of a workaround. This is the actual workaround:

add "CAPE=BB-FOO-GPIO" to /etc/default/capemgr

.. and remove the code from /boot/uboot/uEnv.txt

edited Dec 17 '14 at 14:59

answered Oct 30 '14 at 15:29

SGS

171
5

score 0 · Answer 5 · answered Nov 26 '14 at 07:20

There are a few conflating ideas here that I just worked through and wanted to update this answer so that the next person doesn't have to spend as much time as I did.

First, it seems that the latest versions of Ubuntu or Debian on Beaglebone Black (as of today) do not honor the uEnv.txt flags for the reasons described in loading custom capes because of a chicken and egg problem with booting from a filesystem that isn't loaded yet. So, per ther link, the directions say to add CAPE=<CAPE NAME HERE> to /etc/default/capemgr.

Second, you need to make sure you're running an operating system that respects this new file, e.g., @RobertCNelson's Ubuntu build that provides init scripts that respect /etc/default/capemgr. See an example.

So, in a nutshell, you need to make sure you're running one of the custom OS that respect /etc/default/capemgr before blindly making those changes, as I did.

My custom cape's devicetree fails to load at boot, but can be loaded manually

5 Answers5