DBTO is not loaded by capemgr (Capes eeprom-info is correct and dbto-file exists in /lib/firmware)

[RL Budde]

Hi!

I am working on a new Home Automation cape using three uarts (1,2,4). The eeprom is set up according to the current SRM with format A1 and gets read correctly on startup. The device tree overlay was compiled using the patch allowing for overlays (so dtc knows -@ and \plugin\). After that I placed the resulting "ibb-0001.dtbo" in /lib/firmware.

This is what I get on startup:

[    1.619295] bone-capemgr bone_capemgr.8: Baseboard: 'A335BNLT,0A5A,1613BBBK2649'
[    1.627084] bone-capemgr bone_capemgr.8: compatible-baseboard=ti,beaglebone-black
[    1.659113] bone-capemgr bone_capemgr.8: slot #0: 'Home Automation Cape,0001,IBB Robert Budde,ibb'
[    1.698749] bone-capemgr bone_capemgr.8: slot #1: No cape found
[    1.735857] bone-capemgr bone_capemgr.8: slot #2: No cape found
[    1.772966] bone-capemgr bone_capemgr.8: slot #3: No cape found
[    1.779219] bone-capemgr bone_capemgr.8: slot #4: specific override
[    1.785819] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 4
[    1.793855] bone-capemgr bone_capemgr.8: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[    1.804003] bone-capemgr bone_capemgr.8: slot #5: specific override
[    1.810600] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 5
[    1.818633] bone-capemgr bone_capemgr.8: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[    1.828671] bone-capemgr bone_capemgr.8: slot #6: specific override
[    1.835267] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 6
[    1.843302] bone-capemgr bone_capemgr.8: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[    1.853925] bone-capemgr bone_capemgr.8: loader: before slot-0 ibb:0001 (prio 0)
[    1.861713] bone-capemgr bone_capemgr.8: loader: check slot-0 ibb:0001 (prio 0)
[    1.869517] bone-capemgr bone_capemgr.8: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.878378] bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.887249] bone-capemgr bone_capemgr.8: loader: before slot-5 BB-BONELT-HDMI:00A0 (prio 1)
[    1.896016] bone-capemgr bone_capemgr.8: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
[    1.904720] bone-capemgr bone_capemgr.8: initialized OK.
[    1.910323] bone-capemgr bone_capemgr.8: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    1.919173] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    1.941732] bone-capemgr bone_capemgr.8: loader: after slot-0 ibb:0001 (prio 0)
[    1.949423] bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.958196] bone-capemgr bone_capemgr.8: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
[    1.973258] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    1.982040] bone-capemgr bone_capemgr.8: slot #0: Requesting part number/version based 'ibb-0001.dtbo
[    1.997835] bone-capemgr bone_capemgr.8: slot #0: Requesting firmware 'ibb-0001.dtbo' for board-name 'Home Automation Cape', version '0001'
[    2.829291] bone-capemgr bone_capemgr.8: failed to load firmware 'ibb-0001.dtbo'
[    2.837120] bone-capemgr bone_capemgr.8: loader: failed to load slot-0 ibb:0001 (prio 0)
[    2.845627] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

But - the dtbo exists in /lib/firmware and the rights are ok as well.

I tried to manually enabling the overlay:

root@arm:~# echo ibb-0001 > /sys/devices/bone_capemgr.8/slots
-bash: echo: write error: No such file or directory

(same for just "ibb" or "/lib/firmware/ibb" and so on)

Enabling the BB-UART by this way works as intended.

Do I have to register the dtbo somewhere to get it found?

Thank you very much!

Robert

[Frank Hunleth]

Hi Robert,

I'm new to the device tree overlay setup as well, but since you don't
have any replies yet, I figured that I'd post what I know.

First, is the filesystem that has ibb-0001.dtbo mounted at the time
where the firmware load failure occurs? I just was curious if the file
even had a chance to load.

I was also wondering whether there were any conflicts in ibb-0001.dtbo
with the other capes. It's interesting that your cape seems to get
loaded after the HDMI and EMMC capes, since my custom cape gets loaded
first. However, I've also been disabling the HDMI cape in my setup so
that I can load the cape dynamically. You might want to add
"capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" to your kernel
command line arguments in uEnv.txt.

>
> But - the dtbo exists in /lib/firmware and the rights are ok as well.
>
> I tried to manually enabling the overlay:
>
>> root@arm:~# echo ibb-0001 > /sys/devices/bone_capemgr.8/slots
>> -bash: echo: write error: No such file or directory

Did you look at dmesg when you get the write error? Sometimes I get
more details there when I get the "write error".

>
>
> (same for just "ibb" or "/lib/firmware/ibb" and so on)
>
> Enabling the BB-UART by this way works as intended.
>
> Do I have to register the dtbo somewhere to get it found?

My next thought is to incrementally modify BB-UART until it looks like
ibb-0001.dts to see what lines causing the problem.

Hope this helps,

Frank

>
> Thank you very much!
>
> Robert
>

> --
> 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 beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>




--
Frank Hunleth
Troodon Software LLC
http://troodon-software.com/

[RL Budde]

Hi Frank!

I highly appreciate your help! Thanks!

First, is the filesystem that has ibb-0001.dtbo mounted at the time
where the firmware load failure occurs? I just was curious if the file
even had a chance to load.

I guess it is. Its located on the onboard eMMC along with the other overlays which are loaded just fine.

 

I was also wondering whether there were any conflicts in ibb-0001.dtbo
with the other capes. It's interesting that your cape seems to get
loaded after the HDMI and EMMC capes, since my custom cape gets loaded
first. 

This is the case here as well. Maybe the exerpt from the system-log was too short - the overlay for my cape is requested prior to loading the other overlays for the onboard "capes".

 

Did you look at dmesg when you get the write error? Sometimes I get
more details there when I get the "write error".

I have to correct my self in this case: I can (now?) manually enable my overlay by "echo ibb > ...". It also works with version-info ("echo ibb:0001 > ...). So it looks like thew dtbo is valid and does not conflict with other overlays or the base.

My next thought is to incrementally modify BB-UART until it looks like
ibb-0001.dts to see what lines causing the problem.

I copy/renamed a BB-UART-overlay to "ibb-0001.dtbo" to check if its loaded then. Still no success. I also changed my version-string from "0001" to "00A0" as for some reason all other capes seem to adhere to this versioning-scheme. Does not change anything (except of course the name of the requested file...).

My dts:

/dts-v1/;

/plugin/;

/ {

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

part-number = "ibb";

version = "00A0";

exclusive-use = "P9.24", "P9.26", "uart1",

                  "P9.21", "P9.22", "uart2",

                  "P9.13", "P9.11", "uart4";

fragment@0 {

target = <&am33xx_pinmux>;

__overlay__ {

bb_uart1_pins: pinmux_bb_uart1_pins {

pinctrl-single,pins = <0x180 0x20 0x184 0x00>;

};

bb_uart2_pins: pinmux_bb_uart2_pins {

pinctrl-single,pins = <0x150 0x21 0x154 0x01>;

};

bb_uart4_pins: pinmux_bb_uart4_pins {

pinctrl-single,pins = <0x70 0x26 0x74 0x06>;

};

};

};

fragment@1 {

target = <&uart2>; /* really uart1 */

__overlay__ {

status = "okay";

pinctrl-names = "default";

pinctrl-0 = <&bb_uart1_pins>;

};

};

fragment@2 {

target = <&uart3>; /* really uart2 */

__overlay__ {

status = "okay";

pinctrl-names = "default";

pinctrl-0 = <&bb_uart2_pins>;

};

};

fragment@3 {

target = <&uart5>; /* really uart4 */

__overlay__ {

status = "okay";

pinctrl-names = "default";

pinctrl-0 = <&bb_uart4_pins>;

};

};

};

Best regards,

Robert 

[RL Budde]

In addition to this:

system-log entries when I MANUALLY load the overlay:

[ 1938.691200] bone-capemgr bone_capemgr.8: part_number 'ibb', version 'N/A'

[ 1938.701292] bone-capemgr bone_capemgr.8: slot #8: generic override

[ 1938.708018] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 8

[ 1938.716197] bone-capemgr bone_capemgr.8: slot #8: 'Override Board Name,00A0,Override Manuf,ibb'

[ 1938.726094] bone-capemgr bone_capemgr.8: slot #8: Requesting part number/version based 'ibb-00A0.dtbo

[ 1938.735943] bone-capemgr bone_capemgr.8: slot #8: Requesting firmware 'ibb-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[ 1938.773112] bone-capemgr bone_capemgr.8: slot #8: dtbo 'ibb-00A0.dtbo' loaded; converting to live tree

[ 1938.786162] bone-capemgr bone_capemgr.8: slot #8: #4 overlays

I have NO clue what is different. I already took a closer look at the patch introducing "capemgr.c" - actually the same routine/info for requesting the firmware is used.

Further, I tried loading the overlay during boot-time using bootargs in uEnv.txt (https://groups.google.com/forum/#!topic/beagleboard/DurM6BE6lpY) - is gives the same error.

So now it might really be that the filesystem is not ready???

Robert

[Frank Hunleth]

Hi Robert,

I think that's the case. I compiled your dts into my kernel, updated
my eeprom and was successful in getting it to load on boot. Based on
what I've learned so far, the error messages below aren't really error
messages, and I'd expect the serial ports to work even though I didn't
test them. Here's the log:

[ 1.002566] bone-capemgr bone_capemgr.8: Baseboard:
'A335BNLT,0A5B,2313BBBK0099'
[ 1.010388] bone-capemgr bone_capemgr.8:
compatible-baseboard=ti,beaglebone-black
[ 1.018323] bone-capemgr bone_capemgr.8: Skipping disabled cape
with part# BB-BONELT-HDMI
[ 1.026966] bone-capemgr bone_capemgr.8: Skipping disabled cape
with part# BB-BONELT-HDMIN
[ 1.059749] bone-capemgr bone_capemgr.8: slot #0:
'cape-bone-ibb,00A0,Troodon Software,ibb'
[ 1.100548] bone-capemgr bone_capemgr.8: slot #1: No cape found
[ 1.137656] bone-capemgr bone_capemgr.8: slot #2: No cape found
[ 1.174765] bone-capemgr bone_capemgr.8: slot #3: No cape found
[ 1.181022] bone-capemgr bone_capemgr.8: slot #4: specific override
[ 1.187624] bone-capemgr bone_capemgr.8: bone: Using override
eeprom data at slot 4
[ 1.195662] bone-capemgr bone_capemgr.8: slot #4:
'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[ 1.205800] bone-capemgr bone_capemgr.8: slot #5: specific override
[ 1.212402] bone-capemgr bone_capemgr.8: bone: Using override
eeprom data at slot 5
[ 1.220440] bone-capemgr bone_capemgr.8: slot #5:
'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[ 1.230495] bone-capemgr bone_capemgr.8: slot #6: specific override
[ 1.237095] bone-capemgr bone_capemgr.8: bone: Using override
eeprom data at slot 6
[ 1.245134] bone-capemgr bone_capemgr.8: slot #6:
'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[ 1.255440] bone-capemgr bone_capemgr.8: Skipping loading of
disabled cape with part# BB-BONELT-HDMI
[ 1.265028] bone-capemgr bone_capemgr.8: Skipping loading of
disabled cape with part# BB-BONELT-HDMIN
[ 1.274900] bone-capemgr bone_capemgr.8: loader: before slot-0
ibb:00A0 (prio 0)
[ 1.283399] bone-capemgr bone_capemgr.8: loader: check slot-0
ibb:00A0 (prio 0)
[ 1.291834] bone-capemgr bone_capemgr.8: initialized OK.
[ 1.297435] bone-capemgr bone_capemgr.8: loader: before slot-4
BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.306286] bone-capemgr bone_capemgr.8: loader: check slot-4
BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.319236] bone-capemgr bone_capemgr.8: loader: after slot-0
ibb:00A0 (prio 0)
[ 1.328434] bone-capemgr bone_capemgr.8: loader: check slot-4
BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.338694] usbcore: registered new interface driver cdc_acm
[ 1.344767] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[ 1.353158] Initializing USB Mass Storage driver...
[ 1.358429] bone-capemgr bone_capemgr.8: slot #0: Requesting part
number/version based 'ibb-00A0.dtbo
[ 1.369173] usbcore: registered new interface driver usb-storage
[ 1.375491] USB Mass Storage support registered.
[ 1.380463] bone-capemgr bone_capemgr.8: slot #0: Requesting
firmware 'ibb-00A0.dtbo' for board-name 'cape-bone-ibb', version
'00A0'
[ 1.395517] mousedev: PS/2 mouse device common for all mice
[ 1.402791] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 1.410355] bone-capemgr bone_capemgr.8: slot #0: dtbo

'ibb-00A0.dtbo' loaded; converting to live tree

[ 1.420971] 44e3e000.rtc: already running
[ 1.425558] i2c /dev entries driver
[ 1.429653] bone-capemgr bone_capemgr.8: slot #0: #4 overlays
[ 1.440044] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 1.448101] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is
a OMAP UART1
[ 1.456901] cpuidle: using governor ladder
[ 1.461965] cpuidle: using governor menu
[ 1.467566] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is
a OMAP UART2
[ 1.476646] of_get_named_gpio_flags: can't parse gpios property
[ 1.476669] of_get_named_gpio_flags: can't parse gpios property
[ 1.476686] of_get_named_gpio_flags: can't parse gpios property
[ 1.476722] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed
[ 1.484017] omap_hsmmc mmc.4: Failed to get rstctl; not using any
[ 1.492449] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is
a OMAP UART4
[ 1.500393] omap_hsmmc mmc.4: unable to select pin group
[ 1.506842] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25
[ 1.514075] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24
[ 1.521472] bone-capemgr bone_capemgr.8: slot #0: Applied #4 overlays.
[ 1.528347] bone-capemgr bone_capemgr.8: loader: done slot-0
ibb:00A0 (prio 0)

[RL Budde]

Hello Frank,

again thank you very much for investigating this issue so thoroughly!

So as the overlay is working with your bone, can you tell me if you are booting from SD or eMMC? Are you using the Angstrom distribution or something different? I am using the most recent kernel from Robert Nelson with his Debian Wheezy distribution.

I also did further tests: after I wasn't able to enable my overlay through "bootargs", I tried the very same with BB-UART1, BB-UART2 and BB-UART4 (which is in essence what I need). This works! So now I am totally puzzled - as this files lie in the very same directory/storage as my overlay. The only difference is the fact that those are shipped with the kernel and are declared somewhere else in the kernel!?

Best regards,

Robert

[Bas Laarhoven]

> --
> 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 beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Very interesting thread!

I've been wondering for a while now why an overlay that works perfectly
and loads at boot time on an Angstrom
based system will not load (during boot) on a Debian based system.
Manually loading after boot does work without
a problem.

-- Bas

[Frank Hunleth]

On Mon, Jul 15, 2013 at 7:36 AM, RL Budde <rl.b...@googlemail.com> wrote:
> Hello Frank,
>
> again thank you very much for investigating this issue so thoroughly!

No problem. I'm in the midst of debugging my own cape, so your
question is particularly convenient to debug at the moment.

>
> So as the overlay is working with your bone, can you tell me if you are
> booting from SD or eMMC?

eMMC

> Are you using the Angstrom distribution or
> something different? I am using the most recent kernel from Robert Nelson
> with his Debian Wheezy distribution.

I'm using buildroot.

The key to loading firmware on boot sounds like it is to have

CONFIG_FIRMWARE_IN_KERNEL=y

in your kernel config and to make sure that your dts is included in
the list in <kernel>/firmware/Makefile.

Having said this, I've been wanting to turn off the
CONFIG_FIRMWARE_IN_KERNEL switch to avoid recompiling the kernel each
change, but I don't know of a good alternative. It might be nice if
the capemgr could pull the dts off the EEPROM... :)

Frank

>
> I also did further tests: after I wasn't able to enable my overlay through
> "bootargs", I tried the very same with BB-UART1, BB-UART2 and BB-UART4
> (which is in essence what I need). This works! So now I am totally puzzled -
> as this files lie in the very same directory/storage as my overlay. The only
> difference is the fact that those are shipped with the kernel and are
> declared somewhere else in the kernel!?
>
> Best regards,
> Robert
>

> --
> 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 beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Bas Laarhoven]

On 15-7-2013 14:20, Frank Hunleth wrote:
> On Mon, Jul 15, 2013 at 7:36 AM, RL Budde <rl.b...@googlemail.com> wrote:
>> Hello Frank,
>>
>> again thank you very much for investigating this issue so thoroughly!
> No problem. I'm in the midst of debugging my own cape, so your
> question is particularly convenient to debug at the moment.
>
>> So as the overlay is working with your bone, can you tell me if you are
>> booting from SD or eMMC?
> eMMC
>
>> Are you using the Angstrom distribution or
>> something different? I am using the most recent kernel from Robert Nelson
>> with his Debian Wheezy distribution.
> I'm using buildroot.
>
> The key to loading firmware on boot sounds like it is to have
>
> CONFIG_FIRMWARE_IN_KERNEL=y
>
> in your kernel config and to make sure that your dts is included in
> the list in <kernel>/firmware/Makefile.
>
> Having said this, I've been wanting to turn off the
> CONFIG_FIRMWARE_IN_KERNEL switch to avoid recompiling the kernel each
> change, but I don't know of a good alternative. It might be nice if
> the capemgr could pull the dts off the EEPROM... :)
>
> Frank

AFAIK the kernel is able to load the overlay from the /lib/firmware
directory on
the boot device. The kernel on my Angstrom system is still the original and
the overlay specified by the eeprom on my cape loads properly during boot.
(BTW: Both kernels I'm using have CONFIG_FIRMWARE_IN_KERNEL set.)

Booting wheezy, loading the overlay during boot fails:

[ 3.205727] bone-capemgr bone_capemgr.8: slot #2: Requesting part
number/version based 'BB-BONE-LVDS-01.dtbo
[ 3.225862] bone-capemgr bone_capemgr.8: slot #2: Requesting firmware
'BB-BONE-LVDS-01.dtbo' for board-name 'BeagleBone LVDS LCD CAPE',
version '01'
[ 5.307834] bone-capemgr bone_capemgr.8: failed to load firmware
'BB-BONE-LVDS-01.dtbo'
[ 5.316289] bone-capemgr bone_capemgr.8: loader: failed to load
slot-2 BB-BONE-LVDS:01 (prio 0)

But the same overlay from the startup script does not:

[ 34.581955] bone-capemgr bone_capemgr.8: part_number 'BB-BONE-LVDS',
version '01'
[ 34.621691] bone-capemgr bone_capemgr.8: slot #7: generic override
[ 34.628371] bone-capemgr bone_capemgr.8: bone: Using override eeprom
data at slot 7
[ 34.636457] bone-capemgr bone_capemgr.8: slot #7: 'Override Board
Name,01,Override Manuf,BB-BONE-LVDS'
[ 34.667417] bone-capemgr bone_capemgr.8: slot #7: Requesting part
number/version based 'BB-BONE-LVDS-01.dtbo
[ 34.716072] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware
'BB-BONE-LVDS-01.dtbo' for board-name 'Override Board Name', version '01'
[ 34.781437] bone-capemgr bone_capemgr.8: slot #7: dtbo
'BB-BONE-LVDS-01.dtbo' loaded; converting to live tree
[ 34.831930] bone-capemgr bone_capemgr.8: slot #7: #6 overlays
[ 35.341240] bone-capemgr bone_capemgr.8: slot #7: Applied #6 overlays.

The wheezy kernel also has rootwait as kernel option.

On Angstrom, the overlay loading during boot does work:

[ 3.066941] bone-capemgr bone_capemgr.9: slot #2: Requesting part
number/version based 'BB-BONE-LVDS-01.dtbo
[ 3.066964] bone-capemgr bone_capemgr.9: slot #2: Requesting firmware
'BB-BONE-LVDS-01.dtbo' for board-name 'BeagleBone LVDS LCD CAPE',
version '01'
[ 3.069375] bone-capemgr bone_capemgr.9: slot #2: dtbo
'BB-BONE-LVDS-01.dtbo' loaded; converting to live tree
[ 3.071074] bone-capemgr bone_capemgr.9: slot #2: #6 overlays
[ 3.131523] bone-capemgr bone_capemgr.9: slot #2: Applied #6 overlays.
[ 3.131540] bone-capemgr bone_capemgr.9: loader: done slot-2
BB-BONE-LVDS:01 (prio 0)

I've compared the sources from the capemgr, nothing obvious there.

Still puzzled,

-- Bas

[RL Budde]

Thank you both!

Unfortunately, I was not able to find a solution yet.

My first try, based on Franks idea that the file system might not be ready by that time, was to check the initrd. Checking the image, I found lib/firmware to be non-existent. I created /lib/firmware and copied over my dtbo. Then I reassembled everything using cpio and so on. As stated above - I hab no success yet the linux was booting successfully.

Right now I am stuck and desperately waiting for someone with a better insight on how this stuff works. Koen? Gerald? Robert? Jason? I don't know exactly in whom to ask...

- Where does the capemgr get the dtbo from at boot time?

- How can I add an own dtbo to be loaded at that stage?

Thanks!

Robert

[BeagleInterest]

I had the same problem, eg compiling the dts in the kernel works fine, manual loading is also fine.

 

There must be some other dir that the dtbo files are copied from on boot that is different from /lib/firmware.

 

Something I tested was modifying the LCD dts files.  I changed it so the LED doesn't blink and nothing else.  If I compile into the kernel it's fine but if I copy the new file into /lib/firmware it doesn't work.  Thus my conclusion is the Kernel keeps a separate copy of bootable firmware files somewhere.

[RL Budde]

Yet I still did not succeed...

I compiled a kernel, adding a dts to "firmware/capes" and included it in the firmware/Makefile. This does not help as well. Right now, I don't know where to dig further.

I think this issue should be solved, as if not the whole EEPROM/DTB thing is useless for developing new capes. It sounds so easy and tempting to just place a dtbo under /lib/firmware and get it loaded automatically... Too good to be true I guess...

[Pantelis Antoniou]

Part numbers are separated from revision numbers via ':' and not a dash. Dashes can be included in the part number.

So:

echo ibb:0001 >slots should work; it will try to load ibb-0001.dtbo from /lib/firmware.

echo ibb-0001 >slots instead tries to load ibb-0001-00A0.dtbo since 00A0 is the default revision.

BTW 0001 is not a valid revision; custom has it versions starting at 00A0

Looking at http://www.elinux.org/BeagleBone_and_the_3.8_Kernel I see there's a typo about what

is used to separate the revisions. Fixed now.

Regards

-- Pantelis

[RL Budde]

Hi Pantelis,

Thanks for your help!

Maybe during all my posts the actual problem somehow got unclear:

I am using 00A0 as revision since my second post. There is no problem with that. The problem, to restate it:

- dtbo can be loaded manually AFTER boot time

- dtbo can not be loaded by uEnv.txt NOR by cape eeprom-mechanism!

When I enable manual loading of - for example - BB-UART1 in uEnv.txt, it is loaded. But all dtbos (which are in the lib/firmware dir) which are not appended to the kernel image do NOT work. There is (quite sure) a bug in firmware_class.c, which must have been introduced between kernel versions 3.2 to 3.8 (supposedly 3.7, when a change was made to load firmware appended/embedded with the kernel image). Since that, udev / firmware.agent is not called any mor, but the kernel is looking for the firmware itself. But it looks like this only works for dtbos which are embedded INTO the kernel at compile time.

Check:

- create a simple dts, compile it using dtc

- copy to /lib/firmware

- try to enable it by adding capemgr.extra_override=<yours-dtbo> to uEnv.txt

- kernel won't be able to find it at boot time, yet you can load it after boot time

This guy has the same problem (see "update"): http://hipstercircuits.com/enable-device-tree-overlay-on-startup-on-beaglebone-black/

Thanks,

Robert

[Pantelis Antoniou]

Hi Robert,

We had the same problem before; you shouldn't use extra_override there; you should use
enable_partno. extra_override uses the override slots part in the base DT.

Have you tried using capemgr.enable_partno ?

Regards

-- Pantelis

> --
> For more options, visit http://beagleboard.org/discuss
> ---

> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Iem_mHknIUM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[RL Budde]

Sorry, I was confused: actually, I am using enable_partno:

c&p from my uEnv.txt

optargs=capemgr.enable_partno=cape-bone-ibb,BB-UART1,BB-UART2,BB-UART4

the file cape-bone-ibb-00A0.dtbo exists in /lib/firmware and can be loaded manually (echo cape-bone-ibb > ....). Also tried without the "cape-bone-". Tried without the BB-UART... (which all work!).

Programmed the EEPROM of the cape - also not working (firmware can not be found!).

Baseline: There must be some issue how the kernel (not udev/firmware.agent!) looks for the firmware!

I modified firmware.agent with some extra messages for debugging: As expected with a kernel >3.7, udev/firmware.agent are not used during boot time. Later on, when manually loading the overlay,the firmware.agent is called and checks all the firmware-directories as expected.

Best regards,

Robert

[Pantelis Antoniou]

That's because the in-kernel firmware loader can find the file in the filesystem directly.

This doesn't happen in angstrom, so it's not a kernel issue.

Doesn't debian/ubuntu use an initrd? That's the first rootfs used when booting
and if there's no dtbo in /lib/firmware of the initrd image it obviously won't be found.

Regards

-- Pantelis

P.S. I could use some kernel logs and/or .config of the kernel in question.

[RL Budde]

Hi Pantelis,

I admit its not a generic kernel bug. It's more a Debian kernel bug or how to call it.

The kernel uses a initrd. I decompressed the initrd and added a /lib/firmware directory with my dtbo. Nevertheless, I had no success. From what I can tell the capemgr start looking for the firmware AFTER the initrd is exchanged with the real fs.

Attached you will find the kernel config and a boot log. At the very end of the boot log you see that I can manually load the dtbo which failed during boot time.

Thanks,

Robert

[Pantelis Antoniou]

Just had a quick look, but it appears the there's a bunch of other capes (UART) that
do get loaded.

Your config has:

> CONFIG_PREVENT_FIRMWARE_BUILD=y

While ours:

> # CONFIG_PREVENT_FIRMWARE_BUILD is not set

And on top of that both have CONFIG_FIRMWARE_IN_KERNEL=y

So, that means that your firmware (dtbo files is included in the kernel image)

> config FIRMWARE_IN_KERNEL
> bool "Include in-kernel firmware blobs in kernel binary"
> depends on FW_LOADER
> default y
> help
> The kernel source tree includes a number of firmware 'blobs'
> that are used by various drivers. The recommended way to
> use these is to run "make firmware_install", which, after
> converting ihex files to binary, copies all of the needed
> binary files in firmware/ to /lib/firmware/ on your system so
> that they can be loaded by userspace helpers on request.
>
> Enabling this option will build each required firmware blob
> into the kernel directly, where request_firmware() will find
> them without having to call out to userspace. This may be
> useful if your root file system requires a device that uses
> such firmware and do not wish to use an initrd.
>
> This single option controls the inclusion of firmware for
> every driver that uses request_firmware() and ships its
> firmware in the kernel source tree, which avoids a
> proliferation of 'Include firmware for xxx device' options.
>
> Say 'N' and let firmware be loaded from userspace.
>
>

The UARTs DTBOs are already in there; we enable that option because we need
the DTBO of the emmc cape as our rootfs.

I guess you compile your cape firmware out of kernel; Try to disable this option
and let me know if it picks it up.

Regards

-- Pantelis

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Iem_mHknIUM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

> <bootlog.txt><config-3.8.13-bone24>

[Pantelis Antoniou]

OK, I think I figured out what's going on.

The whole problem stems from the fact that the emmc (which contains your rootfs) is
a cape too; and is optional with a low priority to boot.

So what goes on is:

Kernel boots
Kernel asks for FOO cape without the rootfs being mounted yet.
Loading of FOO cape fails.
After all user-defined capes (which have higher priority) load/fail emmc cape load
Rootfs is mounted, and now ibb can load (but it's already too late).

What's missing is a way to specify a priority while using the enable_partno= option.

For the meanwhile you can build the kernel with built-in firmware; that way the
manager will find out your cape, or you can boot from external mmc which is not
using the cape mechanism at all.

Regards

-- Pantelis

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Iem_mHknIUM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

> <bootlog.txt><config-3.8.13-bone24>

[Pantelis Antoniou]

This should fix the problem on the next release.

https://github.com/pantoniou/linux-bbxm/commit/738e37102bdfbfd065f4f53814df62b896804d90

It's pretty hard to load a dtbo from a rootfs that's not yet mounted...

On Jul 24, 2013, at 4:35 PM, RL Budde wrote:

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Iem_mHknIUM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

> <bootlog.txt><config-3.8.13-bone24>

[RL Budde]

Hello Pantelis,

thank you very much for your work!

Indeed, compiling the firmware into the kernel works as expected. My feeling just was that the overlay-extension was added to relief the user of compiling custom kernels.

Now, enabling by partno works (and with your new patch also without recompiling the kernel!). Yet I was not able to let capemgr detect the right firmware based on the capes EEPROM. I added a mapping with part-number="BB-BONE-IBB" -> dtbo="cape-bone-ibb-00A0.dtbo" to the am335x-bone-common.dtsi but it was not mapped. But this is another issue.

With respect to your fix: How could this be solved for the EEPROM-supported loading of firmware? Again for known capes there could be an additional entry in the mentioned am335x-bone-common.dtsi, but how to allow this for capes purely known by EEPROM-data?

Again, thank you very much for your work.

BTW: As you introduced the "DTify"-patch for the PCA954x: Maybe you aplly this fix as well: https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-capes/EpSgObarwpc

Best regards,

Robert

[Pantelis Antoniou]

Hi there,

On Jul 25, 2013, at 10:36 AM, RL Budde wrote:

> Hello Pantelis,
>
> thank you very much for your work!
>
> Indeed, compiling the firmware into the kernel works as expected. My feeling just was that the overlay-extension was added to relief the user of compiling custom kernels.
>

It was; the case of loading a dtbo from a rootfs on a device that's been created via a dtbo is a case of a chicken & egg problem.
If you booted from external sd card where the mmc device is part of the base dtb you wouldn't have this problem.

> Now, enabling by partno works (and with your new patch also without recompiling the kernel!). Yet I was not able to let capemgr detect the right firmware based on the capes EEPROM. I added a mapping with part-number="BB-BONE-IBB" -> dtbo="cape-bone-ibb-00A0.dtbo" to the am335x-bone-common.dtsi but it was not mapped. But this is another issue.

You don't have to modify the base dts (am335x-bone-common.dtsi) - for your case just name your dts file for your cape
BB-BONE-IBB-00A0.dts, compile it and put it in /lib/firmware as BB-BONE-IBB-00A0.dtbo.

If the EEPROM is probed correctly and the part-number revision fields are correct (BB-BONE-IBB & 00A0 respectively) it should
just work.

>
> With respect to your fix: How could this be solved for the EEPROM-supported loading of firmware? Again for known capes there could be an additional entry in the mentioned am335x-bone-common.dtsi, but how to allow this for capes purely known by EEPROM-data?
>

No need to mofidy am335x-bone-common.dtsi at all.

> Again, thank you very much for your work.
>

My pleasure.

> BTW: As you introduced the "DTify"-patch for the PCA954x: Maybe you aplly this fix as well: https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-capes/EpSgObarwpc
>

OK, noted; should be in the next release.

> Best regards,
> Robert
>

Regards

-- Pantelis

[Pantelis Antoniou]

Hi,

On Jul 25, 2013, at 10:36 AM, RL Budde wrote:

> Hello Pantelis,
>
> thank you very much for your work!
>
> Indeed, compiling the firmware into the kernel works as expected. My feeling just was that the overlay-extension was added to relief the user of compiling custom kernels.
>
> Now, enabling by partno works (and with your new patch also without recompiling the kernel!). Yet I was not able to let capemgr detect the right firmware based on the capes EEPROM. I added a mapping with part-number="BB-BONE-IBB" -> dtbo="cape-bone-ibb-00A0.dtbo" to the am335x-bone-common.dtsi but it was not mapped. But this is another issue.
>
> With respect to your fix: How could this be solved for the EEPROM-supported loading of firmware? Again for known capes there could be an additional entry in the mentioned am335x-bone-common.dtsi, but how to allow this for capes purely known by EEPROM-data?
>

Ugh, ok, now I see what you mean... The chicken and egg problem, but now with EEPROMs...

Let me think about it a bit; sigh...

[RL Budde]

Sorry for keeping on asking:

Now modified the EEPROM to have part-number "cape-bone-ibb" (which is quite long and only is a working-around for the kernel-mapping). The correct cape-bone-ibb-00A0.dtbo is now found/loaded correctly as it is now in my modified kernel.

But still the cape-fw is loaded now in slot 0 (0-3), which is prior to the eMMC (slot 4 by now!). So without compiling the cape-fw in the kernel even with your patch to the "partno"-option AUTOMATIC loading based on the EEPROM won't work!

One option would be not to refer to the cape-fw when using "partno" but to refer to the eMMC-fw and set it to priority -1 or something to explicitly tell the capemgr to load it prior to all other stuff.

Best regards,

Robert

[RL Budde]

Or better: there is a check for conflicts anyway - what about loading the stuff that is "onboard" anyway and just advise people with incompatible capes (which fw is rejected then) to DISABLE the emmc-fw. Would suit much more people from the first start.

[RL Budde]

After thinking about it for a while - really, the onboard-stuff should be loaded first by default and could be disabled by using uEnv.txt on demand. No need for priorities and most users would never notice. Those with conflicting acpes should pay attention anyway.

[Pantelis Antoniou]

No that's not enough.

There's a requirement that the images used for booting are the same both for the emmc & the external sd card.
Using your prescribed method would mean that those images should be different.

I'm working on it, hang on please.

On Jul 25, 2013, at 11:41 AM, RL Budde wrote:

> After thinking about it for a while - really, the onboard-stuff should be loaded first by default and could be disabled by using uEnv.txt on demand. No need for priorities and most users would never notice. Those with conflicting acpes should pay attention anyway.
>

[duarte...@gmail.com]

Hi Guys,

I've been reading your posts and i'm experiencing the same problem. When i try to load my cape from EEPROM it doesn't work but when i do it manually it loads correctly.

I added to my uEnv.txt file the line "optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" and according with my log the cape is recognized and correctly read from EEPROM, also my dtbo file is in lib/firmware but i get a message on log saying that "failed to load firmware" and i don't understand why.

I'm know that you are working on some solutions and i just wanted to leave my case so you know that there are more people suffering from the same problem :) , if you have some ideas of what is happening please let me know.

Thanks.

Duarte

[RL Budde]

Am Donnerstag, 25. Juli 2013 16:28:44 UTC+2 schrieb Pantelis Antoniou:

No that's not enough.

There's a requirement that the images used for booting are the same both for the emmc & the external sd card.
Using your prescribed method would mean that those images should be different.

You will be right - but it is not clear to me. If you change the order of overlays in "both" cases, everything should be fine? For me it is also meanningful that "onboard-extensions" are loaded by default prior to capes?

[Pantelis Antoniou]

All these will be part of something I will put out tomorrow.
There are many ways to accomplish it.

Hang on a bit ..

-- Pantelis

[Pantelis Antoniou]

Hi,

https://github.com/pantoniou/linux-bbxm/commit/66166f29c1cfa5035ba4782266d677b908e81f0e
https://github.com/pantoniou/linux-bbxm/commit/fb99fd668f8baaf4270ce8b2359077dcc9a047aa

This should fix kind of problem when the dtbo is not included in the kernel image.
BTW, if you do have a cape that you submitted to the beagleboard tree, we include it
and from now on it will always be present without those kind of gymnastics.

Regards

-- Pantelis

On Jul 25, 2013, at 10:50 PM, RL Budde wrote:

>
>

[Seth]

I have been reading through the threads here and Googling quite a bit, and it seems as though this is the same sort of problem I am having. I don't have an EEPROM'ed "cape" (custom HW setup) and am instead loading cape firmware via the uEnv.txt file. I see this question is marked as "completed", but I am unsure how to apply the fix to my issue.

It seems to be simple enough to create your own custom dts file, compile it on the Beaglebone with the dtc command and then make sure the resultant dtbo file is in /lib/firmware. In theory that firmware will be loaded the next time you reboot or via manually loading it to /sys/devices/bone_capemgr*/slots, but that process isn't working for me. It seems I'm not the only one having this issue, either.

This particular thread looks promising, but I am not sure how the two patches Pantelis posted fit into a solution. Pantelis says "This should fix kind of problem when the dtbo is not included in the kernel image." which seems to be my issue. Does that mean we still have to recompile the kernel to have our cape firmware changes included? What is the purpose of the /lib/firmware folder in that case? I am pretty new to this and it would be appreciated if Pantelis (or anyone else who's been successful at this) could share how they got their custom dtbo files loaded and working with more detail. Thanks.

[RL Budde]

Hi Pantelis,

is there an estimate how long it will take for this patch to be included in "3rd-party"-kernels such as the one from Robert C. Nelson (http://elinux.org/BeagleBoardDebian)? Sure it depends on the actual author, but is there a generell procedure / time schedule when this will find its way in the repos Robert Nelson is using for his kernels?

Best regards,

Robert

[Carl Johnson]

Seth - did you ever get an answer to your question?  I'm having a similar problem.  My custom .dtbo files (located in /lib/firmware and loaded using enable_partno in uEnv.txt) do get loaded eventually, but only after a 60 second timeout.  I'm wondering if enable_partno isn't a good idea for firmware that isn't compiled into the kernel, and if you should load these files using /sys/devices/bone_capemgr*/slots after boot instead.  I see that there's a config option that allows you to override the 60 second default, but it isn't clear to me if this can be set without a kernel recompile.

FWIW, this functionality worked without delay prior to a round of patches over the last few months.

[Seth]

Unfortunately I have not found (tried) a solution. I assume that "all I need to do" is to recompile the kernel with the updated dtbo file.

This is one more of those times (many with the beaglebone/linux) where I have two options:
A) Try to fix the problem myself (a relatively inexperienced 'beginner') with what usually ends up being days/weeks of struggling on basic things or
B) Wait for the professionals to fix it correctly or wait until someone nice enough who knows what they're doing answers the question people have been asking.
If I choose (A) but the pros end up fixing it, then I've wasted a lot of my time (although hopefully I've learned something from it). If I pick (B) but the pros never get around to it, then again I've wasted a lot of time and then I'm forced to pick A anyway - but at what point do I switch my choice and try to do things myself?

Fortunately I'm not on a strict schedule that would force me to always pick (A) and this time around I've chosen (B). Sorry I can't be of more help. I haven't tried the recompilation myself and I haven't received help from my question yet either. If I do get time to try that process I'll post back here with my results.

[garyamort]

On Friday, August 23, 2013 8:29:27 PM UTC-4, Seth wrote:

This particular thread looks promising, but I am not sure how the two patches Pantelis posted fit into a solution. Pantelis says "This should fix kind of problem when the dtbo is not included in the kernel image." which seems to be my issue. Does that mean we still have to recompile the kernel to have our cape firmware changes included? What is the purpose of the /lib/firmware folder in that case? I am pretty new to this and it would be appreciated if Pantelis (or anyone else who's been successful at this) could share how they got their custom dtbo files loaded and working with more detail. Thanks.

It means that the kernel must be compiled with the two changes Pantelis made in order to work.  Depending on how you are keeping your software image up to date will control whether or not you need to recompile.  I am using Robert Nelson's build image scripts and currently am using the 3.8 kernel with his patches up through version bone28.  Checking the linux source files I do not see those two patches - and checking his 3.8 kernel branch, https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 I don't see the patches so I'm assuming they are not there yet.

[Robert Nelson]

Ahh i see the issue now.

Those patches are disabled..

https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patch.sh#L786

Feel free to enable them and also "tweak" the config, so it doesn't
break loading every cape...

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[zj_fighting]

Hello, guys. I read all your posts but get really confused. I encounter the same problem. I want to overlay the BB-BONE-LCD7-00A0.dtbo file. But unfortunately I got the error message "-sh: echo: write error: No such file or directory". So, I wanna know, did all you guys fix the problem. Thanks a lot.

On Saturday, July 13, 2013 10:33:06 PM UTC+8, RL Budde wrote:

Hi!

I am working on a new Home Automation cape using three uarts (1,2,4). The eeprom is set up according to the current SRM with format A1 and gets read correctly on startup. The device tree overlay was compiled using the patch allowing for overlays (so dtc knows -@ and \plugin\). After that I placed the resulting "ibb-0001.dtbo" in /lib/firmware.

This is what I get on startup:

[    1.619295] bone-capemgr bone_capemgr.8: Baseboard: 'A335BNLT,0A5A,1613BBBK2649'
[    1.627084] bone-capemgr bone_capemgr.8: compatible-baseboard=ti,beaglebone-black
[    1.659113] bone-capemgr bone_capemgr.8: slot #0: 'Home Automation Cape,0001,IBB Robert Budde,ibb'
[    1.698749] bone-capemgr bone_capemgr.8: slot #1: No cape found
[    1.735857] bone-capemgr bone_capemgr.8: slot #2: No cape found
[    1.772966] bone-capemgr bone_capemgr.8: slot #3: No cape found
[    1.779219] bone-capemgr bone_capemgr.8: slot #4: specific override
[    1.785819] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 4
[    1.793855] bone-capemgr bone_capemgr.8: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[    1.804003] bone-capemgr bone_capemgr.8: slot #5: specific override
[    1.810600] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 5
[    1.818633] bone-capemgr bone_capemgr.8: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[    1.828671] bone-capemgr bone_capemgr.8: slot #6: specific override
[    1.835267] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 6
[    1.843302] bone-capemgr bone_capemgr.8: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[    1.853925] bone-capemgr bone_capemgr.8: loader: before slot-0 ibb:0001 (prio 0)
[    1.861713] bone-capemgr bone_capemgr.8: loader: check slot-0 ibb:0001 (prio 0)
[    1.869517] bone-capemgr bone_capemgr.8: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.878378] bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.887249] bone-capemgr bone_capemgr.8: loader: before slot-5 BB-BONELT-HDMI:00A0 (prio 1)
[    1.896016] bone-capemgr bone_capemgr.8: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
[    1.904720] bone-capemgr bone_capemgr.8: initialized OK.
[    1.910323] bone-capemgr bone_capemgr.8: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    1.919173] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    1.941732] bone-capemgr bone_capemgr.8: loader: after slot-0 ibb:0001 (prio 0)
[    1.949423] bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.958196] bone-capemgr bone_capemgr.8: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)
[    1.973258] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    1.982040] bone-capemgr bone_capemgr.8: slot #0: Requesting part number/version based 'ibb-0001.dtbo
[    1.997835] bone-capemgr bone_capemgr.8: slot #0: Requesting firmware 'ibb-0001.dtbo' for board-name 'Home Automation Cape', version '0001'
[    2.829291] bone-capemgr bone_capemgr.8: failed to load firmware 'ibb-0001.dtbo'
[    2.837120] bone-capemgr bone_capemgr.8: loader: failed to load slot-0 ibb:0001 (prio 0)
[    2.845627] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

But - the dtbo exists in /lib/firmware and the rights are ok as well.

I tried to manually enabling the overlay:

root@arm:~# echo ibb-0001 > /sys/devices/bone_capemgr.8/slots
-bash: echo: write error: No such file or directory

(same for just "ibb" or "/lib/firmware/ibb" and so on)

Enabling the BB-UART by this way works as intended.

Do I have to register the dtbo somewhere to get it found?

Thank you very much!

Robert

[dickelbeck]

This thread has been open for about 8 months.

I've got the experience to understand this, and have spent a week looking at it for 3.12.x.
There are two things I am certain of:

1) if you want to debug a hotplug event, you have to be logging it in detail.  firmware loading requests are hotplug events coming from the kernel.  If you are not logging during your debug session, you are guessing.  I use busybox's mdev, and recently augmented the load_firmware() infrastructure to do a decent job logging the hotplug events.

2) The first firmware load event coming from 3.12 has the wrong ACTION verb, it has remove rather than add.  So tend to indicate a bug in this kernel.  Subsequent firmware requests come with the correct action verb, 60 seconds apart.

It is possible that if you only have one firmware DTB to load, that your hotplug script is IGNORING the load request because of the bad ACTION verb.  Unless you are logging it all, while troubleshooting, you are guessing.

In my case there are 3 firmware requests, they all fail.  The first fails because of the bad verb, and the 2nd two fail because the firmware files are missing.  Without logging I would not have known this.

I have two problems to solve now.