Cape Device Tree Overlay fails to load during boot?

[Jesper We]

OK, I have read this thread twice now, and I still fail to see any real solution in between the discussion of various patches.

There is a lot of discussion in that thread about custom kernels, but my BB Black has the latest Angstrom eMMC flasher version with everything as default.

I have made a Cape PCB with an RTC and 4 serial ports for UART1,2,4,5. The Cape has an EEPROM at i2c address 0x54 (Slot #0) with the proper part number and revision.
I have disabled the loading of all HDMI overlay features in uEnv.txt.

On exactly the same board I can swap out my Cape for the Circuitco RS232 cape which I have a couple of. It has the .dto files already in /lib/firmware in the distro.
That DTO loads fine during boot, with the same priority (0) as my cape.
So it's not an issue of the eMMC not being ready.

However, the Circuitco Rs232 Capes are loaded earlier in the boot process than the point at which my cape fails. Since my DTO is just a merge of the original RS232 UARTs DTOs from the distro, I cannot understand why...

So my questions are:
- Why is the failure to load my cape coming much later in the boot process than the Circuitco cape's success?
- Is there any way to know why the boot time loading fails, when the cape loads fine manually?

See below fore some transcripts. The source for my DTO is enclosed.

/jesper

root@beaglebone:~# ls -l /lib/firmware/CP*
-rw-r--r-- 1 root root 1969 Nov 14 19:15 /lib/firmware/CP-CLOUDSAFE-00A0.dtbo
-rwxr-xr-x 1 root root 2117 Nov 14 19:13 /lib/firmware/CP-CLOUDSAFE-00A0.dts

Loading the DTO manually works fine:

root@beaglebone:/lib/firmware# echo CP-CLOUDSAFE >/sys/devices/bone_capemgr.8/slots
root@beaglebone:/lib/firmware# dmesg
....
[  200.937688] bone-capemgr bone_capemgr.8: part_number 'CP-CLOUDSAFE', version 'N/A'
[  200.937766] bone-capemgr bone_capemgr.8: slot #7: generic override
[  200.937786] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 7
[  200.937803] bone-capemgr bone_capemgr.8: slot #7: 'Override Board Name,00A0,Override Manuf,CP-CLOUDSAFE'
[  200.937896] bone-capemgr bone_capemgr.8: slot #7: Requesting part number/version based 'CP-CLOUDSAFE-00A0.dtbo
[  200.937915] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware 'CP-CLOUDSAFE-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[  200.947556] bone-capemgr bone_capemgr.8: slot #7: dtbo 'CP-CLOUDSAFE-00A0.dtbo' loaded; converting to live tree
[  200.947984] bone-capemgr bone_capemgr.8: slot #7: #5 overlays
[  200.954890] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1
[  200.958878] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP UART2
[  200.964739] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
[  200.970604] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP UART5
[  200.974945] bone-capemgr bone_capemgr.8: slot #7: Applied #5 overlays.
....
root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots
 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
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,CP-CLOUDSAFE

But when rebooting the board it will not load:

Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: Baseboard: 'A335BNLT,0A5C,2713BBBK1211'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: compatible-baseboard=ti,beaglebone-black
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: Skipping disabled cape with part# BB-BONELT-HDMI
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: Skipping disabled cape with part# BB-BONELT-HDMIN
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #0: 'Cloudsafe IO Cape,00A0,Cashpro AB,CP-CLOUDSAFE'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #1: No cape found
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #2: No cape found
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #3: No cape found
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #4: specific override
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 4
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #5: specific override
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 5
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #6: specific override
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 6
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: Skipping loading of disabled cape with part# BB-BONELT-HDMI
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: Skipping loading of disabled cape with part# BB-BONELT-HDMIN
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: before slot-0 CP-CLOUDSAFE:00A0 (prio 0)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: check slot-0 CP-CLOUDSAFE:00A0 (prio 0)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: initialized OK.
Jan 01 00:01:02 beaglebone kernel: OneNAND driver initializing
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: after slot-0 CP-CLOUDSAFE:00A0 (prio 0)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #0: Requesting part number/version based 'CP-CLOUDSAFE-00A0.dtbo
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #0: Requesting firmware 'CP-CLOUDSAFE-00A0.dtbo' for board-name 'Cloudsafe IO Cape', version '00A0'  

// <--- This is the point where for example the RS232 cape loads successfully. Why is my cape not loaded here????

Jan 01 00:01:02 beaglebone kernel: usbcore: registered new interface driver asix
Jan 01 00:01:02 beaglebone kernel: usbcore: registered new interface driver cdc_ether
Jan 01 00:01:02 beaglebone kernel: usbcore: registered new interface driver smsc95xx
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

// ...skip ~100 lines of boot transcript here, to get to the point where the load fails...

Jan 01 00:01:02 beaglebone kernel: ALSA device list:
Jan 01 00:01:02 beaglebone kernel:   No soundcards found.
Jan 01 00:01:02 beaglebone kernel: Waiting for root device /dev/mmcblk0p2...
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: failed to load firmware 'CP-CLOUDSAFE-00A0.dtbo'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: failed to load slot-0 CP-CLOUDSAFE:00A0 (prio 0)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #4: #2 overlays
Jan 01 00:01:02 beaglebone kernel: of_get_named_gpio_flags: can't parse gpios property
Jan 01 00:01:02 beaglebone kernel: of_get_named_gpio_flags: can't parse gpios property

[David Marquart]

I am preoccupied today, but this is what I am going to try for the exact same situation that you have.
http://hipstercircuits.com/enable-device-tree-overlay-on-startup-on-beaglebone-black/

Hope it helps.

[Jesper We]

Yes it seems lots of people are in the same situation. OK, so despite all the halabaloo about Device Tree Overlays you still need to build a custom kernel to add a new cape at boot, is that so?
I kind of thought the whole point was getting rid of that ;-)

[Don deJuan]

> --
> 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.
really depends on how you kernel is built.

Say for Arch linux you would have to install linux-am33x-legacy
dtc-overlay to get it working. Which is the 3.8.* kernel ..

If you happen to be on the 3.12.* kernel you will have cape problems it
seems right now at least that is what I have run into as of recent.

Though I did end up just running my own kernel, this does work
http://www.adminempire.com/beaglebone-basics-for-arch-linux/

[Jesper We]

OK, I bit the bullet and went through the custom kernel build process.
Put my .dts in kernel/firmware/capes/ and added it to the kernel/firmware/MakefileDTO

...and so it works.

Conclusion: The reason the Circuitco Capes work is that they are already compiled into the standard distribution.
The appearance of the .dts and .dtbo files in /etc/firmware of the standard distro is just for shows, this is not the files that are actually used at boot.

Obviously the whole DTO+Cape EEPROM scheme has some flaws to be worked out...

[Robert Nelson]

You can also just disable the kernel config switch for building
firmware inside the kernel. Then the files in /lib/firmware/ will be
used directly..

Regards,

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

[Jesper We]

Really :-) ? This is all it takes to make it work as advertised? Makes me wonder why that is not in the default distribution...

[Jesper We]

Robert, after much headscratching at the various Angstrom download and instruction pages, which seem to be in various stages of bit-rot, I switched my attention to your stuff, which seems a lot more well maintained.

I'm now using omap-image-builder to create an image. I have chosen to work with Ubuntu raring.
I was hoping to recreate the process to build your posted flashers, such as:

https://rcn-ee.net/deb/flasher/raring/BBB-eMMC-flasher-ubuntu-13.04-2013-10-08.img

...which has a working usb0 network interface and does flash the eMMC when booted with the user button pressed.

I use the following commands:

cd omap-image-builder
./build-image.sh
cd deploy/ubuntu-13.04-console-armhf-2013-11-17
./setup_sdcard.sh --img cs-installer.img --uboot bone --bbb-flasher
dd bs=1M if=cs-installer.img of=/dev/sdb

Now booting from this SD-Card works, but I get no usb0 network interface.
And there is a file called flash-eMMC.txt on the card, but it does not flash if booted while holding the user button pressed.

What am I missing here?

[Charles Steinkuehler]

You don't _have_ to recompile the kernel.

You can directly merge your overlay with the board device tree (in other
words, it is no longer an overly, it is just part of the native board
resources). Just drop the new device tree file onto your system
wherever uboot is pulling it from (varies depending on the release
you're running) and your hardware will be recognized at the earliest
possible time (well, unless you start hacking on uboot).

As others pointed out, you can also get the kernel to load the files
from /lib/firmware, but this requires that /lib/firmware is already
mounted and the files are visible when the kernel is trying to find the
overlays. Depending on your boot sequence and kernel settings, this may
or may not work.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

Check out:
/boot/uboot/debug/flash-eMMC.log

to see if something error'ed out, as the flashing script logs
everything in that file...

[Jesper We]

Actually, staring a bit more at the build logs I see an error from the build_image.sh run that causes both my problems.
Towards the end, in chroot.sh/startup_script(), qemu segfaults while git clone-ing the boot scrips, see log excerpt below.
I'm running Ubuntu 13.10 with version "QEMU emulator version 1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)"
I'm trying to think a way around this, but running under qemu makes things a bit more complicated...

Log: (chroot) Ubuntu: setting up locales: [en_US.UTF-8]
Generating locales...
  en_US.UTF-8... done
Generation complete.
Log: (chroot) adding admin group to /etc/sudoers
passwd: password expiry information changed.
Cloning into '/opt/boot-scripts'...
qemu: Unsupported syscall: 374
remote: Counting objects: 65, done.
remote: Compressing objects: 100% (60/60), done.
remote: Total 65 (delta 26), reused 44 (delta 5)
Receiving objects: 100% (65/65), 8.00 KiB, done.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
error: index-pack died of signal 11
fatal: index-pack failed
/bin/chown: cannot access '/opt/boot-scripts/': No such file or directory
qemu: Unsupported syscall: 374
2013-11-18 05:11:19 URL:http://rcn-ee.net/deb/raring-armhf/v3.12.0-armv7-x8/ [1327/1327] -> "/tmp/index.html" [1]
Log: Using: 3.12.0-armv7-x8

[Seth]

I just read this thread and thought "wow, this is the same set of experiences I've had over the last couple months."

"OK, I have read this thread twice now, and I still fail to see any real solution in between the discussion of various patches." - me too. As can be seen I also appear in that thread asking questions.
"I have made a Cape PCB..."- me too (basically).
"I have disabled the loading of all HDMI overlay features in uEnv.txt." - me too.
"Yes it seems lots of people are in the same situation." - looks that way to me too.
"OK, so despite all the halabaloo about Device Tree Overlays you still need to build a custom kernel to add a new cape at boot, is that so? I kind of thought the whole point was getting rid of that ;-)" - my thoughts exactly ("...I thought the nice thing about the 'cape' concept was that you were supposed to be able to basically plug them in...and they would work").
"OK, I bit the bullet and went through the custom kernel build process." - me too, after waiting patiently for a fix or other solutions.
"Robert, after much headscratching at the various Angstrom download and instruction pages, which seem to be in various stages of bit-rot..." - Agreed. It's difficult to find instructions online that are up-to-date. Spending hours traveling down the wrong path becomes frustrating after you do it multiple times.
"...I switched my attention to your stuff, which seems a lot more well maintained." - me too at first (especially after I found a post where Robert said he had taken over pushing changes to the beaglebone fork or something along those lines, and of course I can't find it now, but it made me think that was the best way to keep up-to-date), although I got stuck and am back to using the angstrom-distribution "setup-scripts" method (which seems to be working so far). I am still unsure when a person is supposed to use Robert's instructions versus the angstrom-distribution method.

Just today I think I've made progress in this area after trying for several days over the last couple months. I think I have to figure out how to title my questions on Google Groups so people are more likely to answer them. I tried changing my question-asking strategy to a higher-level question (most recent example) so more people would feel they could answer, but not even that seems to work. Or maybe it's just the weekend, I'm not sure.

At any rate, I just wanted to chime in to make it known that there are definitely others with very similar issues regarding capes. I continue to appreciate the help the forums and lists provide and the work and support of the professionals currently involved with the development of the Beaglebone. I hope we all can get our projects working without too much additional struggle.

Cheers!

[Jesper We]

I tried to replace qemu 1.5 with a locally built qemu 1.6.1, and run build_image.sh.

This gives me:

Cloning into '/opt/boot-scripts'...
qemu: Unsupported syscall: 374
remote: Counting objects: 65, done.
remote: Compressing objects: 100% (60/60), done.
remote: Total 65 (delta 26), reused 44 (delta 5)
Receiving objects: 100% (65/65), 8.00 KiB, done.

*** stack smashing detected ***: /usr/lib/git-core/git terminated
qemu: uncaught target signal 6 (Aborted) - core dumped
error: index-pack died of signal 6

[Robert Nelson]

Run it native... qemu is always full of bugs, i NEVER release a build
via x86/qemu they are alll built on arm hardware..

[Andreas Tauböck]

Hy,

I´m having a very similar problem. I am using the current version of ubuntu for BBB (Ubuntu 14.04 LTS (GNU/Linux 3.8.13-bone47 armv7l)) and tried to a device tree overlay with this guide for the exact same cape: http://the8thlayerof.net/2013/10/28/canbus-beagle-bone-black-as-a-canbus-data-logger-part-2/

However the dmesg output says the loading fails:

[    2.011897] bone-capemgr bone_capemgr.9: loader: before slot-3 TT3201-001:05 (prio 0)
[    2.020116] bone-capemgr bone_capemgr.9: loader: check slot-3 TT3201-001:05 (prio 0)
[    2.042227] bone-capemgr bone_capemgr.9: loader: after slot-3 TT3201-001:05 (prio 0)
[    2.062825] bone-capemgr bone_capemgr.9: slot #3: Requesting part number/version based 'TT3201-001-05.dtbo
[    2.093253] bone-capemgr bone_capemgr.9: slot #3: Requesting firmware 'TT3201-001-05.dtbo' for board-name 'TT3201 CAN Bus Cape', version '05'
[    2.901230] bone-capemgr bone_capemgr.9: failed to load firmware 'TT3201-001-05.dtbo'
[    2.909494] bone-capemgr bone_capemgr.9: loader: failed to load slot-3 TT3201-001:05 (prio 0)

and I get a permission denied when i want to add it manually with:

ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo echo TT3201:001 >slots
-bash: slots: Permission denied

There are plenty of people having this problem but i could not find a good solution yet as it should not happen in newer releases anymore.

I appreciate any help???

Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8:<span style="color: #000;" c

...

[Charles Steinkuehler]

On 4/25/2014 5:37 AM, Andreas Tauböck wrote:
>
> and I get a permission denied when i want to add it manually with:
>
> ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo echo TT3201:001 >slots
> -bash: slots: Permission denied

The redirect happens before the sudo, try:

sudo su -c "echo TT3201:001 > slots"

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

I think sudo -S <command> might work too, but have not tested this myself yet.

--
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/d/optout.

[Andreas Tauböck]

Well, neither of them works:

ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo su -c "echo TT3201:001 > slots"
[sudo] password for ubuntu:
bash: line 0: echo: write error: No such file or directory
ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo -S "echo TT3201:001 > slots"
sudo: echo TT3201:001 > slots: command not found
ubuntu@arm:/sys/devices/bone_capemgr.9$

Does someone know how to "disable the kernel config switch for building firmware inside the kernel" as Robert mentioned in a prior post to force the BBB to load the .dtbo from /lib/firmware?

[Robert Nelson]

On Mon, Apr 28, 2014 at 8:26 AM, Andreas Tauböck
<andreas....@gmail.com> wrote:
> Well, neither of them works:
>
> ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo su -c "echo TT3201:001 > slots"
> [sudo] password for ubuntu:
> bash: line 0: echo: write error: No such file or directory
> ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo -S "echo TT3201:001 > slots"
> sudo: echo TT3201:001 > slots: command not found
> ubuntu@arm:/sys/devices/bone_capemgr.9$
>
> Does someone know how to "disable the kernel config switch for building
> firmware inside the kernel" as Robert mentioned in a prior post to force the
> BBB to load the .dtbo from /lib/firmware?

Come on guys this syntax has been stated many times before..

sudo sh -c "echo 'something' >> /etc/privilegedfile"

So:

sudo sh -c "echo TT3201:001 > slots"

root@beaglebone:/sys/devices/bone_capemgr.9# dmesg | tail
[ 293.946886] bone-capemgr bone_capemgr.9: slot #10: Requesting part
number/version based 'TT3201-001.dtbo
[ 293.956807] bone-capemgr bone_capemgr.9: slot #10: Requesting
firmware 'TT3201-001.dtbo' for board-name 'Override Board Name',
version '001'
[ 293.983577] bone-capemgr bone_capemgr.9: failed to load firmware
'TT3201-001.dtbo'
[ 356.556506] bone-capemgr bone_capemgr.9: part_number 'TT3201', version '001'
[ 356.574682] bone-capemgr bone_capemgr.9: slot #11: generic override
[ 356.581469] bone-capemgr bone_capemgr.9: bone: Using override
eeprom data at slot 11
[ 356.589754] bone-capemgr bone_capemgr.9: slot #11: 'Override Board
Name,001,Override Manuf,TT3201'
[ 356.605950] bone-capemgr bone_capemgr.9: slot #11: Requesting part
number/version based 'TT3201-001.dtbo
[ 356.620992] bone-capemgr bone_capemgr.9: slot #11: Requesting
firmware 'TT3201-001.dtbo' for board-name 'Override Board Name',
version '001'
[ 356.670369] bone-capemgr bone_capemgr.9: failed to load firmware
'TT3201-001.dtbo'


added to faq;

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

haven't had my coffee so it's a little terse, any authors in the house?

[Charles Steinkuehler]

On 4/28/2014 8:40 AM, Robert Nelson wrote:

> firmware 'TT3201-001.dtbo' for board-name 'Override Board Name',
> version '001'
> [ 356.670369] bone-capemgr bone_capemgr.9: failed to load firmware
> 'TT3201-001.dtbo'

Note that this is the exact filename it's looking for in /lib/firmware,
and based on your error I'd say it doesn't exist (or is not readable).

How about posting the results of "ls -l /lib/firmware/TT*'

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Mon, Apr 28, 2014 at 8:43 AM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 4/28/2014 8:40 AM, Robert Nelson wrote:
>
>> firmware 'TT3201-001.dtbo' for board-name 'Override Board Name',
>> version '001'
>> [ 356.670369] bone-capemgr bone_capemgr.9: failed to load firmware
>> 'TT3201-001.dtbo'
>
> Note that this is the exact filename it's looking for in /lib/firmware,
> and based on your error I'd say it doesn't exist (or is not readable).
>
> How about posting the results of "ls -l /lib/firmware/TT*'

very true, so the second problem..

root@beaglebone:/sys/devices/bone_capemgr.9# cp
/lib/firmware/TT3201-001-01.dtbo /lib/firmware/TT3201-001-01-00A0.dtbo
root@beaglebone:/sys/devices/bone_capemgr.9# sudo sh -c "echo
TT3201-001-01 > slots"
root@beaglebone:/sys/devices/bone_capemgr.9# dmesg | tail
[ 1049.947337] bone-capemgr bone_capemgr.9: failed to load firmware
'TT3201-001-01-00A0.dtbo'
[ 1071.409157] bone-capemgr bone_capemgr.9: part_number
'TT3201-001-01', version 'N/A'
[ 1071.427985] bone-capemgr bone_capemgr.9: slot #14: generic override
[ 1071.434734] bone-capemgr bone_capemgr.9: bone: Using override
eeprom data at slot 14
[ 1071.443014] bone-capemgr bone_capemgr.9: slot #14: 'Override Board
Name,00A0,Override Manuf,TT3201-001-01'
[ 1071.461413] bone-capemgr bone_capemgr.9: slot #14: Requesting part
number/version based 'TT3201-001-01-00A0.dtbo
[ 1071.474908] bone-capemgr bone_capemgr.9: slot #14: Requesting
firmware 'TT3201-001-01-00A0.dtbo' for board-name 'Override Board
Name', version '00A0'
[ 1071.490681] bone-capemgr bone_capemgr.9: slot #14: dtbo
'TT3201-001-01-00A0.dtbo' loaded; converting to live tree
[ 1071.503738] bone-capemgr bone_capemgr.9: slot #14: TT3201-001-01
conflict P9.25 (#5:BB-BONELT-HDMI)
[ 1071.513483] bone-capemgr bone_capemgr.9: slot #14: Failed verification

Looks like we should rename "TT3201-001-01.dtbo" as it doesn't fit the
current cape loading syntax..

[maxmike]

Yes - same problem here; I just added the echo > $SLOTS script to /etc/profile to walk around all this.