From: David Gibson <david@gibson.dropbear.id.au>
To: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 0/2] libfdt: problems with real life blobs
Date: Tue, 20 Feb 2007 10:46:31 +1100 [thread overview]
Message-ID: <20070219234631.GD17818@localhost.localdomain> (raw)
In-Reply-To: <45D9E5D9.6060704@smiths-aerospace.com>
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
next prev parent reply other threads:[~2007-02-19 23:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-19 18:00 [PATCH 0/2] libfdt: problems with real life blobs Jerry Van Baren
2007-02-19 23:46 ` David Gibson [this message]
2007-02-20 13:02 ` Jerry Van Baren
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=20070219234631.GD17818@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=gerald.vanbaren@smiths-aerospace.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.