linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: Jon Loeliger <jdl@jdl.com>
Cc: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: libfdt: a fix but still broken
Date: Fri, 23 Feb 2007 10:21:58 -0500	[thread overview]
Message-ID: <45DF0696.80301@smiths-aerospace.com> (raw)
In-Reply-To: <E1HKc1x-0001ze-0b@jdl.com>

Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
>> On Thu, Feb 22, 2007 at 08:27:29AM -0500, Jerry Van Baren wrote:
>>> Hi Dave,
>>>
>>> I have good news and bad news. ;-)  The good news is that the 
>>> incompatibility between libfdt and jdl's dtc is that libfdt has the name 
>>> offset and the length of the name switched.  booting_without_of.txt says 
>>> the length comes first, so libfdt is in the wrong.
>> Ouch.  That's.. a very embarrassing bug.  Actually, I know where it
>> came from: I was looking at flat_dt.h from dtc, which also gets this
>> wrong (but the declaration in question is unused).  Of course, I also
>> wrote flat_dt.h ...
>>
>>> The bad news is that, when I fix this, nearly all of the tests fail (but 
>>> they fail the same way for both tree.S and jdl's dtc).  I have not 
>>> started on that layer of the onion yet.
>> Found it, there was a direct use of the position of the length in
>> _fdt_next_tag().  Just pushed out a fix for this in the libfdt tree,
>> along with some other small fixes which I found while tracking this
>> one down.
>>
>> Oh, incidentally, I applied your patch by eye rather than with
>> patch(1), which was handy, because it appears to have been whitespace
>> damaged.
> 
> And amidst all of this, is there an actual DTC change needed?
> I've not detected one yet, but I'm watching... :-)
> 
> jdl

Hi Jon,

Your dtc is the "gold standard."  Gold doesn't tarnish.  ;-)

David's libfdt supports version 17 that dtc doesn't - I'm not sure where 
version 17 came from, David or elsewhere.  Version 17 adds one more size 
to the blob header structure and is suppose to be backward compatible 
with version 16. (A couple of the current libfdt tests fail when run 
against a dtc-generated version 16 blob - don't know where the fault 
lies yet.)

Best regards,
gvb

  reply	other threads:[~2007-02-23 15:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-22 13:27 libfdt: a fix but still broken Jerry Van Baren
2007-02-23  3:47 ` David Gibson
2007-02-23 12:59   ` Jerry Van Baren
2007-02-23 14:33     ` Jerry Van Baren
2007-02-23 22:24     ` David Gibson
2007-02-23 15:08   ` Jon Loeliger
2007-02-23 15:21     ` Jerry Van Baren [this message]
2007-02-23 22:47       ` David Gibson
2007-02-23 22:25     ` 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=45DF0696.80301@smiths-aerospace.com \
    --to=gerald.vanbaren@smiths-aerospace.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=jdl@jdl.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 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).