public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Testing todays u-boot-fdt
Date: Thu, 19 Apr 2007 15:10:34 +0200	[thread overview]
Message-ID: <46276A4A.6050209@grandegger.com> (raw)
In-Reply-To: <46275BC2.6080506@smiths-aerospace.com>

Jerry Van Baren wrote:
> Wolfgang Grandegger wrote:
>> Hi Jerry,
>>
>> I gave the fdtlib of your git://cideas.us/pub/scm/u-boot/u-boot-fdt.git
>> a try on my Icecube board. I got it built with the attached patch. 
>> libfdt was actually not made and the second hunk fixes a warning 
>> (=bug?). Then I was able to read and list a blob in memory:
>>
>> => fdt addr 20000
>> => fdt print /
>> ...
>>
>> A few other things didn't work, especially updating the FDT:
>>
>> => fdt addr 20000 10000
>> libfdt: FDT_ERR_BADVERSION
>>
>> => fdt env
>> libfdt: FDT_ERR_BADVERSION
>> => fdt bd_t
>> libfdt: FDT_ERR_BADVERSION
>> => fdt chosen
>> libfdt: FDT_ERR_BADVERSION
>>
>> => fdt set /memory reg "<00000000 08000000>"
>> Usage:
>> fdt     - flattened device tree utility commands
>>
>> And "fdt mknode" seems not to be implemented.
>>
>> Am I doing something wrong?
>>
>> Wolfgang.
> 
> Hi Wolfgang,
> 
> Ouch, that was a bad bug and very embarrassing.  Just when you think you 
> are perfect, a stupid pointer error jumps up and bits you.  :-(  I'll 
> apply your patch.  Thanks & sorry.

Well, nobody is ...

> 
> The bad version error is because you are running a version 16 blob and 
> you need a version 17 blob to allow modifications.  David Gibson has an 
> intention of upconverting a v16 to v17 as part of libfdt, but neither of 
> us has gotten around to doing it yet.

OK, I can now update the FDT, apart from "mknode", but have still 
problems booting Linux-2.6.21-rc7. Should it already work?

> If you pick up the latest dtc, it compiles v17 by default now.  The 
> latest dtc also implements a -S <minsize> parameter so you can make 
> extra space in the blob and not need to specify the length parameter 
> with the "fdt addr" command (the length parameter for addr makes the 
> blob longer - unnecessary with -S blobs).  If you really want to be at 
> the bleeding edge, you can apply this patch as well, but it is *not* 
> necessary (the patch pads out the blob rather than leaving the extra 
> space undefined):
>   <http://article.gmane.org/gmane.linux.ports.ppc64.devel/18741>
> 
> See also:
> <http://www.denx.de/wiki/UBoot/UBootFdtInfo>
> (linked off the Custodian page).

Ah, I was not yet aware of that link. It's very useful, indeed.

> On a related note, you will probably want a fdt_find_compatible_node() 
> function added to libfdt.  I looked at the kernel one and it looks like 
> it would be pretty simple to adapt it to libfdt, but I have not gotten 
> to it yet.
> 
> <http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#ToDo_libfdt>
>    2. fdt_find_compatible_node() Ref: arch/powerpc/kernel/prom.c
>           * Needed if we use fdt blobs to configure u-boot drivers

OK.

Thanks.

Wolfgang.

  reply	other threads:[~2007-04-19 13:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-19  8:58 [U-Boot-Users] Testing todays u-boot-fdt Wolfgang Grandegger
2007-04-19 12:08 ` Jerry Van Baren
2007-04-19 13:10   ` Wolfgang Grandegger [this message]
2007-04-19 13:19     ` Jerry Van Baren
2007-04-19 15:24   ` Timur Tabi
2007-04-22 20:38   ` Timur Tabi
2007-04-23  0:05     ` Jerry Van Baren
2007-04-19 13:28 ` Jerry Van Baren
2007-04-19 13:42   ` Wolfgang Grandegger
2007-04-19 15:51   ` Wolfgang Denk
2007-04-19 23:11     ` Jerry Van Baren
2007-04-19 23:19       ` Wolfgang Denk
2007-04-20 16:36       ` Wolfgang Grandegger
2007-04-20 17:11         ` Jerry Van Baren
2007-04-20 20:40           ` Wolfgang Denk
2007-04-20 22:02             ` Jerry Van Baren
2007-04-20  3:38 ` Jerry Van Baren
2007-04-20 13:32   ` Wolfgang Denk
2007-04-20  3:40 ` Jerry Van Baren
     [not found] <4629358C.5050401@cideas.com>
2007-04-20 23:01 ` Wolfgang Denk

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=46276A4A.6050209@grandegger.com \
    --to=wg@grandegger.com \
    --cc=u-boot@lists.denx.de \
    /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