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

[ags]

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

[Robert Nelson]

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

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

[ags]

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

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.

[Robert Nelson]

On Fri, Mar 23, 2018 at 7:59 PM, ags <alfred.g...@gmail.com> wrote:
> 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..

[ags]

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]

[Robert Nelson]

On Sat, Mar 24, 2018 at 6:40 PM, ags <alfred.g...@gmail.com> wrote:
> 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.

https://youtu.be/HYdb5uimPtE