Followed instructions to update to sync config-pin & overlays - now even worse...

ags · March 23, 2018, 10:44pm

I gave up trying to figure out how to get config-pins, overlays, uboot, etc all in-sync to allow access to all the available pru pins, so I followed previous instructions to update.

What I did:

debian@BBBWl:~$ cd /opt/scripts/tools
debian@BBBWl:~$ sudo ./update_kernel.sh

edited /boot/uEnv.txt to include:

enable_uboot_overlays=1

disable_uboot_overlay_audio=1

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

enable_uboot_cape_universal=1

and changed this:

cmdline=coherent_pool=1M quiet cape_universal=enable

to this:

cmdline=coherent_pool=1M quiet

rebooted and…

Last login: Fri Mar 23 22:01:29 2018 from 10.8.0.6

debian@BBBWl:~$ uname -r

4.4.113-ti-r148

debian@BBBWl:~$ config-pin -l p9.25

default gpio gpio_pu gpio_pd qep pruout pruin

debian@BBBWl:~$ config-pin p9.25 pruout

P9_25 pinmux file not found!

cape-universala overlay not found

run “config-pin overlay cape-universala” to load the cape

checked to see if the bb-cape-overlays had been updated and saw a newer version so installed that:

debian@BBBWl:~$ apt show bb-cape-overlays

Package: bb-cape-overlays

Version: 4.4.20180322.0-0rcnee0~jessie+20180322

Maintainer: Robert Nelson robertcnelson@gmail.com

Installed-Size: 2,289 kB

Priority: extra

Section: misc

Download-Size: 66.7 kB

APT-Sources: http://repos.rcn-ee.com/debian/ jessie/main armhf Packages

Description: Device tree overlays for Beaglebone.

Device tree overlays for Beaglebone /lib/firmware/

rebooted and same problem.

I then looked to see if the uio_pruss driver had been installed…

debian@BBBWl:/opt/scripts/tools$ ls /sys/class/uio

debian@BBBWl:/opt/scripts/tools$

Bad.

debian@BBBWl:/opt/scripts/tools$ ls /sys/class/gpio

export gpio12 gpio13 gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport

Worse.

So now I have no uio_pruss driver, and just two gpio pins.

Info:

debian@BBBWl:/opt/scripts/tools$ sudo ./version.sh

git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]

eeprom:[A335BNLTBWA51650BBWG0378]

model:[TI_AM335x_BeagleBone_Black_Wireless]

dogtag:[BeagleBoard.org Debian Image 2016-11-06]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.11-rc3-00002-g73df7f]:[location: dd MBR]

kernel:[4.4.113-ti-r148]

nodejs:[v6.12.2]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[disable_uboot_overlay_audio=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg:[bb-cape-overlays]:[4.4.20180322.0-0rcnee0~jessie+20180322]

pkg:[bb-wl18xx-firmware]:[1.20161020-0rcnee1~bpo80+20161020+1]

WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal netdev i2c admin spi tisdk weston-launch xenomai]

cmdline:[console=ttyO0,115200n8 root=UUID=ac4731db-c4db-463f-9129-07e6746b98ba ro rootfstype=ext4 rootwait coherent_pool=1M quiet]

dmesg | grep pinctrl-single

[ 1.179799] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

dmesg | grep gpio-of-helper

[ 1.180937] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0

[ 1.181098] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1

[ 1.181110] gpio-of-helper ocp:cape-universal: ready

END

Help please…

RobertCNelson · March 24, 2018, 12:35am

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2016.11-rc3-00002-g73df7f]:[location: dd MBR]

This is why it's worse:

Run:

sudo /opt/scripts/tools/developers/update_bootloader.sh

and reboot, as that OLD u-boot is sending things down the old path...

Regards,

ags · March 24, 2018, 12:59am

That seems to have fixed it. Will need to run a test to be sure. It does allow me to configure the audio pin as pruout, and I do see gpio entries and the uio events in sysfs.

I was wondering if it was the old U-Boot - I presume the old one doesn’t understand uboot overlays??

(was I correct to remove “cape_universal=enable” from the kernel command line entry in uEnv.txt (or does it not matter once uboot overlays are enabled?)

The syntax of the directives I added to uEnv.txt look (to me) like they are hard-coded into u-boot – is that correct? That is, rather than generic directives that look like:

enable_uboot_overlay=<some overlay found in /lib/firmware>
enable_uboot_overlay=<some other overlay found in /lib/firmware>
disable_uboot_overlay=

we now have:

enable_uboot_overlays=1 # OK, that seems generic… tell u-boot to handle overlays

disable_uboot_overlay_audio=1 . # “audio” is hardcoded in the directive itself

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo # u-boot even knows about prus?

enable_uboot_cape_universal=1 # … and cape_universal?

Thank you for the response.

RobertCNelson · March 24, 2018, 1:11am

That *seems* to have fixed it. Will need to run a test to be sure. It does
allow me to configure the audio pin as pruout, and I do see gpio entries and
the uio events in sysfs.

I was wondering if it was the old U-Boot - I presume the old one doesn't
understand uboot overlays??

That is correct..

(was I correct to remove "cape_universal=enable" from the kernel command
line entry in uEnv.txt (or does it not matter once uboot overlays are
enabled?)

it'll actually get ignored...

The syntax of the directives I added to uEnv.txt look (to me) like they are
hard-coded into u-boot -- is that correct? That is, rather than generic
directives that look like:

enable_uboot_overlay=<some overlay found in /lib/firmware>
enable_uboot_overlay=<some other overlay found in /lib/firmware>
disable_uboot_overlay=<yet another...>

we now have:

enable_uboot_overlays=1 # OK, that seems generic... tell
u-boot to handle overlays

disable_uboot_overlay_audio=1 . # "audio" is hardcoded in the directive
itself

onboard devices:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

(these change cape-universal)...

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo # u-boot
even knows about prus?

pru is special:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

enable_uboot_cape_universal=1
# ... and cape_universal?

Correct, although i'm working on a project to have that auto-enabled..

Regards,

ags · March 24, 2018, 11:40pm

I’ve confirmed that all desired functionality with PRU and IOs is restored, with full access to all the exposed PRU0 (output) pins. Thanks for the help.

I revisited the elinux.org BB pages, and understand what is being described there (for the most part) – but not why. Is there a group/list/forum where the discussion and decisions leading to u-boot overlays (replacing the “old way”) is available? Here’s what I’m trying to understand:

What is benefit of u-boot overlays over the “old way”? Is it that custom capes can be specified for loading by u-boot, rather than the script workaround that is referred to in the elinux:BB page?

For “non-custom” overlays, how is it different (other than syntax) to enable u-boot overlays and then provide directives to enable/disable as u-boot overlays – compared to using the previous capemgr.enable_partno=XXX method?

With u-boot overlays, is it still possible to specify the dtb (not overlay) that is loaded, rather than what is auto-detected?

The biggest confusion I have is with the overarching strategy: my understanding is that DeviceTree exists specifically to avoid a multitude of board files and other junk compiled into the kernel for each platform derivative. It’s been a challenge but I can appreciate the vision and value once there. This was done by creating a way to specify the specific hardware configuration in a data model (and provide parameters to more generic drivers in the kernel to make it all work). IIUC, doesn’t building capes (by way of overlays) into u-boot go against that concept? Building a new u-boot to add an overlay is easier than adding to the kernel (and not polluting mainline). But why not have u-boot look in a designated location for a specified overlay which it knows nothing about, only to load it? [realizing that I may have just “just…” discounted a huge technical problem in the way this question is formed - not intentionally, but from lack of more detailed understanding of how the pieces all fit together]

RobertCNelson · March 25, 2018, 1:18am

I've confirmed that all desired functionality with PRU and IOs is restored,
with full access to all the exposed PRU0 (output) pins. Thanks for the help.

I revisited the elinux.org BB pages, and understand what is being described
there (for the most part) -- but not why. Is there a group/list/forum where
the discussion and decisions leading to u-boot overlays (replacing the "old
way") is available? Here's what I'm trying to understand:

What is benefit of u-boot overlays over the "old way"? Is it that custom
capes can be specified for loading by u-boot, rather than the script
workaround that is referred to in the elinux:BB page?

Old-Way: Tons of Kernel Races, dma's wouldn't sync up, "everything"
had to be a module (aka even more race conditions).. Fast lcd (aka
bootlog/tux) impossible..

New-Way: DT is "complete" before we turn over to the kernel boot..
LCD: we have bootlog and tux!!!

For "non-custom" overlays, how is it different (other than syntax) to enable
u-boot overlays and then provide directives to enable/disable as u-boot
overlays -- compared to using the previous capemgr.enable_partno=XXX method?

With u-boot overlays, is it still possible to specify the dtb (not overlay)
that is loaded, rather than what is auto-detected?

Yes, every 'feature' of the old method was reproduced:

Here is the full list of options..

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

The biggest confusion I have is with the overarching strategy: my
understanding is that DeviceTree exists specifically to avoid a multitude of
board files and other junk compiled into the kernel for each platform
derivative. It's been a challenge but I can appreciate the vision and value
once there. This was done by creating a way to specify the specific hardware
configuration in a data model (and provide parameters to more generic
drivers in the kernel to make it all work). IIUC, doesn't building capes (by
way of overlays) into u-boot go against that concept? Building a new u-boot
to add an overlay is easier than adding to the kernel (and not polluting
mainline). But why not have u-boot look in a designated location for a
specified overlay which it knows nothing about, only to load it? [realizing
that I may have just "just..." discounted a huge technical problem in the
way this question is formed - not intentionally, but from lack of more
detailed understanding of how the pieces all fit together]

So for beagleboard.org, we use u-boot overlays, as we have 100's of
capes, 100's of configurations, thus we try to allow every
configuration...

Now for end users who develop one "product" they can get by with 1
device-tree. BUT, even that's not true, thus overlays become
important.

PS: this is all still evolving, the biggest thing we've done for
beagleboard.org:

1: Move away from our un-maintained "3.8" kernel overlays. It has NO
path to mainline.

2: U-Boot overlays, this is all features in mainline u-boot. Or
patchset for u-boot, aka the "cape manager" utilizes u-boot overlay
functions. It still needs someone a good 3-6 months to properly
implement it in u-boot.. Our current patchset works, but there are
things i don't like about it.

PS2: Frank Rowand has a good talk on all the fun we trying to solve,
just done at ELC 2 weeks ago or so.

Regards,