Jason, What is so radically different that capemgr does not work ? 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? 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.
