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

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

[David Gibson]

libfdt defined a new version of the flattened device tree format,
version 17.  It is backwards compatible with version 16, just adding
an extra header field giving the size of the blob's structure blob.

This patch adds support to dtc allowing it to read and write version
17 blobs.  It also makes version 17 the default output version for
blobs.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c	2007-03-13 16:37:01.000000000 +1100
+++ dtc/dtc.c	2007-03-13 16:37:17.000000000 +1100
@@ -113,7 +113,7 @@ int main(int argc, char *argv[])
 	int opt;
 	FILE *inf = NULL;
 	FILE *outf = NULL;
-	int outversion = 0x10;
+	int outversion = 0x11;
 	int reservenum = 1;
 	int boot_cpuid_phys = 0xfeedbeef;
 
Index: dtc/flat_dt.h
===================================================================
--- dtc.orig/flat_dt.h	2007-03-13 16:33:23.000000000 +1100
+++ dtc/flat_dt.h	2007-03-13 16:38:09.000000000 +1100
@@ -25,11 +25,15 @@ struct boot_param_header {
 					    booting on */
 	/* version 3 fields below */
         uint32_t size_dt_strings;        /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;         /* size of the DT structure block */
 };
 
 #define BPH_V1_SIZE	(7*sizeof(uint32_t))
 #define BPH_V2_SIZE	(BPH_V1_SIZE + sizeof(uint32_t))
 #define BPH_V3_SIZE	(BPH_V2_SIZE + sizeof(uint32_t))
+#define BPH_V17_SIZE	(BPH_V3_SIZE + sizeof(uint32_t))
 
 struct reserve_entry {
 	uint64_t address;
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c	2007-03-13 16:32:58.000000000 +1100
+++ dtc/flattree.c	2007-03-13 17:20:53.000000000 +1100
@@ -26,6 +26,7 @@
 #define FTF_NAMEPROPS	0x4
 #define FTF_BOOTCPUID	0x8
 #define FTF_STRTABSIZE	0x10
+#define FTF_STRUCTSIZE	0x20
 
 static struct version_info {
 	int version;
@@ -41,6 +42,8 @@ static struct version_info {
 	 FTF_FULLPATH|FTF_VARALIGN|FTF_NAMEPROPS|FTF_BOOTCPUID|FTF_STRTABSIZE},
 	{0x10, 0x10, BPH_V3_SIZE,
 	 FTF_BOOTCPUID|FTF_STRTABSIZE},
+	{0x11, 0x10, BPH_V17_SIZE,
+	 FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_STRUCTSIZE},
 };
 
 struct emitter {
@@ -328,6 +331,8 @@ static void make_bph(struct boot_param_h
 		bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
 	if (vi->flags & FTF_STRTABSIZE)
 		bph->size_dt_strings = cpu_to_be32(strsize);
+	if (vi->flags & FTF_STRUCTSIZE)
+		bph->size_dt_struct = cpu_to_be32(dtsize);
 }
 
 void dt_to_blob(FILE *f, struct boot_info *bi, int version,
@@ -742,7 +747,7 @@ static struct node *unflatten_tree(struc
 
 struct boot_info *dt_from_blob(FILE *f)
 {
-	u32 magic, totalsize, version, size_str;
+	u32 magic, totalsize, version, size_str, size_dt;
 	u32 off_dt, off_str, off_mem_rsvmap;
 	int rc;
 	char *blob;
@@ -841,6 +846,13 @@ struct boot_info *dt_from_blob(FILE *f)
 		if (off_str+size_str > totalsize)
 			die("String table extends past total size\n");
 	}
+
+	if (version >= 17) {
+		size_dt = be32_to_cpu(bph->size_dt_struct);
+		fprintf(stderr, "\tsize_dt_struct:\t\t%d\n", size_dt);
+		if (off_dt+size_dt > totalsize)
+			die("Structure block extends past total size\n");
+	}
 			
 	if (version < 0x10) {
 		flags |= FTF_FULLPATH | FTF_NAMEPROPS | FTF_VARALIGN;

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[Mark A. Greer]

On Tue, Mar 13, 2007 at 05:22:40PM +1100, David Gibson wrote:
> Index: dtc/dtc.c
> ===================================================================
> --- dtc.orig/dtc.c	2007-03-13 16:37:01.000000000 +1100
> +++ dtc/dtc.c	2007-03-13 16:37:17.000000000 +1100
> @@ -113,7 +113,7 @@ int main(int argc, char *argv[])
>  	int opt;
>  	FILE *inf = NULL;
>  	FILE *outf = NULL;
> -	int outversion = 0x10;
> +	int outversion = 0x11;

Super-minor nit but since you seem to refer to the version as decimal
'17' everywhere else, why don't you just put '17' here?

Mark

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

[David Gibson]

On Tue, Mar 13, 2007 at 02:10:02PM -0700, Mark A. Greer wrote:
> On Tue, Mar 13, 2007 at 05:22:40PM +1100, David Gibson wrote:
> > Index: dtc/dtc.c
> > ===================================================================
> > --- dtc.orig/dtc.c	2007-03-13 16:37:01.000000000 +1100
> > +++ dtc/dtc.c	2007-03-13 16:37:17.000000000 +1100
> > @@ -113,7 +113,7 @@ int main(int argc, char *argv[])
> >  	int opt;
> >  	FILE *inf = NULL;
> >  	FILE *outf = NULL;
> > -	int outversion = 0x10;
> > +	int outversion = 0x11;
> 
> Super-minor nit but since you seem to refer to the version as decimal
> '17' everywhere else, why don't you just put '17' here?

Oh, because, the old code used hex.  Which it does in a totally
inconsistent fashion.  Yeah, I probably should take this opportunity
to start phasing out the use of hex.  Ok, revised patch coming.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[David Gibson]

libfdt defined a new version of the flattened device tree format,
version 17.  It is backwards compatible with version 16, just adding
an extra header field giving the size of the blob's structure blob.

This patch adds support to dtc allowing it to read and write version
17 blobs.  It also makes version 17 the default output version for
blobs.

At the same time we change the code to consistently using decimal
numbers for versions.  Previously we sometimes used 16 and sometimes
0x10 to refer to version 16.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c	2007-03-14 11:00:05.000000000 +1100
+++ dtc/dtc.c	2007-03-14 11:01:05.000000000 +1100
@@ -113,7 +113,7 @@ int main(int argc, char *argv[])
 	int opt;
 	FILE *inf = NULL;
 	FILE *outf = NULL;
-	int outversion = 0x10;
+	int outversion = 17;
 	int reservenum = 1;
 	int boot_cpuid_phys = 0xfeedbeef;
 
Index: dtc/flat_dt.h
===================================================================
--- dtc.orig/flat_dt.h	2007-03-14 11:00:06.000000000 +1100
+++ dtc/flat_dt.h	2007-03-14 11:00:06.000000000 +1100
@@ -25,11 +25,15 @@ struct boot_param_header {
 					    booting on */
 	/* version 3 fields below */
         uint32_t size_dt_strings;        /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;         /* size of the DT structure block */
 };
 
 #define BPH_V1_SIZE	(7*sizeof(uint32_t))
 #define BPH_V2_SIZE	(BPH_V1_SIZE + sizeof(uint32_t))
 #define BPH_V3_SIZE	(BPH_V2_SIZE + sizeof(uint32_t))
+#define BPH_V17_SIZE	(BPH_V3_SIZE + sizeof(uint32_t))
 
 struct reserve_entry {
 	uint64_t address;
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c	2007-03-14 11:00:06.000000000 +1100
+++ dtc/flattree.c	2007-03-14 11:00:06.000000000 +1100
@@ -26,6 +26,7 @@
 #define FTF_NAMEPROPS	0x4
 #define FTF_BOOTCPUID	0x8
 #define FTF_STRTABSIZE	0x10
+#define FTF_STRUCTSIZE	0x20
 
 static struct version_info {
 	int version;
@@ -39,8 +40,10 @@ static struct version_info {
 	 FTF_FULLPATH|FTF_VARALIGN|FTF_NAMEPROPS|FTF_BOOTCPUID},
 	{3, 1, BPH_V3_SIZE,
 	 FTF_FULLPATH|FTF_VARALIGN|FTF_NAMEPROPS|FTF_BOOTCPUID|FTF_STRTABSIZE},
-	{0x10, 0x10, BPH_V3_SIZE,
+	{16, 16, BPH_V3_SIZE,
 	 FTF_BOOTCPUID|FTF_STRTABSIZE},
+	{17, 16, BPH_V17_SIZE,
+	 FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_STRUCTSIZE},
 };
 
 struct emitter {
@@ -328,6 +331,8 @@ static void make_bph(struct boot_param_h
 		bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
 	if (vi->flags & FTF_STRTABSIZE)
 		bph->size_dt_strings = cpu_to_be32(strsize);
+	if (vi->flags & FTF_STRUCTSIZE)
+		bph->size_dt_struct = cpu_to_be32(dtsize);
 }
 
 void dt_to_blob(FILE *f, struct boot_info *bi, int version,
@@ -742,7 +747,7 @@ static struct node *unflatten_tree(struc
 
 struct boot_info *dt_from_blob(FILE *f)
 {
-	u32 magic, totalsize, version, size_str;
+	u32 magic, totalsize, version, size_str, size_dt;
 	u32 off_dt, off_str, off_mem_rsvmap;
 	int rc;
 	char *blob;
@@ -841,8 +846,15 @@ struct boot_info *dt_from_blob(FILE *f)
 		if (off_str+size_str > totalsize)
 			die("String table extends past total size\n");
 	}
+
+	if (version >= 17) {
+		size_dt = be32_to_cpu(bph->size_dt_struct);
+		fprintf(stderr, "\tsize_dt_struct:\t\t%d\n", size_dt);
+		if (off_dt+size_dt > totalsize)
+			die("Structure block extends past total size\n");
+	}
 			
-	if (version < 0x10) {
+	if (version < 16) {
 		flags |= FTF_FULLPATH | FTF_NAMEPROPS | FTF_VARALIGN;
 	}
 
Index: dtc/ftdump.c
===================================================================
--- dtc.orig/ftdump.c	2007-03-14 11:00:06.000000000 +1100
+++ dtc/ftdump.c	2007-03-14 11:00:06.000000000 +1100
@@ -144,7 +144,7 @@ static void dump_blob(void *blob)
 		}
 		sz = GET_CELL(p);
 		s = p_strings + be32_to_cpu(GET_CELL(p));
-		if (version < 0x10 && sz >= 8)
+		if (version < 16 && sz >= 8)
 			p = PALIGN(p, 8);
 		t = p;
 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[Timur Tabi]

David Gibson wrote:

> -	{0x10, 0x10, BPH_V3_SIZE,
> +	{16, 16, BPH_V3_SIZE,
>  	 FTF_BOOTCPUID|FTF_STRTABSIZE},
> +	{17, 16, BPH_V17_SIZE,

So this is compatible with version 16?  Does that mean that a V17 DTB 
will work fine with U-Boot today?  Or will we need to update U-Boot?

The reason I ask is that I created a patch for U-Boot that tests the 
version of the DTB before attempting to process it.  By marking V17 to 
be compatible with V16, the patch will make U-Boot assume that it can 
parse the DTB.

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

[Jon Loeliger]

So, like, the other day David Gibson mumbled:
> libfdt defined a new version of the flattened device tree format,
> version 17.  It is backwards compatible with version 16, just adding
> an extra header field giving the size of the blob's structure blob.
> 
> This patch adds support to dtc allowing it to read and write version
> 17 blobs.  It also makes version 17 the default output version for
> blobs.
> 
> At the same time we change the code to consistently using decimal
> numbers for versions.  Previously we sometimes used 16 and sometimes
> 0x10 to refer to version 16.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Applied.

Thanks,
jdl

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

[Timur Tabi]

David Gibson wrote:
> libfdt defined a new version of the flattened device tree format,
> version 17.  It is backwards compatible with version 16, just adding
> an extra header field giving the size of the blob's structure blob.

Question:

Since the DTB is compatible with V16, then technically U-Boot can work with it.  What 
would happen if U-Boot added some nodes to the DTB, but it didn't update size_dt_struct? 
Would the value of size_dt_struct still be correct?  If not, then does that mean that 
U-Boot should reject V17 DTBs?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Jerry Van Baren]

Timur Tabi wrote:
> David Gibson wrote:
>> libfdt defined a new version of the flattened device tree format,
>> version 17.  It is backwards compatible with version 16, just adding
>> an extra header field giving the size of the blob's structure blob.
> 
> Question:
> 
> Since the DTB is compatible with V16, then technically U-Boot can work with it.  What 
> would happen if U-Boot added some nodes to the DTB, but it didn't update size_dt_struct? 
> Would the value of size_dt_struct still be correct?  If not, then does that mean that 
> U-Boot should reject V17 DTBs?

Ahh, now I see your concern and don't know the answer at this point.

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.

gvb

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

[Timur Tabi]

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 don't think that will help, because the problem is how do you update a device tree that 
you don't know everything about?

 > I very much want v17 blobs because that removes my
> "write-in-place" restrictions on changing the properties.

Another idea which just came to light is to have the compatibility field be only useful to 
code that just *reads* the DTB.  Any code that *writes* the DTB should look it.

Since the kernel only reads the DTB, it can use the compatibility field.  Since U-Boot 
writes to the DTB, it should currently only accept true V16 DTBs.

If the kernel were to ever write to the DTB, then it would have to be as restrictive.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[David Gibson]

On Wed, Mar 14, 2007 at 04:20:29PM -0500, 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 don't think that will help, because the problem is how do you
> update a device tree that you don't know everything about?
> 
>  > I very much want v17 blobs because that removes my
> > "write-in-place" restrictions on changing the properties.
> 
> Another idea which just came to light is to have the compatibility
> field be only useful to code that just *reads* the DTB.  Any code
> that *writes* the DTB should look it.

Yes, that's always been true for the compatibility version field
(version 3 had exactly the same problem, for example).  Code which
writes the dtb has to understand everything it writes.  Or to put it
another way, the 'version' field records the version of the writer,
'last_comp_version' field records the version of the reader.

But a program which manipulates a tree, like u-boot is both a reader
and a writer.  It *can* take in a higher compatible version and alter
it as long as it downgrades the version on its output to the highest
thing it fully understands.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[Jerry Van Baren]

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

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

[Timur Tabi]

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.

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

[David Gibson]

On Wed, Mar 14, 2007 at 09:32:25PM -0400, Jerry Van Baren wrote:
> 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).

In fact, with a v16 blob, libfdt is suppose to allow expansion and
contraction by first converting it to a v17 blob.  I just haven't
implemented that yet.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[Jerry Van Baren]

Timur Tabi wrote:
> 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.

That is close to the top of my list.  My intent with the "fdt" command 
is to have a subcommand that creates the "chosen" node.  This will 
replace the auto-generation (with no opportunity to review or revise) 
the "chosen" node as part of the "bootm" command.

Downside: "bootm" becomes more than one command.  So script it.
Upside: MUCH cleaner, allows the user to review and revise the blob 
before booting linux.

These are my current thoughts for the "fdt" command:
=> help fdt
fdt addr   <addr>                  - Set the fdt location to <addr>
fdt get    <node> <property>       - Get the value of <node> <property>
fdt set    <node> <property> <val> - Set the value of <property> to <val>
     (creates a new property if necessary)
fdt mknode <node>                  - Create a new node <node>
     (the path must exist except for the last node name)
fdt rmnode <node>                  - Deletes the node <node>
     (the last node name in the path)
fdt print  <node> [<property>]     - Recursive print starting at <node>
     (if <property> is specified, prints only that property)
fdt chosen - Add/update the "chosen" branch to the tree
Hints:
  * "fdt print /" prints the whole tree.
  * If the property you are setting/printing has a '#' character,
      you MUST escape it with a \ character or quote it with " or
      it will be ignored as a comment.
  * If the value has spaces in it, you MUST escape the spaces with
      \ characters or quote it with "
Examples: fdt p /cpus "#address-cells"
           fdt s /cpus "#address-cells" "[00 00 00 01]"

I've actually implemented addr, set, and print (get is an alias for print).

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

libfdt.

David already did the work, I'm working on the integration (works but 
needs some cleanup).

gvb