On Sat, Dec 02, 2006 at 01:41:48AM -0700, Grant Likely wrote:

On 11/30/06, David Gibson [off-list ref] wrote:

quoted

On Wed, Nov 29, 2006 at 04:59:04PM +1100, David Gibson wrote:

quoted

On Mon, Nov 27, 2006 at 04:59:05PM +1100, David Gibson wrote:
[snip]

quoted

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

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