On Sat, Mar 24, 2018 at 6:40 PM, ags <[email protected]> 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 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/CAOCHtYjjxeR5PspgM7jg53aKKJFKi4C6hYX6BfmTvif7VMSJGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
