Beaglebone and the 3.8 Kernel (Repost)

Hello there,

In light of all the confusion about the new kernel of the beaglebone we’ve taken some time off our really busy schedule and put up a detailed explanation about how the new kernel works, what is different with 3.8, what changes Device Tree mandated, as well as how cape manager can be used.

This is a live document, so let me know if you have any additions, can’t figure out something etc.

Our intention is to have a set of blessed documents that will contain authoritative answers about any questions you might have.

The document is at:

https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub

Regards

– Pantelis

P.S. Sorry for the reposts but google groups seems to be going nuts.

You're a mensch!

I do have a question on boot time overlay loading.

I'm making an NTP server from the original Beaglebone with a proto cape (so no eeprom). The board has an assortment of devices like a serial port for a GPS, an external i2c RTC module, a few LED's, an OLED display and assorted GPIO's. (Yes, everything is either 3.3v friendly or it's buffered or driven from external hardware.)

The 3.8 kernel might support all my hardware with device trees! Excellent! So I'm writing an overlay--call it BB-NTPD-00A0.dtbo.

From U-Boot, how do I pass my DTB to the kernel? I tried variations of these arguments in my uEnv.txt:

Setenv bootargs {$bootargs} capemgr.extra_override=BB-NTPD:00A0

I've not gotten Linux to see this--the command does not show in /proc/cmdline. My DTB overlay would enable UART2, but it does not show up in /dev either. Mind, the DTB loads fine when I do it manually after boot. I'm using the latest Angstrom.

I'm going by the documentation you originally wrote up for capemgr in the kernel sources. It specifies the kernel argument as "capemgr.extra_override" while Google Docs show it as "capemgr.extra-override". Which is it?

Ultimately I just want to know the best way to load my device tree as early in the boot as I can get it. How can I do this?

Your documentation is an excellent start!

OK, I have a partial update. I am passing additional kernel arguments through the optargs environment variable in U-Boot. To load a file called BB-NTPD-00A0, which is in my root under /lib/firmware, I have put this in uEnv.txt:

optargs=capemgr.extra_override=BB-NTPD-00A0

I’ve not gotten my overlay to load on boot. A few weeks ago, when I decided to move from the 3.2 kernel to the 3.8 kernel to get the configuration tax out of the way, I read of someone on this list sort of handwave that one could use uEnv.txt to load an overlay, but I never found the details despite a lot of searching here.

Now it seems one can pass arbitrary, module-specific arguments through uEnv, but I still don’t have my overlay. I wonder what’s happening here. While I can use systemd to load the overlay, it would be technically preferable to have my overlay activated at boot as I have the PPS timing support in my kernel and the sooner the kernel can see my hardware, the better.

Regards,

Dave M.

Hi there,

OK, I have a partial update. I am passing additional kernel arguments through the optargs environment variable in U-Boot. To load a file called BB-NTPD-00A0, which is in my root under /lib/firmware, I have put this in uEnv.txt:

optargs=capemgr.extra_override=BB-NTPD-00A0

optargs=capemgr.extra_override=BB-NTPD:00A0
Note the ':'

Since this is revision 00A0 you can omit the :00A0 part.

i.e. capemgr.extra_override=BB-NTPD

It will try to load the /lib/firmware/BB-NTPD-00A0.dtbo file

You should see the capemgr log that reports that.

I've not gotten my overlay to load on boot. A few weeks ago, when I decided to move from the 3.2 kernel to the 3.8 kernel to get the configuration tax out of the way, I read of someone on this list sort of handwave that one could use uEnv.txt to load an overlay, but I never found the details despite a lot of searching here.

Now it seems one can pass arbitrary, module-specific arguments through uEnv, but I still don't have my overlay. I wonder what's happening here. While I can use systemd to load the overlay, it would be technically preferable to have my overlay activated at boot as I have the PPS timing support in my kernel and the sooner the kernel can see my hardware, the better.

Regards,

Dave M.

I would suggest to put the kernel log someplace like pastebin when you have problems, and then link from your email.

Have fun.

-- Pantelis

I’m also wondering how to load device tree overlays at boot. For example, I put the following in uEnv.txt:

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI capemgr.extra_override=BB-SPI0

If I then check the logs, I see that the HDMI cape is disabled, but I see no entries for an attempt to load the virtual SPI0 cape in /lib/firmware:

dmesg | grep cape

[ 0.000000] Kernel command line: console=ttyO0,115200n8 quiet capemgr.disable_partno=BB-BONELT-HDMI capemgr.extra_override=BB-SPI0 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
[ 0.251333] bone-capemgr bone_capemgr.9: Baseboard: ‘A335BNLT,0A5A,1613BBBK0496’
[ 0.251371] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black
[ 0.251441] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI
[ 0.281830] bone-capemgr bone_capemgr.9: slot #0: No cape found
[ 0.318939] bone-capemgr bone_capemgr.9: slot #1: No cape found
[ 0.356047] bone-capemgr bone_capemgr.9: slot #2: No cape found
[ 0.393155] bone-capemgr bone_capemgr.9: slot #3: No cape found
[ 0.399455] bone-capemgr bone_capemgr.9: slot #4: specific override
[ 0.399500] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4
[ 0.399530] bone-capemgr bone_capemgr.9: slot #4: ‘Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G’
[ 0.399672] bone-capemgr bone_capemgr.9: slot #5: specific override
[ 0.399710] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5
[ 0.399738] bone-capemgr bone_capemgr.9: slot #5: ‘Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI’
[ 0.400017] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 0.400218] bone-capemgr bone_capemgr.9: initialized OK.
[ 0.404911] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.404939] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.404967] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.405004] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware ‘cape-bone-2g-emmc1.dtbo’ for board-name ‘Bone-LT-eMMC-2G’, version ‘00A0’
[ 0.405034] bone-capemgr bone_capemgr.9: slot #4: dtbo ‘cape-bone-2g-emmc1.dtbo’ loaded; converting to live tree
[ 0.405346] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
[ 0.405648] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
[ 0.405674] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

I can load it manually with the following command though:

echo BB-SPI0 > /sys/devices/bone_capemgr.9/slots

dmesg | grep cape


[ 133.404053] bone-capemgr bone_capemgr.9: part_number ‘BB-SPI0’, version ‘N/A’
[ 133.404130] bone-capemgr bone_capemgr.9: slot #6: generic override
[ 133.404148] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6
[ 133.404166] bone-capemgr bone_capemgr.9: slot #6: ‘Override Board Name,00A0,Override Manuf,BB-SPI0’
[ 133.404271] bone-capemgr bone_capemgr.9: slot #6: Requesting part number/version based 'BB-SPI0-00A0.dtbo
[ 133.404288] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware ‘BB-SPI0-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 133.404316] bone-capemgr bone_capemgr.9: slot #6: dtbo ‘BB-SPI0-00A0.dtbo’ loaded; converting to live tree
[ 133.404556] bone-capemgr bone_capemgr.9: slot #6: #2 overlays
[ 133.411776] bone-capemgr bone_capemgr.9: slot #6: Applied #2 overlays.

This is in the latest Angstrom kernel (3.8.13-r23a.13).

Hi Carl,

I'm also wondering how to load device tree overlays at boot. For example, I put the following in uEnv.txt:

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI capemgr.extra_override=BB-SPI0

If I then check the logs, I see that the HDMI cape is disabled, but I see no entries for an attempt to load the virtual SPI0 cape in /lib/firmware:

# dmesg | grep cape
[ 0.000000] Kernel command line: console=ttyO0,115200n8 quiet capemgr.disable_partno=BB-BONELT-HDMI capemgr.extra_override=BB-SPI0 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
[ 0.251333] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,0A5A,1613BBBK0496'
[ 0.251371] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black
[ 0.251441] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI
[ 0.281830] bone-capemgr bone_capemgr.9: slot #0: No cape found
[ 0.318939] bone-capemgr bone_capemgr.9: slot #1: No cape found
[ 0.356047] bone-capemgr bone_capemgr.9: slot #2: No cape found
[ 0.393155] bone-capemgr bone_capemgr.9: slot #3: No cape found
[ 0.399455] bone-capemgr bone_capemgr.9: slot #4: specific override
[ 0.399500] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4
[ 0.399530] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[ 0.399672] bone-capemgr bone_capemgr.9: slot #5: specific override
[ 0.399710] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5
[ 0.399738] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[ 0.400017] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 0.400218] bone-capemgr bone_capemgr.9: initialized OK.
[ 0.404911] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.404939] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.404967] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 0.405004] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
[ 0.405034] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
[ 0.405346] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
[ 0.405648] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
[ 0.405674] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

I can load it manually with the following command though:

# echo BB-SPI0 > /sys/devices/bone_capemgr.9/slots
# dmesg | grep cape
...
[ 133.404053] bone-capemgr bone_capemgr.9: part_number 'BB-SPI0', version 'N/A'
[ 133.404130] bone-capemgr bone_capemgr.9: slot #6: generic override
[ 133.404148] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6
[ 133.404166] bone-capemgr bone_capemgr.9: slot #6: 'Override Board Name,00A0,Override Manuf,BB-SPI0'
[ 133.404271] bone-capemgr bone_capemgr.9: slot #6: Requesting part number/version based 'BB-SPI0-00A0.dtbo
[ 133.404288] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'BB-SPI0-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 133.404316] bone-capemgr bone_capemgr.9: slot #6: dtbo 'BB-SPI0-00A0.dtbo' loaded; converting to live tree
[ 133.404556] bone-capemgr bone_capemgr.9: slot #6: #2 overlays
[ 133.411776] bone-capemgr bone_capemgr.9: slot #6: Applied #2 overlays.

This is in the latest Angstrom kernel (3.8.13-r23a.13).

Hmm, I guess I haven't explained things properly; the extra override must be present as an override node in the boot dts
(am335x-bone-common.dtsi). It doesn't work like the slots echo sequence.

But I guess that you are right, that something like that is needed for users. Gimme an hour or so and I'll prep something up.

Regards

-- Pantelis

Awesome! That means we won’t have to rebuild any of the stock device trees.

Hi Carl,

Option (enable_partno) added. It's going to be in the next release that goes out.

Enjoy

-- Pantelis

Hi Carl,

Option (enable_partno) added. It's going to be in the next release that goes out.

Enjoy

-- Pantelis

Awesome! That means we won't have to rebuild any of the stock device trees.

That is fantastic news!

In preparation for this feature I’ve created a couple of virtual capes to enable /dev/spidev1.0 and /dev/spidev2.0. They work great, but I’ve noticed that there’s a crash if I attempt to unload them. Maybe it’s stupid to attempt this but here’s the stack trace in case you’re interested.

Hi Carl,

In preparation for this feature I've created a couple of virtual capes to enable /dev/spidev1.0 and /dev/spidev2.0. They work great, but I've noticed that there's a crash if I attempt to unload them. Maybe it's stupid to attempt this but here's the stack trace in case you're interested.

It's a known issue; omap derived peripheral drivers just can't handle removal. We will revisit on
next rebase to mainline.

Slightly off topic, but in preparation for this option I have been attempting to write a bitbake recipe to cross-compile my dts file on the host. Previously I have been manually using the target dtc compiler. My question is, how do I reference the correct dtc compiler from within my recipe? I would rather not patch the kernel tree, but build the device tree in a similar manner to my external module.

Regards,

Dave.

In this document you mention the patch needed for dtc. I have attempted use it to patch: , without success. I am attempting to build a dtc for my host system. Am I completely on the wrong path? If not, could you please guide me to the correct source. Regards, Dave.

OK I think I figured out where the dtc host executable resides, in: ./build/tmp-angstrom_v2012_12-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline-3.8.12-r23a/git/scripts/dtc/dtc Am I correct? My question is now; is there an environment variable for this dtc that can be used in bitbake recipes similar to ${KERNEL_CC} or ${KERNEL_LD}? Regards, Dave.

I just upgraded to this morning’s release (3.8.13-r23a.17) and the capemgr.enable_partno feature works really well! I put the following in my uEnv.txt file:

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-SPI0DEV,BB-SPI1DEV

As expected, the HDMI was disabled and I saw both /dev/spidev1.0 and /dev/spidev2.0. This means I won’t have to fix the boot device trees after every “opkg upgrade,” which was beginning to get old.

Thanks for the quick and fine work!

If anyone else needs to use SPI using the /dev/spidevX.X devices in the latest Angstrom distribution, you can build the SPI device trees by doing the following:

  1. Fetch the contents of the BB-SPI0DEV-00A0.dts and BB-SPI1DEV-00A0.dts files from pastebin, and save them with the associated file names.
  2. Running as root, compile them with the following commands:
opkg install dtc
dtc -O dtb -o /lib/firmware/BB-SPI0DEV-00A0.dtbo -b 0 -@ BB-SPI0DEV-00A0.dts
dtc -O dtb -o /lib/firmware/BB-SPI1DEV-00A0.dtbo -b 0 -@ BB-SPI1DEV-00A0.dts

  1. Mount the boot partition with the following commands:
if [ ! -d /mnt/boot ]; then mkdir /mnt/boot; fi

mount /dev/mmcblk0p1 /mnt/boot

  1. If you want to just enable SPI0, which doesn’t conflict with the on board HDMI, add the following to the end of the “optargs” line in /mnt/boot/uEnv.txt:
capemgr.enable_partno=BB-SPI0DEV

  1. If you also want to enable SPI1 you’ll need to disable the HDMI cape first, so you can edit uEnv.txt as I specified above.

Comments on this approach are welcome!

I’ve been running a stripped down version of Angstrom which doesn’t automount the boot partition, so you’re good with what you did. I created the custom device tree overlays because I wasn’t seeing the /dev/spidevX.X devices with the stock BB-SPIX overlays. Did you?

I just tried, and indeed it did not show up any device. Reason was that there wasn’t a device defined in the @fragment1 section: the lcd cape from Adafruit that was there was commented out.

Oops: fragment@1 section

I’ve followed Carl’s instructions to enable SPI0, which seems to have worked. Short of figuring out how to compile a test app, is there a way to check for SPI availability in Linux? I know it’s a dumb noob question, but that’s basically what I am. I thought maybe I’d see something in /dev after making the necessary changes and recompiling the device tree, but I don’t see anything that is obviously SPI-related.

I think I have found the information I need from some other posts I just found here. http://hipstercircuits.com/enable-spi-with-device-tree-on-beaglebone-black-copy-paste/#comments