capemgr in 4.1.10-bone16 kernel not loading capes at boot

[jason]

I am attempting to update my beaglebone black Rev C to the 4.1 kernel from https://github.com/RobertCNelson/bb-kernel and filesystem from https://rcn-ee.com/rootfs/eewiki/minfs/debian-8.2-minimal-armhf-2015-09-07.tar.xz

uname -a: Linux arm 4.1.10-bone16 #2 Tue Oct 27 19:53:33 EDT 2015 armv7l GNU/Linux

I am having an issue loading capes from the kernel command line.I downloaded and installed the bb.org overlays per the eewiki instructions without issue, however capemgr will not load the dtbo files on boot. I can load them manually without an issue after the kernel boots or by specifying them in /etc/default/capemgr. This behavior appears similar to what would occur when the .dtbo is not loaded into the initrd, however I have run the /opt/scripts/tools/developers/update_initrd.sh and it made no difference. Is there a step I might have missed along the way.

/boot/uEnv.txt:

uname_r=4.1.10-bone16

cmdline=quiet init=/lib/systemd/systemd

#comment out below to enable gui

optargs=text

dtb=am335x-boneblack-emmc-overlay.dtb

##Example

#cape_disable=capemgr.disable_partno=

cape_enable=bone_capemgr.enable_partno=BB-UART1,BB-I2C1,BB-UART4

dmesg | grep bone output:

[    0.000000] Linux version 4.1.10-bone16 (user) (gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11) ) #2 Tue Oct 27 19:53:33 EDT 2015

[    0.000000] Kernel command line: console=ttyO0,115200n8 text no_console_suspend=1 vt.global_cursor_default=0 consoleblank=0 bone_capemgr.enable_partno=BB-UART1,BB-I2C1,BB-UART4 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd

[    3.098555] usb usb1: Manufacturer: Linux 4.1.10-bone16 musb-hcd

[    3.268395] bone_capemgr bone_capemgr: Baseboard: 'A335BNLT,00C0,2215BBBK123A'

[    3.268423] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4

[    3.322565] bone_capemgr bone_capemgr: slot #0: No cape found

[    3.382558] bone_capemgr bone_capemgr: slot #1: No cape found

[    3.442556] bone_capemgr bone_capemgr: slot #2: No cape found

[    3.502556] bone_capemgr bone_capemgr: slot #3: No cape found

[    3.508342] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART1' VER 'N/A' PR '0'

[    3.508354] bone_capemgr bone_capemgr: slot #4: override

[    3.508367] bone_capemgr bone_capemgr: Using override eeprom data at slot 4

[    3.508381] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART1'

[    3.508463] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-I2C1' VER 'N/A' PR '0'

[    3.508473] bone_capemgr bone_capemgr: slot #5: override

[    3.508482] bone_capemgr bone_capemgr: Using override eeprom data at slot 5

[    3.508494] bone_capemgr bone_capemgr: slot #5: 'Override Board Name,00A0,Override Manuf,BB-I2C1'

[    3.508554] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART4' VER 'N/A' PR '0'

[    3.508563] bone_capemgr bone_capemgr: slot #6: override

[    3.508572] bone_capemgr bone_capemgr: Using override eeprom data at slot 6

[    3.508584] bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override Manuf,BB-UART4'

[    3.508900] bone_capemgr bone_capemgr: initialized OK.

[    4.542747] bone_capemgr bone_capemgr: loader: failed to load slot-6 BB-UART4:00A0 (prio 0)

[    4.551350] bone_capemgr bone_capemgr: loader: failed to load slot-4 BB-UART1:00A0 (prio 0)

[    4.559823] bone_capemgr bone_capemgr: loader: failed to load slot-5 BB-I2C1:00A0 (prio 0)

 

[Robert Nelson]

On Thu, Nov 5, 2015 at 12:24 PM, jason <jlhe...@gmail.com> wrote:
> I am attempting to update my beaglebone black Rev C to the 4.1 kernel from
> https://github.com/RobertCNelson/bb-kernel and filesystem from
> https://rcn-ee.com/rootfs/eewiki/minfs/debian-8.2-minimal-armhf-2015-09-07.tar.xz
>
> uname -a: Linux arm 4.1.10-bone16 #2 Tue Oct 27 19:53:33 EDT 2015 armv7l
> GNU/Linux
>
> I am having an issue loading capes from the kernel command line.I downloaded
> and installed the bb.org overlays per the eewiki instructions without issue,
> however capemgr will not load the dtbo files on boot. I can load them
> manually without an issue after the kernel boots or by specifying them in
> /etc/default/capemgr. This behavior appears similar to what would occur when
> the .dtbo is not loaded into the initrd, however I have run the
> /opt/scripts/tools/developers/update_initrd.sh and it made no difference. Is
> there a step I might have missed along the way.

Sounds like either the initrd is not being used or the dtbo objects
aren't present..

Make sure this file:

https://raw.githubusercontent.com/rcn-ee/repos/master/bb-customizations/suite/jessie/debian/dtbo

exists

/usr/share/initramfs-tools/hooks/dtbo

If you can please add a serial boot log, i want to see what u-boot's
doing with the initrd. ;)

Regards,

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

[jlhe...@gmail.com]

The dtbo file is present on the system. Below is the serial boot log

U-Boot 2015.04-svn40 (Oct 23 2015 - 08:19:16)

       Watchdog enabled

I2C:   ready

DRAM:  512 MiB

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

Using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC

cpsw

Hit any key to stop autoboot:  0 

gpio: pin 53 (gpio 53) value is 1

switch to partitions #0, OK

mmc0 is current device

gpio: pin 54 (gpio 54) value is 1

Checking for: /uEnv.txt ...

reading uEnv.txt

983 bytes read in 6 ms (159.2 KiB/s)

gpio: pin 55 (gpio 55) value is 1

Loaded environment from uEnv.txt

Importing environment from mmc ...

Checking if uenvcmd is set ...

gpio: pin 56 (gpio 56) value is 1

Running uenvcmd ...

924 bytes read in 40 ms (22.5 KiB/s)

6948760 bytes read in 430 ms (15.4 MiB/s)

5082010 bytes read in 329 ms (14.7 MiB/s)

54462 bytes read in 124 ms (428.7 KiB/s)

Kernel image @ 0x82000000 [ 0x000000 - 0x6a0798 ]

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Using Device Tree in place at 88000000, end 880104bd

Starting kernel ...

The uenv.txt on the boot partition is:

##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.

loadaddr=0x82000000

fdtaddr=0x88000000

rdaddr=0x88080000

initrd_high=0xffffffff

fdt_high=0xffffffff

##These are needed to be compliant with Debian 2014-05-14 u-boot.

loadximage=load mmc 0:2 ${loadaddr} /boot/vmlinuz-${uname_r}

loadxfdt=load mmc 0:2 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}

loadxrd=load mmc 0:2 ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}

loaduEnvtxt=load mmc 0:2 ${loadaddr} /boot/uEnv.txt ; env import -t ${loadaddr} ${filesize};

check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;

loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; run loadxfdt;

mmcargs=setenv bootargs console=${console} ${optargs} no_console_suspend=1 vt.global_cursor_default=0 consoleblank=0 ${cape_disable} ${cape_enable} root=/dev/mmcblk0p2 rootfstype=${mmcrootfstype} ${cmdline}

uenvcmd=run loadall; run mmcargs; bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};d from the 

I also found that if I remove the loadxrd, thereby removing the initrd from the uEnv.txt that it will load the capes properly when booting from the sdcard. However removing the initrd from the emmc boot causes the boot to hang when loading capes.

Thanks for the help

Jason

[Jason Hessler]

I confirmed that /usr/share/initramfs-tools/hooks/dtbo exists in the file system, however after mounting and examining the initrd image file the /lib/firmware does not exist within the initrd. Could anyone point me to the proper steps to take to force the inclusion of /lib/firmware into the initrd through the update-initramfs function?

Thanks,

Jason

Jason

--
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/hr8L9U7HLMk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason]

So it turns out this was fairly simple to fix. 

The /usr/share/initramfs-tools/hooks/dtbo executable bit was not set.

After running chmod +x /usr/share/initramfs-tools/hooks/dtbo  everything is good.