All of lore.kernel.org
 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 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.