On Tue, Aug 26, 2014 at 5:35 PM, William Hermans <[email protected]> wrote:
> Jason, > > What is so radically different that capemgr does not work ? > Didn't say that it doesn't work. It hasn't yet been added to our 3.14 tree which will require a backport. It looks like it should land upstream in 3.17 and we'll likely backport it from there. > Sorry if this is a total newb question, but this is one aspect I've been > struggling to try and understand. As I'm not exactly a kernel dev *yet*. > > I've read stuff where people have used mmap to configure pins, using the > PRU etc, but again this is another area where I lack experience . . . > Perhaps the device tree needs to be in place for any of this to work? > Using mmap to configure pins and peripherals bypasses Linux maintaining control over that peripheral and is not the "Linux way". A device tree is required to boot modern ARM kernels, but device tree *overlays* are not. For mmap interfaces to work, you simply need a kernel that will agree to mmap the memory. A device tree overlay may or may not be helpful. The way to know something will work now and in the future is to get a real device driver into the mainline kernel. > > > On Tue, Aug 26, 2014 at 2:20 PM, Jason Kridner <[email protected]> > wrote: > >> On Tue, Aug 26, 2014 at 3:50 PM, Tony DiCola <[email protected]> wrote: >> >>> Sorry to bump up an old thread, but I was trying to catch up on the >>> general state and future of overlay support and this looks like the best >>> discussion. I was curious, is there any thought around how bonescript and >>> other tools that use overlays today for dynamic pin control (like setting >>> pull-ups, analog inputs, etc.) would work in a world without overlays? For >>> example does bonescript work on the 3.14 kernel today without the cape >>> manager? >>> >> >> I have a version where I did a bit of a proof-of-concept on this, but I >> haven't enabled all of the peripherals yet. I have various implementations >> of the kernel interfaces and here is the one that uses cape-universal: >> * https://github.com/jadonk/bonescript/blob/master/src/hw_universal.js >> >> It is triggered by this condition when the library is loaded: >> * https://github.com/jadonk/bonescript/blob/master/src/index.js#L33 >> >> This is the test condition I used to discover if cape-universal is loaded: >> * https://github.com/jadonk/bonescript/blob/master/src/my.js#L43 >> >> exports.is_cape_universal = function(callback) { >> var ocp = exports.is_ocp(); >> if(debug) winston.debug('is_ocp() = ' + ocp); >> var cape_universal = exports.find_sysfsFile('cape-universal', ocp, >> 'cape-universal.', callback); >> if(debug) winston.debug('is_cape_universal() = ' + cape_universal); >> return(cape_universal); >> }; >> >> However, I'm not finding that 3.14 is really using cape-universal. I'm >> still exploring that, but it seems Robert has implemented things in a >> different way. When I'm not fighting 'buildbot' (builds.beagleboard.org), >> I'm looking at what it'll take to align 'config-pin' from cape-universal >> and Robert's entries. Right now, I'm leaning towards backing out Robert's >> changes and going back to cape-universal. >> >> With cape-universal, there are gpio and pinmux helpers that can be >> configured from userspace. >> >> >>> >>> Also based on this LKML thread that was mentioned in other threads ( >>> https://lkml.org/lkml/2014/7/27/57), does it still look like device >>> tree overlay support is on its way into the mainline kernel? >>> >> >> I certainly believe so. We don't want to go away from enabling device >> tree overlays, but usability seems to be showing that it is better to try >> to avoid the dependency. Not so much because of getting the CapeMgr merged, >> but rather the headaches that people are getting trying to keep overlays >> compatible and derive new ones. >> >> >>> >>> I just wanted to get a better picture of the future of overlays and if >>> libraries that use them today (like bonescript or Adafruit's BBIO library) >>> should continue to use them or start looking at alternatives. Thanks! >>> >>> On Thursday, June 26, 2014 8:27:22 AM UTC-7, Jason Kridner wrote: >>>> >>>> On Thu, Jun 26, 2014 at 9:06 AM, Tom Rini <[email protected]> wrote: >>>> > On 06/26/2014 03:50 AM, Tony Lindgren wrote: >>>> >> * Gupta, Pekon <[email protected]> [140618 01:52]: >>>> >>> Hi, >>>> >>> >>>> >>>> From: Jason Kridner [mailto:[email protected]] >>>> >>>>> On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <[email protected]> >>>> wrote: >>>> >>>>>> From: Jason Kridner >>>> >>> [...] >>>> >>>>>>> * The devicetree sources, including the primary boot .dts >>>> files, will >>>> >>>>>>> eventually be removed from the kernel source tree. I'm not too >>>> sure if >>>> >>>>>>> and when it'll really happen, but starting up a project to >>>> maintain >>>> >>>>>>> the definitive beagleboard.org board devicetree files outside >>>> the >>>> >>>>>>> kernel seems to make sense. Given the interdependency of the >>>> boot .dtb >>>> >>>>>>> and the overlay .dtbo files, combining them into a single >>>> repository >>>> >>>>>>> where every distribution can pick them up seems like a natural >>>> and >>>> >>>>>>> obvious choice. There are of course some dependencies on kernel >>>> >>>>>>> versions, but I believe most of those have settled out by now >>>> and we >>>> >>>>>>> should be OK moving forward. >>>> >>>>> >>>> >>>>> +1 >>>> >>>>> Yes, moving cape DTS out of kernel tree should help developers. >>>> >>>>> There are quite a few cape patches floating in mail-lists, but as >>>> cape >>>> >>>>> DTS is still not accepted in mainline so they get lost and >>>> forgotten. >>>> >>>>> So one place for collecting all this is a good idea. >>>> >>>>> >>>> >>>>> >>>> >>>>> However, somehow the universal I/O DTS looked seemed complicated: >>>> >>>>> (1) >>>> >>>>> All capes work standalone, but due to share pin-mux some cape >>>> >>>>> combinations cannot be used simultaneously. But most users of >>>> >>>>> BeagleBone are already well-versed with DT and kernel >>>> infrastructure, >>>> >>>>> so they need not be spoon fed to get a out-of-box working >>>> solution >>>> >>>>> for each combination. If there is proper documentation is >>>> available >>>> >>>>> about compatibility of capes with each other, then users will >>>> figure >>>> >>>>> out themselves. >>>> >>>> >>>> >>>> I think you have too much confidence in users. If this doesn't >>>> hurt >>>> >>>> power users, then why is it bad have an option to spoon feed? This >>>> >>>> doesn't prevent anyone with knowledge of DT from doing their own >>>> >>>> thing. >>>> >>>> >>>> >>> Fair enough. >>>> >>> But plz give a try to u-boot alternative below. It works at my end. >>>> >>> >>>> >>>>> >>>> >>>>> (2) >>>> >>>>> Also, there was a talk of enabling and disabling DT fragments via >>>> u-boot. >>>> >>>>> That should also be explored instead of complicating cape DTS. >>>> >>>> >>>> >>>> Link? Relevance? >>>> >>>> >>>> >>> we can modify DT from u-boot itself [1]. >>>> >>> Example: "MMC2" pin-mux conflicts with "NAND" and "NOR" capes. >>>> >>> But using following sequence of commands, you can modify DTB via >>>> >>> u-boot and make NAND cape work _without_any_hack_ in patch [2]. >>>> >>> >>>> >>> /* load DTB */ >>>> >>> u-boot> tftp 0x81000000 am335x-boneblack.dtb >>>> >>> u-boot> fdt addr 0x81000000 >>>> >>> /* disable MMC2 node */ >>>> >>> u-boot> fdt list /ocp/mmc@481d8000 >>>> >>> u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d >>>> >>> u-boot> fdt list /ocp/mmc@481d8000 status >>>> >>> /* enable GPMC node */ >>>> >>> u-boot> fdt list /ocp/gpmc >>>> >>> u-boot> fdt set /ocp/gpmc status \o\k\a\y >>>> >>> u-boot> fdt list /ocp/gpmc status >>>> >>> /* enable ELM node */ >>>> >>> u-boot> fdt list /ocp/elm >>>> >>> u-boot> fdt set /ocp/elm status \o\k\a\y >>>> >>> u-boot> fdt list /ocp/elm status >>>> >>> /* boot uImage */ >>>> >>> tftp 0x82000000 uImage >>>> >>> bootm 0x82000000 - 0x81000000 >>>> >>> >>>> >>> Note: "fdt set" command does not accept string literals >>>> >>> as binding values, it internally converts them to string, so >>>> >>> escape sequenced characters were used here.. >>>> >>> "okay" == \o\k\a\y >>>> >>> "disabled" == \d\i\s\a\b\l\e\d" >>>> >>> >>>> >>> >>>> >>> Hope above solves the pre-requisite because of which 'Tony Lindgren >>>> <[email protected]>' >>>> >>> was unable to accept cape related DTS into his tree [3] >>>> >> >>>> >> Yes. If the capes are disabled by default we can have at >>>> >> least some of them included in the mainline kernel and >>>> >> enabled by the bootloader as needed. I'd like to hear back >>>> >> from the u-boot people too on this approach naturally. >>>> >>>> Great. >>>> >>>> >> >>>> >> And some things we still cannot merge if they overlap for >>>> >> GPMC bindings for example. So we have to carefully check >>>> >> the generated .dtb file with dtc -I dtb -O dts. >>>> > >>>> > This sounds really problematic to me from an end-user horror point of >>>> > view. And fortunately 3.17 is going to have some level of overlay >>>> > support so we can set this problem aside (and even treat the am335x >>>> gp >>>> > evm "profileN" trees as overlays too). >>>> >>>> Thank you Tom for chiming in. I think the end user experience is >>>> horrific. Pekon should at least provide patches to u-boot that would >>>> provide a mechanism to enable/disable a cape with a single operation, >>>> rather than the individual devicetree nodes. This seems to really >>>> break any ability to keep information about a cape consolidated or >>>> usable by mere mortals. >>>> >>>> I don't know that pushing it all into the kernel with overlays, >>>> however, is the right answer. We've seen challenges with some >>>> userspaces not exposing /lib/firmware in time and needing to compile >>>> overlays into the kernel to make them work. More troublesome are the >>>> types of errors end-users get when there are syntax errors, conflicts >>>> or other failures, most notably because testing of loading all of the >>>> various overlays in conflict with each other is adhoc at best. We've >>>> gotten a lot of good feedback on using the pinmux-helper and >>>> config-pin utility from end users who are still struggling to learn >>>> how to do devicetree overlays properly. It seems to me that kernel >>>> run-time overlays should be used for development and dynamic hardware >>>> rather than boot-time configuration, despite the convenience they add >>>> to most of us who understand the basics of how to use them. >>>> >>> -- >>> 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]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
