Beaglebone and the 3.8 Kernel (Repost)

[Pantelis Antoniou]

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.

[David M.]

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!

[David M.]

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.

 

[Pantelis Antoniou]

Hi there,

On Jun 4, 2013, at 1:45 AM, David M. wrote:

> 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

>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/jYpYHZPl1ig/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Carl Johnson]

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).

[Pantelis Antoniou]

Hi Carl,

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

[Carl Johnson]

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

[Pantelis Antoniou]

Hi Carl,

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

Enjoy

-- Pantelis

On Jun 4, 2013, at 7:00 PM, Carl Johnson wrote:

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

[David Lambert]

On 13-06-04 11:44 AM, Pantelis Antoniou wrote:
> Hi Carl,
>
> Option (enable_partno) added. It's going to be in the next release that goes out.
>
> Enjoy
>
> -- Pantelis
>
> On Jun 4, 2013, at 7:00 PM, Carl Johnson wrote:
>
>> Awesome! That means we won't have to rebuild any of the stock device trees.

That is fantastic news!

[Carl Johnson]

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.

[Pantelis Antoniou]

Hi Carl,

On Jun 5, 2013, at 4:20 AM, Carl Johnson wrote:

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

[David Lambert]

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.

[David Lambert]

On 13-05-31 08:48 AM, Pantelis Antoniou wrote:

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

In this document you mention the patch needed for dtc. I have attempted use it to patch:
https://launchpad.net/ubuntu/+source/device-tree-compiler/1.3.0-2, 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.
 

Regards

-- Pantelis

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

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

[David Lambert]

On 13-06-05 06:49 PM, David Lambert wrote:

On 13-05-31 08:48 AM, Pantelis Antoniou wrote:

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

In this document you mention the patch needed for dtc. I have attempted use it to patch:
https://launchpad.net/ubuntu/+source/device-tree-compiler/1.3.0-2, 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.

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.

[Carl Johnson]

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

3. Mount the boot partition with the following commands:

if [ ! -d /mnt/boot ]; then mkdir /mnt/boot; fi

mount /dev/mmcblk0p1 /mnt/boot

4. 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

5. 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!

[Carl Johnson]

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?

[Johan Henselmans]

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.

[Johan Henselmans]

Oops: fragment@1 section

[Dave M]

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.

[Dave M]

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

[Thorsten von Eicken]

I'm having difficulties with the new enable_partno the cape manager fails to load my dtbo even through the "echo slots" works just fine. I have:

$ cat /boot/uboot/uEnv.txt

optargs=fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-UART4-RTS

uenvcmd=i2c mw 0x24 1 0x3e

loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtbs/${fdtfile}

and at boot time the cape manager says:

# dmesg | grep capemgr

[    0.000000] Kernel command line: console=ttyO0,115200n8 fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-UART4-RTS root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

[    1.343502] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,0A5C,3513BBBK3163'

[    1.351312] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black

[    1.359241] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI

[    1.367894] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMIN

[    1.406433] bone-capemgr bone_capemgr.9: slot #0: No cape found

[    1.443539] bone-capemgr bone_capemgr.9: slot #1: No cape found

[    1.480647] bone-capemgr bone_capemgr.9: slot #2: No cape found

[    1.517756] bone-capemgr bone_capemgr.9: slot #3: No cape found

[    1.524025] bone-capemgr bone_capemgr.9: slot #4: specific override

[    1.530635] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4

[    1.538680] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'

[    1.548837] bone-capemgr bone_capemgr.9: slot #5: specific override

[    1.555443] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5

[    1.563486] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'

[    1.573537] bone-capemgr bone_capemgr.9: slot #6: specific override

[    1.580143] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6

[    1.588187] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'

[    1.598439] bone-capemgr bone_capemgr.9: enabled_partno part_number 'BB-UART4-RTS', version 'N/A', prio '0'

[    1.608666] bone-capemgr bone_capemgr.9: slot #7: generic override

[    1.615165] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 7

[    1.623207] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,BB-UART4-RTS'

[    1.633413] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI

[    1.643011] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN

[    1.652965] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    1.661849] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    1.670659] bone-capemgr bone_capemgr.9: initialized OK.

[    1.676269] bone-capemgr bone_capemgr.9: loader: before slot-7 BB-UART4-RTS:00A0 (prio 0)

[    1.684855] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-UART4-RTS:00A0 (prio 0)

[    1.707112] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    1.722288] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-UART4-RTS:00A0 (prio 0)

[    1.736908] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-UART4-RTS-00A0.dtbo

[    1.767844] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'BB-UART4-RTS-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[   62.000364] bone-capemgr bone_capemgr.9: failed to load firmware 'BB-UART4-RTS-00A0.dtbo'

[   62.008988] bone-capemgr bone_capemgr.9: loader: failed to load slot-7 BB-UART4-RTS:00A0 (prio 0)

[   62.018399] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[   62.027331] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[   62.036148] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'

[   62.049743] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree

[   62.060764] bone-capemgr bone_capemgr.9: slot #4: #2 overlays

[   62.143004] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.

[   62.149936] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

If I then manually load the overlay it works fine:

# echo BB-UART4-RTS >/sys/devices/bone_capemgr.9/slots

# dmesg | tail

[  264.848073] bone-capemgr bone_capemgr.9: part_number 'BB-UART4-RTS', version 'N/A'

[  264.848260] bone-capemgr bone_capemgr.9: slot #8: generic override

[  264.848310] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8

[  264.848360] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,BB-UART4-RTS'

[  264.848632] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-UART4-RTS-00A0.dtbo

[  264.848684] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'BB-UART4-RTS-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[  264.859878] bone-capemgr bone_capemgr.9: slot #8: dtbo 'BB-UART4-RTS-00A0.dtbo' loaded; converting to live tree

[  264.860523] bone-capemgr bone_capemgr.9: slot #8: #2 overlays

[  264.875574] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4

[  264.878196] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.

What am I doing wrong?

[ara...@gmail.com]

Does anybody know what exactly should be added to am335x-bone-common.dtsi?

Thanks!

[Robert Nelson]

Umm, that was 3 years ago...

Just ask your question and state your problem like a normal person..

Regards,

--

Robert Nelson
https://rcn-ee.com/

[Sergey Manucharian]

Well, I'm using 4.4.8-ti-rt-r22 and the option capemgr.extra_override=XXXX doesn't work for a cape without EEPROM, but it works by echoing into /sys/devices/platform/bone_capemgr/slots.

[Robert Nelson]

On Wed, May 11, 2016 at 10:40 AM, Sergey Manucharian <ara...@gmail.com> wrote:

Well, I'm using 4.4.8-ti-rt-r22 and the option capemgr.extra_override=XXXX doesn't work for a cape without EEPROM, but it works by echoing into /sys/devices/platform/bone_capemgr/slots.

Well, that's not a valid option in 4.1/4.4:

bone_capemgr.enable_partno=
bone_capemgr.disable_partno=

using, ',' you specify multiple overlays...

[Sergey Manucharian]

That was the first think I tried, but it's simply ignored:

bone_capemgr.enable_partno=XXXX

[Robert Nelson]

On Wed, May 11, 2016 at 10:50 AM, Sergey Manucharian <ara...@gmail.com> wrote:

That was the first think I tried, but it's simply ignored:

bone_capemgr.enable_partno=XXXX

Well, that is the kernel parameter, so how did you pass it to the kernel from u-boot?

in /boot/uEnv.txt i have a some macro's setup:

cape_enable=bone_capemgr.enable_partno=XXXX

(our default u-boot has been patched to recognize cape_enable=)

or add it to the cmdline variable:

cmdline=bone_capemgr.enable_partno=XXXX

Then you should see it via:

cat /proc/cmdline

Regards,

[Sergey Manucharian]

I've added it to "cmdline=" and I do see it when booted:

$ cat /proc/cmdline
console=tty0 console=ttyO0,115200n8 video=HDMI-A-1:1280x720@60 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait fixrtc coherent_pool=1M quiet cape_universal=enable bone_capemgr.enable_partno=BB-LCD10 video=LVDS-1:800x600@60

[Robert Nelson]

On Wed, May 11, 2016 at 11:03 AM, Sergey Manucharian <ara...@gmail.com> wrote:

I've added it to "cmdline=" and I do see it when booted:

$ cat /proc/cmdline
console=tty0 console=ttyO0,115200n8 video=HDMI-A-1:1280x720@60 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait fixrtc coherent_pool=1M quiet cape_universal=enable bone_capemgr.enable_partno=BB-LCD10 video=LVDS-1:800x600@60

Then you should see it load:

dmesg | grep bone

Regards,

[Sergey Manucharian]

That's strange, first it loads and then reports "failed":

[    3.042573] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-LCD10' VER 'N/A' PR '0'
[    3.042588] bone_capemgr bone_capemgr: slot #4: override
[    3.042605] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[    3.042623] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-LCD10'
[    3.043003] bone_capemgr bone_capemgr: initialized OK.
. . . . .
[    4.053108] bone_capemgr bone_capemgr: loader: failed to load slot-4 BB-LCD10:00A0 (prio 0)

[Robert Nelson]

On Wed, May 11, 2016 at 11:14 AM, Sergey Manucharian <ara...@gmail.com> wrote:

That's strange, first it loads and then reports "failed":

[    3.042573] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-LCD10' VER 'N/A' PR '0'
[    3.042588] bone_capemgr bone_capemgr: slot #4: override
[    3.042605] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[    3.042623] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-LCD10'
[    3.043003] bone_capemgr bone_capemgr: initialized OK.
. . . . .
[    4.053108] bone_capemgr bone_capemgr: loader: failed to load slot-4 BB-LCD10:00A0 (prio 0)

Well considering it's an lcd board...

Did you force one of the overlay dtb's:

BBB compatibility issues:

You can override dtb=x in /boot/uEnv.txt...

BeagleBone Black: HDMI (Audio/Video) disabled:

dtb=am335x-boneblack-emmc-overlay.dtb

BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:

dtb=am335x-boneblack-overlay.dtb

ps, this is all in:

https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md

Regards,

[Sergey Manucharian]

BBB compatibility issues:

You can override dtb=x in /boot/uEnv.txt...

BeagleBone Black: HDMI (Audio/Video) disabled:

dtb=am335x-boneblack-emmc-overlay.dtb

BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:

dtb=am335x-boneblack-overlay.dtb

ps, this is all in:

https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md

 

Thanks, Robert, however I've read that and

dtb=am335x-boneblack-overlay.dtb

is there (I don't know how HMDI mode option appeared in the command line though).
Also that LCD panel works perfectly when I echo to cape slots:

# echo BB-LCD10 > /sys/devices/platform/bone_capemgr/slots
# cat /sys/devices/platform/bone_capemgr/slots
 0: PF----  -1 
 1: PF----  -1 
 2: PF----  -1 
 3: PF----  -1 
 5: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-LCD10

I have spent some time before posting the problem here.

[Sergey Manucharian]

SOLVED: it works now:

bone_capemgr.enable_partno=BB-LCD10

It was my fault. I reworked the DTS file. Initially it was based on the old BB-BONE-LCD7-01-00A0.dts (since my cape has been designed based on Bone LCD 7").
But even BB-BONE-LCD7-01-00A1.dts works out of the box for my LCD panel. Although the hardware engineer who designed it still works on it and makes improvements.

Thanks, Robert! Without your proof that it must work I wouldn't think it's a DTS issue.