Device tree overlays may load manually, but not at boot.

GoogleGroups
1

Dear Forum,

I have now turned the web outside-in to find an answer to this question.
I see a lot of subjects touching the subject, but the answers and suggestions are mostly in the hear-say category and points in different directions putting me off in an endless ghost-hunt.

I have been testing various overlays, some loads without problems, other won’t load but can be manually loaded after boot.
I can even rename an overlay that loads and it stops loading even if the content is identical.
I have changed the sequence of loading proving that the file system is ready at the time of loading.

I have tested the suggested solutions from:
http://elinux.org/BeagleBone_Black_Enable_SPIDEV

The .dtbo files does not load at boot, but can be loaded manually later. And working when loaded!
The boot log gives no clue of what the problem may be.

  • Is it the content of the .dtbo?

  • Is it the name of the .dtbo file?

Please advice
Best regards
Terje Froysa

debian@beaglebone:~$ uname -a
Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux

Boot log showing BB-SPI1-SWP-01 not loading:

debian@beaglebone:~$ dmesg |grep BB-
[ 0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd
[ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI
[ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMIN
[ 0.714324] bone-capemgr bone_capemgr.9: slot #4: ‘Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G’
[ 0.714439] bone-capemgr bone_capemgr.9: slot #5: ‘Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI’
[ 0.714540] bone-capemgr bone_capemgr.9: slot #6: ‘Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN’
[ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number ‘BB-I2C1’, version ‘N/A’, prio ‘0’
[ 0.714653] bone-capemgr bone_capemgr.9: slot #7: ‘Override Board Name,00A0,Override Manuf,BB-I2C1’
[ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number ‘BB-SPI1-SWP-01’, version ‘N/A’, prio ‘0’
[ 0.714762] bone-capemgr bone_capemgr.9: slot #8: ‘Override Board Name,00A0,Override Manuf,BB-SPI1-SWP-01’
[ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN
[ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 BB-I2C1:00A0 (prio 0)
[ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-I2C1:00A0 (prio 0)
[ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-I2C1:00A0 (prio 0)
[ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-I2C1-00A0.dtbo
[ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware ‘BB-I2C1-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo ‘BB-I2C1-00A0.dtbo’ loaded; converting to live tree
[ 0.720710] bone-capemgr bone_capemgr.9: loader: before slot-8 BB-SPI1-SWP-01:00A0 (prio 0)
[ 0.720724] bone-capemgr bone_capemgr.9: loader: check slot-8 BB-SPI1-SWP-01:00A0 (prio 0)
[ 0.720740] bone-capemgr bone_capemgr.9: loader: after slot-8 BB-SPI1-SWP-01:00A0 (prio 0)
[ 0.720754] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-SPI1-SWP-01-00A0.dtbo
[ 0.720770] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware ‘BB-SPI1-SWP-01-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 0.721636] bone-capemgr bone_capemgr.9: loader: done slot-7 BB-I2C1:00A0 (prio 0)
[ 0.721672] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.075899] bone-capemgr bone_capemgr.9: failed to load firmware ‘BB-SPI1-SWP-01-00A0.dtbo’
[ 1.084703] bone-capemgr bone_capemgr.9: loader: failed to load slot-8 BB-SPI1-SWP-01:00A0 (prio 0)
[ 1.094196] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.094214] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.122393] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

Verify overlay not loaded:

root@beaglebone:/home/debian# cat $SLOTS
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-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-I2C1

Manually loading same overlay:
root@beaglebone:/home/debian# echo BB-SPI1-SWP-01 > $SLOTS
root@beaglebone:/home/debian# cat $SLOTS
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-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-I2C1
9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-SWP-01
root@beaglebone:/home/debian# ls /dev |grep spi
spidev1.0

2

Update:
Originally there was a “BB-SPIDEV1-00A0.dtbo” in the /lib/firmware directory.
This file loads when enabled in the uEnv.txt.
The file is unique in the system (checked with find / )
Pin configuration of the pins if no .dtbo is loaded is 0x000027.
Experiments:

  1. Changing the name of the original file (and in the uEnv.txt)
  • The loading fails under boot.1. Compiling the “BB-SPI1-SWP-01-00A0.dts” into a file named “BB-SPIDEV1-00A0.dtbo” and copying it til /lib/firmware.
    This file swaps the D0 and D1 pins.
  • The load works, but the pin configuration is identical with the original file loaded, i.e. D0/D1 are not swapped…??1. Compiling same file into “BB-SPIDEV1-SWP-00A0.dtbo”, cp to /lib/firmware.
    Removing overlay file load in uEnv.txt and loading BB-SPIDEV1-SWP manually.
  • The manual load works and pins configuration is changed, D0/D1 are swapped!
    Can anyone please explain this enigma??
    Is there at all any down-to-earth documentation on this subject except for all the hear-says?

Best regards
Terje Froysa

3

Update:
Originally there was a "BB-SPIDEV1-00A0.dtbo" in the /lib/firmware
directory.

They are "built-into" the kernel, thus any "modifications" to the
files under /lib/firmware/ would be ignored.. thus we removed them, as
they just confused users.

This file loads when enabled in the uEnv.txt.
The file is unique in the system (checked with find / )
Pin configuration of the pins if no .dtbo is loaded is 0x000027.
Experiments:

Changing the name of the original file (and in the uEnv.txt)

The loading fails under boot.

Compiling the "BB-SPI1-SWP-01-00A0.dts" into a file named
"BB-SPIDEV1-00A0.dtbo" and copying it til /lib/firmware.
This file swaps the D0 and D1 pins.

The load works, but the pin configuration is identical with the original
file loaded, i.e. D0/D1 are not swapped...??

Because "BB-SPIDEV1-00A0.dtbo" is built-in, thus the modified version
is not loaded..

Compiling same file into "BB-SPIDEV1-SWP-00A0.dtbo", cp to /lib/firmware.
Removing overlay file load in uEnv.txt and loading BB-SPIDEV1-SWP manually.

The manual load works and pins configuration is changed, D0/D1 are swapped!

It should make sense with the above^

Regards,

4

Thanks for your reply.

We intend to use this BBB professionally and need to change the pin configurations at boot.
From your reply it seem to me that device overlays cannot be used as intended.
We can remove and add predefined modules, but not change them…
Is this really true?
Does that mean that we cannot design a cape with our own ID and corresponding dtbo?

If yes, what will you recommend for us to do to solve the problem?

  • If I generate a complete new am335x-boneblack.dtb, will that do?
  • Or do we have to re-compile the kernel?

Best regards
Terje Froysa

5

Thanks for your reply.

We intend to use this BBB professionally and need to change the pin
configurations at boot.

So the problem is..?

From your reply it seem to me that device overlays cannot be used as
intended.

Define "as intended": the overlays work. So unless you like waiting 2
minutes for udev to find the firmware under /lib/firmware/, they are
going to be "built-in"...

We can remove and add predefined modules, but not change them...
Is this really true?

If "BB-SPIDEV1-00A0.dtbo" is builtin, you can't name something else
that and expect your version to be loaded.. The file "build-in" has
preference..

Does that mean that we cannot design a cape with our own ID and
corresponding dtbo?

submit a patch like everyone else, and we will roll your "cape" in
like everyone else..

If yes, what will you recommend for us to do to solve the problem?

If I generate a complete new am335x-boneblack.dtb, will that do?
Or do we have to re-compile the kernel?

Regards,

6

Thanks again for your quick reply!

With “as intended” I refer to the lecture given at:
http://elinux.org/BeagleBone_Black_Enable_SPIDEV
and many other lectures i have studied made me think that I (anyone) could throw out predefined pin configurations and ad-hoc substitute them with my own in the /lib/firmware directory.

When I find the .dtbo working by placing them /lib/firmware and using "echo .dtbo > $SLOTS, I (of course) get confused when the files are not accepted (and with no explanation) during boot.
The confusion arises (like you say) when no other .dtbo file is accepted during boot but the “built ins” while no information is given but “loading failed”.
Replacing an existing .dtbo and finding that the pins were configured as the origninal file suggests that the content of the /lib/firmware .dtbo’s doesn’t seem to count at all.

I have used some 4-5 working days on this subject convinced that it all had to be my mistake since I couldn’t find any consistent information about this. All documents and lectures on the web seemed to tell that loading custom ad-hoc .dtbo’s by uEnv.txt was feasible.

You are the first to tell me that the Linux cape configurations have to be furnished by anyone but ourselves. We are making a one-of-a-kind cape in a scientific research context. It really shouldn’t be necessary to submit a short-sighted experiment although in professional context. We are doing changes steadily and plan to use BBB in many different activities (also in cooperation with the NTNU, Norwegian University of Technology). I don’t think we will want to overthrow you with numerous patches for different projects.

Well, I’m learning, but knowledge is sometime hard to obtain.
In 1987, as a Unix system responsible, I learned the saying:
“Manuals…? Which manuals…? This is Unix my son, you gotta know!” :slight_smile:

I guess I have to do a script running after boot that loads the .dtbo and reconfigures the pins.

Best regards
Terje Froysa

7

Thanks again for your quick reply!

With "as intended" I refer to the lecture given at:
BeagleBone Black Enable SPIDEV - eLinux.org
and many other lectures i have studied made me think that I (anyone) could
throw out predefined pin configurations and ad-hoc substitute them with my
own in the /lib/firmware directory.

That "works" for the old Angstrom image. I 'can' make it work the same
way with debian, however there will be a 2 minute delay on bootup
thanks to udev on bootup.

When I find the .dtbo working by placing them /lib/firmware and using "echo
<device>.dtbo > $SLOTS, I (of course) get confused when the files are not
accepted (and with no explanation) during boot.
The confusion arises (like you say) when no other .dtbo file is accepted
during boot but the "built ins" while no information is given but "loading
failed".
Replacing an existing .dtbo and finding that the pins were configured as the
origninal file suggests that the content of the /lib/firmware .dtbo's
doesn't seem to count at all.

I have used some 4-5 working days on this subject convinced that it all had
to be my mistake since I couldn't find any consistent information about
this. All documents and lectures on the web seemed to tell that loading
custom ad-hoc .dtbo's by uEnv.txt was feasible.

You are the first to tell me that the Linux cape configurations have to be
furnished by anyone but ourselves. We are making a one-of-a-kind cape in a
scientific research context. It really shouldn't be necessary to submit a
short-sighted experiment although in professional context. We are doing
changes steadily and plan to use BBB in many different activities (also in
cooperation with the NTNU, Norwegian University of Technology). I don't
think we will want to overthrow you with numerous patches for different
projects.

Well, I'm learning, but knowledge is sometime hard to obtain.
In 1987, as a Unix system responsible, I learned the saying:
"Manuals...? Which manuals...? This is Unix my son, you gotta know!" :slight_smile:

I guess I have to do a script running after boot that loads the .dtbo and
reconfigures the pins.

see:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Loading_custom_capes

It's already setup for you to use it in the image.

Regards,

8

Ok, thanks!

I’ll have to cope with that solution.
I really appreciate that you took your time to explain this.
From what I have read from the web, there is a lot of mis-leading information and a lot of confused people (me included).

The nice thing with Linux is that there is always a work-a-round (even if you must construct one yourself).
The draw-back is that the information can be hard to find.

I have been working with embedded programming for over 30 years.
Mostly bottom up with homemade preemtive RTOS and VME VRTX etc. but I am a newbi to Linux though.

Best regards
Terje Froysa

9

Hello,

I’ve had similar problems, and similar frustration with existing instructions.

My workaround was to put this line in /etc/rc.local:

/usr/local/bin/startSPI.sh > /dev/null &

I believe that the output redirect and the & will prevent this line from hanging initiation if anything goes wrong. But I don’t know for sure… (anyone care to comment?)

…and adding a startSPI.sh in /usr/local/bin/ with contents like this:

#!/bin/bash

echo CUSTOM-SPIDEV0 > /sys/devices/bone_capemgr./slots
echo CUSTOM-SPIDEV1 > /sys/devices/bone_capemgr./slots

exit

Note: the shebang line calls /bin/bash not /bin/sh. /bin/sh → /bin/dash in debian and it didn’t like the wild-card * which I believe might be necessary… (anyone care to comment?

I hope this is useful.

Cheers.

10

I get away with it:
https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/capemgr-debian.sh#L19

Regards,

11 
I found this:
<i>"...POSIX says that a non-interactive
shell must not generate pathnames for a redirection; an interactive
shell may do so, provided there is exactly one match.."
</i>

So although:

echo BB-SPIDEV0 > /sys/devices/bone_capemgr.*/slots

might work when you are doing it manually,
you need to do something like this:

#!/bin/sh -e
slots=$(ls /sys/devices/bone_capemgr.*/slots)
echo BB-SPIDEV0 > $slots
echo BB-SPIDEV1 > $slots
exit

to make it run in a plain sh script

12

Thanks for good advice!

I have taken care of the information for my further work.
I will be away for 3 weeks now, so i can’t attend this forum for a while if additional posts are made.

Best regards
Terje Froysa

13

If memory serves me right the following has worked for me with kernel 3.8 - place the dtbo file under lib/firmware inside the initrd.img

It’s a lot quicker and easier than recompiling a kernel.

It’s been a while since I’ve done it that way because I no longer use an initrd.