On Thu, Aug 15, 2013 at 11:45:57AM -0400, Nicolas Pitre wrote: > On Thu, 15 Aug 2013, 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: > > > > > 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. > > Indeed. For instance, the bootloader is likely to update it with some > user provided kernel cmdline string, and possibly ethernet MAC addresses > and/or some board serial number, etc. Right, command line, memory and mac addresses are what U-Boot does today. Is there a standard binding for board serial number? If so we could update that too, if set. > BTW providing a unique serial number via DT to the kernel would help a > lot in the seeding of the kernel's random pool. > > > 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. > > U-Boot let you update any node you want once you've told it where in > memory the DTB is. I suppose such thing can be scripted or even added > to the board specific U-Boot support easily. As long as people are not > overriding every nodes I suppose this is reasonable. Right, U-Boot has a 'fdt' command for fiddling with the in-memory DT as well as updating certain nodes as part of booting the kernel. This could be used to "hotfix" the stored device tree if desired. Today this is used more (or at least, so it seems) while developing your DT, or simply functionality people didn't widely know was there. > Especially if the hardware may accommodate different amount of RAM, in > that case there is no other way than runtime probing of that RAM and the > DTB must be updated accordingly. This is probably why many PowerPC platforms have a zero size memory node, yes. At one point I was talking about saying the standard should be zero, and then we assume that a non-zero value must be correct (for platforms with lots and lots of memory where U-Boot is setting things wrong now). > > > And the DTB should be updated far less often than the kernel. So that > > > might be acceptable to have a special bootloader-specific procedure to > > > update it. > > > > Right. But you wouldn't want it to be a hardware mod to make things be > > writable again (thinking the EEPROM I mentioned before). > > No. > > It must be end user updatable, even if the bootloader itself might not > always be. So one of the rules for the guidelines :) > > > I expect that the kernel will have to deal with quirks from a bad DTB > > > that has already been deployed. But those quirks workarounds only have > > > to make things minimally work while the optimal state would come from an > > > updated DTB. Same story as with bad BIOSes on a X86 system. > > > > > > More importantly, a DTB update is likely to be useful in providing new > > > data the previous DTB didn't include e.g. if some bindings weren't > > > finalized when the initial deployment took place. > > > > And what bindings it should use in the interm depends on the general > > outcome of when bindings get locked in and how all of that. But does > > this mean that the expectation, on the kernel side, would be that a > > developer should use the latest published bindings for a platform, or > > the bindings that shipped the very first time? For bootloaders the rule > > is "whatever shipped on the hardware shouldn't be touched". > > I think the debate on this very topic is still ongoing. Right. And that's part of why I brought the topic up. Using my magic VPN-based crystal ball, I can see when for example TI plans to release platforms, think a little about timelines and go "Gee, if we want the device tree included with the hardware when it ships, I need to know what's expected somewhere between a month from now and 3 months ago, crap.". -- 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
