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:-(
The second is the DTB passed to the kernel. Right now, we're using the
model of putting this in /boot on the root filesystem and having the
U-Boot boot script load it (with filename generated as
${soc}-${board}.dtb) and pass it to the kernel. Moving this into boot
flash at some well-known location rather than the filesystem might be
possible in the long term.
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.
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)
* Command-line
* Possibly to add a "simplefb" node, until the kernel has LCD panel
support (CDF).
--
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
