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

[Timur Tabi <timur@freescale.com>]

Jerry Van Baren wrote:

> 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).

I'll check out the code and see what it does, since I'm not really 
familiar with it.

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

Yes, I have this bug on my to-do list to fix.

> 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).

I agree that it would be nice if U-Boot had a robust DTB parser, but I 
don't have the time to do that work.