libfdt - flat tree manipulation library

[David Gibson]

On Sat, Dec 02, 2006 at 01:41:48AM -0700, Grant Likely wrote:
> On 11/30/06, David Gibson <david at gibson.dropbear.id.au> wrote:
> > On Wed, Nov 29, 2006 at 04:59:04PM +1100, David Gibson wrote:
> > > On Mon, Nov 27, 2006 at 04:59:05PM +1100, David Gibson wrote:
> > > [snip]
> > > > The code, such as it is, is at:
> > > >     git://ozlabs.org/home/dgibson/git/libfdt.git
> > >
> > > Code for writing device trees from scratch, sequentially, is now
> > > implemented.
> >
> > And now support for random access read-write is implemented.  The
> > library is now close to feature-complete, cleanups and convenience
> > wrappers remain.
> 
> I've run into some problems running this on an amd64 host.  There are
> problems with the byte swapping code where libfdt.h is trying to byte
> swap the fdt pointer, not the value it points to.
> 
> Ie, I think this:
> #define fdt_magic(fdt)			(fdt32_to_cpu(fdt)->magic)
> should really be this:
> #define fdt_magic(fdt)			(fdt32_to_cpu(fdt->magic))

Erk!  That's.. highly embarrasing.  I was getting to testing on a
little endian machine...

> As is it doesn't compile on amd64 (and probably not x86 either).  I
> suspect that you want to do your byte swap on the value in the
> structure field, not on the pointer to the structure.  :)  However,
> the test cases fail spectacularly when I change the byte swap to be on
> the value in the structure.  If I comment out the byte swap entirely
> in libfdt_env.h; then the test cases unexpectedly pass!  So I did some
> digging.  The test cases are generating little-endian device trees;
> looks like test/trees.S is at fault.  I would say that a different
> mechanism is needed to generate the .dtb files.

Oh, crud.  Yes of course.

> For example; here's the first 16 bytes of my lite5200 device tree:
> 00000000  d0 0d fe ed 00 00 15 b7  00 00 00 38 00 00 14 5c  |...........8...\|
> Here's the first 16 bytes of tests/rw_tree1.test.dtb; clearly wrong endian!
> 00000000  ed fe 0d d0 1a 01 00 00  40 00 00 00 08 01 00 00  |........ at .......|

Um.. yes.. but in the case if rw_tree1 this is because you commented
out the byteswaps - this one is generated by the code in fdt_rw.c.
test_tree1.dtb is the only one from trees.S

> Anyway; I'll send a patch to fix up part of the byte swapping code;
> but I haven't looked into other ways of creating the .dtb files.

Um.. yes.  I really don't want to have to fuss with hex editors and
including binary files in the distribution.  Ah, but I think I have
the solution, I can make a macro using .byte directives to explicitly
output things with the correct endianness.

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