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

GoogleGroups
1

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

2

Hi Robert,

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)

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

3

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

4

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

5

Hi Robert,

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 (Redirecting to Google Groups) -
is gives the same error.

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

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)

6

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

7

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

8

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... :slight_smile:

Frank

9

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... :slight_smile:

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

10

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

11

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.

12

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…

13

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

Τη Τρίτη, 23 Ιουλίου 2013 12:24:04 μ.μ. UTC+3, ο χρήστης RL Budde έγραψε:

14

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= 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

15

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

16

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

17

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.

18

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

config-3.8.13-bone24 (106 KB)

bootlog.txt (33.5 KB)

19

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

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

20

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