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]



On Friday, March 23, 2018 at 6:12:11 PM UTC-7, RobertCNelson wrote:
>
> On Fri, Mar 23, 2018 at 7:59 PM, ags <[email protected] <javascript:>> 
> 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.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/77780e48-089a-4bb6-b883-ee95a589fe8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to