[dtc] Add support for flat device tree format version 17
Timur Tabi
timur at freescale.com
Thu Mar 15 12:37:56 EST 2007
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.
More information about the Linuxppc-dev
mailing list