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?
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 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 <tr...@ti.com <javascript:>> > wrote: > > On 06/26/2014 03:50 AM, Tony Lindgren wrote: > >> * Gupta, Pekon <pe...@ti.com <javascript:>> [140618 01:52]: > >>> Hi, > >>> > >>>> From: Jason Kridner [mailto:jkri...@gmail.com <javascript:>] > >>>>> On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pe...@ti.com > <javascript:>> 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 < > to...@atomide.com <javascript:>>' > >>> 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
