[PATCH 0/2] libfdt: problems with real life blobs

[PATCH 0/2] libfdt: problems with real life blobs

[Jerry Van Baren]

Hi David,

I've been trying to use your libfdt in u-boot and my first step, get a 
value from the blob, failed terminally.  After poking about a bit, it 
appears that your libfdt and Jon Loeliger's dtc (-V 16) disagree with 
respect to the format of the blob - libfdt won't traverse the path.

I've created two patches:
1) Make the libfdt tests use "fdt endian" so that dtc can be used.
2) Create a minimal test tree and compile it with dtc.

The first patch is clean, the second patch is a bit of a hack job, I did 
just enough to check this out and confirm/deny my suspicions that libfdt 
doesn't like the dtc format.  Running the tests on the dtc-compiled blob 
shows the same problems with traversing paths.

I think I created the correct tree in test_tree1.dts (I didn't do the 
truncated node, but that is immaterial for my primary objective) but I 
could be wrong...

Supporting using dtc in the long run as well as the assembly-generated 
blob would be nice so that regression tests can be done on different 
versions of the blob format (both supported and unsupported) and to make 
sure libfdt and dtc stay in sync.

Best regards,
gvb

Re: [PATCH 0/2] libfdt: problems with real life blobs

[David Gibson]

On Mon, Feb 19, 2007 at 01:00:57PM -0500, Jerry Van Baren wrote:
> Hi David,
> 
> I've been trying to use your libfdt in u-boot and my first step, get a 
> value from the blob, failed terminally.  After poking about a bit, it 
> appears that your libfdt and Jon Loeliger's dtc (-V 16) disagree with 
> respect to the format of the blob - libfdt won't traverse the path.

That's certainly bad.

> I've created two patches:

Ug.  Damn.  Trouble is, for IBM paranoid procedural reasons, I'm not
really in a position to accept patches for libfdt from outside at
present.  I'm already working on fixing that, but there being a
ponderous bureaucracy involved, it's going to take a little while.

Oh, plus I want to relicense libfdt (so it can be used in non-GPL
firmware), so for that reason also I can't accept random patches at
present.

> 1) Make the libfdt tests use "fdt endian" so that dtc can be used.

That sounds sensible, I was always pretty dubious about using a
different endianness for the framing and content in the tests.

> 2) Create a minimal test tree and compile it with dtc.
> 
> The first patch is clean, the second patch is a bit of a hack job, I did 
> just enough to check this out and confirm/deny my suspicions that libfdt 
> doesn't like the dtc format.  Running the tests on the dtc-compiled blob 
> shows the same problems with traversing paths.
> 
> I think I created the correct tree in test_tree1.dts (I didn't do the 
> truncated node, but that is immaterial for my primary objective) but I 
> could be wrong...
> 
> Supporting using dtc in the long run as well as the assembly-generated 
> blob would be nice so that regression tests can be done on different 
> versions of the blob format (both supported and unsupported) and to make 
> sure libfdt and dtc stay in sync.

Yes, absolutely.  I want to merge libfdt and dtc into a single
package, so they can be used to test each other.  Again, planning to
do that just as soon as I get the bureaucratic hurdles out of the way.

-- 
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: [PATCH 0/2] libfdt: problems with real life blobs

[Jerry Van Baren]

David Gibson wrote:
> On Mon, Feb 19, 2007 at 01:00:57PM -0500, Jerry Van Baren wrote:
>> Hi David,
>>
>> I've been trying to use your libfdt in u-boot and my first step, get a 
>> value from the blob, failed terminally.  After poking about a bit, it 
>> appears that your libfdt and Jon Loeliger's dtc (-V 16) disagree with 
>> respect to the format of the blob - libfdt won't traverse the path.
> 
> That's certainly bad.
> 
>> I've created two patches:
> 
> Ug.  Damn.  Trouble is, for IBM paranoid procedural reasons, I'm not
> really in a position to accept patches for libfdt from outside at
> present.  I'm already working on fixing that, but there being a
> ponderous bureaucracy involved, it's going to take a little while.

That's OK, just call it "the illustration of advice formerly known as a 
patch."  I just hope I didn't poison the well. ;-)

Seriously, I don't claim copyright on the changes, that would be 
inappropriate their trivial nature.  I do understand IBM's paranoia, 
however.  }:-(

gvb