Re: [dtc] Add support for flat device tree format version 17

[Jerry Van Baren <gerald.vanbaren@comcast.net>]

Timur Tabi wrote:
> Jerry Van Baren wrote:
> 
>> The best solution, which I'm making progress on but slowly, is to pull 
>> David Gibson's libfdt utilities into u-boot and use them to manipulate 
>> the tree.  I very much want v17 blobs because that removes my 
>> "write-in-place" restrictions on changing the properties.
> 
> Here's an alternative idea I got from a colleage (Scott Wood).
> 
> Allow U-Boot to accept V17 DTBs.  When it modifies the DTB, it should change the version 
> to 16, since that's the only version that it really knows.  U-Boot currently does not have 
> the infrastructure to support multiple DTB versions.
> 
> The DTB that U-Boot passes to the kernel will say V16, but it will have the extra length 
> field in the header.  Therefore, we need to update the documentation to say that 
> compatibility implies that any DTB will still be able to read the DTB if the DTB version 
> number has been changed to another compatible version.  So if your DTB is V17, and it has 
> V17 data, any code that assumes a V16 DTB should still be able to read it.  That seems 
> obvious, but is should be documented.

Actually, I believe that is how the existing code works: it opens the 
original blob and copies it to a newly created dft.  It then augments 
the new dft with a "chosen" node and optionally additional nodes (bd_t, 
env variables) and passes the new dft blob to linux.  Theoretically, the 
existing code will read a v17 blob and create a new v16 blob from it 
(without the additional v17 length field - the header would be created, 
not copied).

Trivia: the current code is kinda dumb about it: if the original blob 
had a "chosen" node, the code *adds another* "chosen" node.

Back to libdft: with a v16 blob, libdft has to either modify in place 
(no size change) or you have to create a new blob and copy the original 
data over (like the existing code).  With the v17 blob, libdft is able 
to expand and contract the contents of the blob (with limitations, I'm 
sure).

Best regards,
gvb