2017-04-02-1gb.img capemgr bug

[William Hermans]

So the image I'm using on two separate boards: bone-debian-8.7-console-armhf-2017-04-02-1gb.img

One board has uboot capes enabled, and they do function. The other board is not using uboot overlays, but seems odd at times.

So on both board inserting an overlay as such: root@wgd:~# echo BB-UART1 > /sys/devices/platform/bone_capemgr/slots

Causes the terminal session to hang directly after the command is issued. The board is still operational, however after reiitializing an ssh session:

root@wgd:~# cat  /sys/devices/platform/bone_capemgr/slots
 0: ---l--  -1
 1: ------  -1
 2: ---l--  -1
 3: ---l--  -1
 4: --O---  -1

root@wgd:~# dmesg | tail
[   18.436962] net eth0: initializing cpsw version 1.12 (0)
[   18.436993] net eth0: initialized cpsw ale version 1.4
[   18.437003] net eth0: ALE Table size 1024
[   18.445166] net eth0: phy found : id is : 0x7c0f1
[   18.462196] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  121.758813] cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  121.758944] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[346482.260850] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 'N/A'
[346482.260892] bone_capemgr bone_capemgr: slot #4: override
[346482.260910] bone_capemgr bone_capemgr: slot #4: auto loading handled by U-Boot

root@wgd:~# ls /dev |grep ttyO[0-4]
ttyO0

The cape is definitely not loading. The output from these commands here is from the board that is loading overlays via uboot, but I am willing( I have not checked yet ) the output would be identical on the board that does not have uboot overlays enabled. Curiously, I did try the old method of loading the overlay form uEnv.txt, and the overlay did not load correctly then either.

One thing of note which may *possibly* be the culprit. Is that I do not have a board file for either of these loaded specifically. However on at least the uboot overlay board I have hdmi video and audio both disabled through the new uboot way. I have not checked if any of those pins conflict with that overlay or not, because I have not looked.

I'll make another post following this one to see how this overlay behaves when i attempt to load via uboot overlays.

[William Hermans]

By the way, Universal IO is disabled on both boards.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1c0c6094-2b0a-4724-a434-1c6d043e608c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Ok so uboot overlay loading works on UART1:

root@wgd:~# ls /dev |grep ttyO[0-4]
ttyO0

ttyO1

So apparently the part of capemgr that works from the command line seems to be broken. This board I'm testing is an Alpha prototype whcih needs serial debug brought out over to the top of the cape, so I can not unfortunately give serial debug output. uEnv.txt line on a working uboot overlay load:

###Additional custom capes
uboot_overlay_addr4=/lib/firmware/wph-i2c-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo
uboot_overlay_addr6=/lib/firmware/BB-W1-P8.26-00A0.dtbo
uboot_overlay_addr7=/lib/firmware/BB-UART1-00A0.dtbo

The first cape is nothing special that could possibly interfere with capemgr. It just enables I2C-1 bus, and loads the ds3232 RTC driver, for a ds3232 on I2C-2 bus.

[Robert Nelson]

On Wed, Apr 26, 2017 at 10:03 PM, William Hermans <yyr...@gmail.com> wrote:
> Ok so uboot overlay loading works on UART1:
>
> root@wgd:~# ls /dev |grep ttyO[0-4]
> ttyO0
> ttyO1
>
> So apparently the part of capemgr that works from the command line seems to
> be broken. This board I'm testing is an Alpha prototype whcih needs serial
> debug brought out over to the top of the cape, so I can not unfortunately
> give serial debug output. uEnv.txt line on a working uboot overlay load:
>
> ###Additional custom capes
> uboot_overlay_addr4=/lib/firmware/wph-i2c-00A0.dtbo
> uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo
> uboot_overlay_addr6=/lib/firmware/BB-W1-P8.26-00A0.dtbo
> uboot_overlay_addr7=/lib/firmware/BB-UART1-00A0.dtbo
>
> The first cape is nothing special that could possibly interfere with
> capemgr. It just enables I2C-1 bus, and loads the ds3232 RTC driver, for a
> ds3232 on I2C-2 bus.

Yeah, i don't want to go down that road.. to have u-boot's
cape-manager tell the kernel's cape-manager what pin's are available.
It would be a great GSOC project ;)

So what's i'm doing:

if u-boot overlays loads something that's just a normal *.dtb you can
use the kernel's cape-manager. But if it loads anything custom.. i
disable the kernel's cape-manager..

So any of these combinations:

enable_uboot_overlays=1
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1

kernel cape-manager is enabled..

With any of these combinations:

#disable_uboot_overlay_adc=1
uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
dtb_overlay=/lib/firmware/<file8>.dtbo
#enable_uboot_cape_universal=1

kernel cape-manager get's disabled..

Regards,

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