From: "Grant Likely" <grant.likely@secretlab.ca>
To: linuxppc-dev@ozlabs.org, "David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: libfdt - flat tree manipulation library
Date: Sat, 2 Dec 2006 01:41:48 -0700 [thread overview]
Message-ID: <528646bc0612020041q32e8b1el3e8362f980f8f7b@mail.gmail.com> (raw)
In-Reply-To: <20061201060038.GA25476@localhost.localdomain>
On 11/30/06, David Gibson <david@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))
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.
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 |........@.......|
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.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
next prev parent reply other threads:[~2006-12-02 8:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-27 5:59 libfdt - flat tree manipulation library David Gibson
2006-11-29 5:59 ` David Gibson
2006-12-01 6:00 ` David Gibson
2006-12-01 13:11 ` Jerry Van Baren
2006-12-03 23:55 ` David Gibson
2006-12-02 8:41 ` Grant Likely [this message]
2006-12-04 0:03 ` David Gibson
2006-12-07 20:35 ` Hollis Blanchard
2006-12-07 22:23 ` David Gibson
2007-01-02 23:29 ` Mark A. Greer
2007-01-03 1:32 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528646bc0612020041q32e8b1el3e8362f980f8f7b@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).