On Thu, Aug 15, 2013 at 09:30:01AM -0600, Stephen Warren wrote: > On 08/15/2013 08:53 AM, Tom Rini wrote: > > On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote: > >> On Wed, 14 Aug 2013, Tom Rini wrote: > >> > >>> On 08/14/2013 08:37 PM, Nicolas Pitre wrote: > >>>> On Wed, 14 Aug 2013, Tom Rini wrote: > >>>> > >>>>> On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote: > >>>>>> On 08/14/2013 09:13 AM, Tom Rini wrote: > >>>>>>> Hey all, > >>>>>>> > >>>>>>> Do we have a document yet talking about the best practices for how we > >>>>>>> would like a hardware vendor to ship, store and possibly update a device > >>>>>>> tree, on the hardware? "However they like" seems likely to invite > >>>>>>> problems down the line with everyone trying their own thing. Thanks! > >>>>>> > >>>>>> I don't believe there's any written guidance, no. > >>>>>> > >>>>>> The initial guidance Grant gave (IIRC at the first Linaro Connect last > >>>>>> year, or perhaps the ARM workshop in Prague, or perhaps also in various > >>>>>> ARM kernel list threads?) was that the DTBs should be stored/accessed in > >>>>>> exactly the same way as the kernel, which on many systems implies it's a > >>>>>> file in /boot (although MTD partitions, ... are also possible kernel > >>>>>> locations). The idea here was to explicitly make upgrading the DTB as > >>>>>> easy as upgrading the kernel, and explicitly without having to upgrade > >>>>>> any firmware, since that's a more dangerous process in most cases. > >>>>>> > >>>>>> Now perhaps that advice was only intended to apply very early on when DT > >>>>>> was really new on ARM, and has "aged out" by now? If so, I don't recall > >>>>>> that every being explicitly mentioned or communicated later. > >>>>> [snip out a bit more of Stephen's answer] > >>>>> > >>>>> Yes, this notion certainly is the opposite of what was suggested on the > >>>>> cross-distro list, both as part of a "what should a bootloader provide > >>>>> to get commodity distros to support the board" thread and the "where > >>>>> should a device tree live in the filesystem" thread. Cc'ing them now > >>>>> because this is one of those things that feels like it needs solving, > >>>>> solving soon, and done in a way the least number of folks get surprised > >>>>> about it. > >>>> > >>>> I don't think the "however they like" approach is that bad. It is > >>>> certainly less of a problem than "exactly the same way as the kernel" is. > >>>> > >>>> Using /boot implies a distro filesystem and we'd rather wish for DT to > >>>> be independent from a distro or even Linux. The DTB should therefore be > >>>> stored and accessed in a way which is hardware/bootloader specific. The > >>>> distro being installed on top shouldn't have to care. > >>> > >>> Right, the expectation has been set that the DT isn't supposed to be > >>> tied to the kernel and I don't wish to re-hash that. I'm asking, should > >>> we provide some expectations / guidance on how to store the DT? Should > >>> quirks be expected to be worked around at the DT consumer level (kernel, > >>> bootloader, whatever) or in updating the stored copy? That there rules > >>> out, or not, certain choices. > >> > >> Well, the hard guideline should require that the DTB be updateable and > >> not linked with nor generated by the bootloader or firmware. That > >> implies some storage separate from the bootloader but this doesn't need > >> to be a filesystem. > > > > I assume generated doesn't mean not updated. Do we want to limit the > > nodes that can be touched here? For example, a number of platforms have > > incorrect memory size (and on PowerPC, intentionally zero) so that the > > bootloader can correct them. And not linked with the bootloader may (or > > may not, Stephen, can you comment on what Tegra is doing at the moment?) > > make it harder to use in those cases. > > On Tegra, there are two DTBs: > > The first is attached to the U-Boot image, and parameterizes U-Boot > itself. The bindings used in this are often quite different from the > kernel:-( [snip] > Perhaps the two should be unified, although there isn't much interest in > bringing the U-Boot DT content up to scratch, it seems:-( I would just > ignore the U-Boot copy for now, and treat it as an internal > implementation detail of U-Boot. I would very much like to see them unified and used more in U-Boot. Most U-Boot development is about scratching ones own itch, is the biggest hurdle towards mass conversion to DTs (followed by the number of platforms that aren't being updated to DT in the kernel, followed by needing more conversion done in the kernel, bindings finalized, etc). But that's why I bring up "not attached to bootloader/firmware" as a question here. If we get the bindings in-sync, and make it easy to trim down a tree, we could still attach what the firmware needs to know to know about the rest of the system and have the full DT somewhere. > We certainly expect U-Boot to update the DT that's passed to the kernel, > for: > > * Memory size (although it's typically already correct in all the DTBs > anyway) ... for Tegra (for clarity). > * Command-line > * Possibly to add a "simplefb" node, until the kernel has LCD panel > support (CDF). Can we talk about that last one more? That sounds like some sort of temporary binding. Or am I using the terms wrong? But, it sounds like we're saying add whatever nodes might be missing? -- Tom -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
