capemgr_partno does not load overlay, no message in kernel logs

I cannot get my Beaglebone to load my DTS at boot. Does not work for me, no way, no how. I’ve been keeping up with the latest Angstrom build on my Beaglebone White since last Thursday, when Pantellis released his enable_partno kernel option.

Consider this device tree, attached, BB-NTPD. It exists in /lib/firmware/BB-NTPD-00A0.dtbo on my BB White. For now it only loads UART2.
When I load it with echo BB-NTPD > /sys/devices/bone_capemgr.7/slots
it will load the overlay.

But in uEnv.txt on the boot volume I have
and nothing else.

/proc/cmdline gives:
console=ttyO0,115200n8 capemgr.partno_enable=BB-NTPD root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

So I know the argument is getting through to the kernel. But after that, nothing.
All I get is the normal messages from capemgr reporting the slots loaded (there are no capes on the board).
No /dev/ttyO1 whatsoever until I load it manually through bone_capemgr.7/slots.

I can load any DTBO file I have. Won’t make a difference.

Is anyone running 3.8.13 who has gotten this working? Do you have an old (White) BB or a Black? Most importantly, what does dmesg report? How soon does the capemgr driver report an overlay? Does it report broken, unreachable or nonsensical DTB’s? How would I know if capemgr even sees my arguments?

I’m only a little bitter because I have been on this for a week, and I was so hopeful when Pantellis fixed it, or so I thought.


Dave M.

BB-NTPD.dts (1.63 KB)

OK, I have it working. No changes to the attached file.

In uEnv.txt enter:

optargs=quiet run_hardware_tests capemgr.partno_enable=BB-NTPD

Note the bolded part. There’s no excuse for getting partno_enable and enable_partno confused but I’m not surprised. I don’t think run_hardware_tests have anything to do with capemgr, but it’s in Robert Nelson’s uEnv, so it is in mine.

Dmesg will show something like:

[ 0.251108] bone-capemgr bone_capemgr.7: Baseboard: ‘A335BONE,00A6,2712BB0003
[ 0.251147] bone-capemgr bone_capemgr.7: compatible-baseboard=ti,beaglebone
[ 0.281225] bone-capemgr bone_capemgr.7: slot #0: No cape found
[ 0.318331] bone-capemgr bone_capemgr.7: slot #1: No cape found
[ 0.355440] bone-capemgr bone_capemgr.7: slot #2: No cape found
[ 0.392550] bone-capemgr bone_capemgr.7: slot #3: No cape found
[ 0.398825] bone-capemgr bone_capemgr.7: enabled_partno part_number ‘BB-NTPD’, version 'N/A’
[ 0.398851] bone-capemgr bone_capemgr.7: slot #4: generic override
[ 0.398879] bone-capemgr bone_capemgr.7: bone: Using override eeprom data at slot 4
[ 0.398908] bone-capemgr bone_capemgr.7: slot #4: 'Override Board Name,00A0,Override Manuf,BB-NTPD’
[ 0.399364] bone-capemgr bone_capemgr.7: initialized OK.
[ 0.401376] OneNAND driver initializing

And now you know. “Knowing is half the bat…”, oh forget it. :slight_smile:

I'm pretty sure run_hardware_tests is a test/thing for CircuitCo/Angstrom/etc..


I’ve been fighting with a similar issue. But, neither “capemgr.enable_partno=Kastle-V6T” nor “capemgr.partno_enable=Kastle-V6T” works for me. “echo Kastle-V6T >/sys/devices/bone_capemgr.9/slots” works.

What’s different is that I’m running Ubuntu 12.04, not Angstrom. Linux kernel is 3.8.13. (I got this setup from

My optargs says: “optargs=fixrtc capemgr.partno_enable=Kastle-V6T” and that is evident in dmesg:
[ 0.000000] Kernel command line: console=ttyO0,115200n8 fixrtc capemgr.partno_enable=Kastle-V6T root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

But, none of the capemgr logs bears mention of Kastle-V6T. It’s as if the option weren’t there.

Upgrade your kernel, that feature wasn't enable till 3.8.13-bone21...

Normally i'd say

sudo /bin/bash

to upgrade, but the author of the images decided to go on
his own direction for the partition layout, so i have no idea if
that'll even work.. So if it failes, here's an image with that
already enabled:


Ah, thanks good sir. I’ll get the new kernel then.

Okay, I got it.

The image from had a tiny FAT12 boot partition. So tiny, in fact, that the script ran out of space. So I tarred out the partitions’ contents, and created two new partitions of respectable size (and FAT16 this time).

After booting my resized system, the script ran without error. When I rebooted, uname -a still said “bone20” not “bone23”. It turned out that the symbolic link /boot/zImage was still pointed at vmlinuz-3.8.13-bone20. I fixed that link:

cd /boot; rm zImage; ln -s vmlinuz-3.8.13-bone23 zImage

Now it’s up and calling itself bone23.