public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] libfdt problem when loading device tree
Date: Thu, 13 Dec 2007 11:46:37 -0500	[thread overview]
Message-ID: <476161ED.3070603@ge.com> (raw)
In-Reply-To: <1197563083.8607.19.camel@gentoo-jocke.transmode.se>

Joakim Tjernlund wrote:
> I get this when I try to boot my board:
> ## Booting image at 00200000 ...
>    Image Name:   oskernel02a:p1a:99
>    Created:      2007-12-13   9:59:43 UTC
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1238992 Bytes =  1.2 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
>    Loading Device Tree to 007fe000, end 007ff6f9 ... OK
> WARNING: could not create /bd_t FDT_ERR_NOSPACE.
> fdt_bd_t: FDT_ERR_NOSPACE
> ERROR: /bd_t node create failed - must RESET the board to recover.
> Resetting the board.
> 
> I have tried different combinations of -S and -R options to dtc,
> but nothing helps:
> dtc -S 2000 -R 2000 -f of-tmcu.dts -O asm > of-tmcu.S

-S 2000 may be too small, I found I needed -S 3000.  If you run dtc 
without the -S option and add in a verbose/info option(?), dtc will tell 
you how big your blob is without any padding.  Obviously, you need to 
pad it.

-R 2000 is big time overkill, I've found -R 8 is plenty.  These are the 
memory reserve slots.

> If I remove the chosen node from my dts file, I get the error when
> libfdt tries to create a chosen node.

I don't believe having a /chosen node in the source is recommended.  The 
idea is that u-boot's board configuration customization should create 
the /chosen node with the proper values either from a-priori knowledge 
or from probing.

> I am using dtc 1.0.0 and u-boot 1.3.1
> 
>  Jocke

Sounds like a bug with the move operation from flash to RAM.  What 
happens if you copy the blob from flash to RAM from the u-boot command line?

(from memory so I may be wrong)

 > fdt move <source> <ramblobaddr>
 > bootm <ramdisk> <ramblobaddr>

gvb

  parent reply	other threads:[~2007-12-13 16:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 16:24 [U-Boot-Users] libfdt problem when loading device tree Joakim Tjernlund
2007-12-13 16:34 ` Kumar Gala
2007-12-13 16:39   ` Joakim Tjernlund
2007-12-13 18:59   ` Jerry Van Baren
2007-12-13 22:11     ` Joakim Tjernlund
2007-12-13 16:46 ` Jerry Van Baren [this message]
2007-12-13 17:00   ` Joakim Tjernlund
2007-12-13 17:07   ` Joakim Tjernlund
2007-12-13 17:16     ` Joakim Tjernlund
2007-12-13 18:03     ` Jerry Van Baren
2007-12-13 18:17       ` Joakim Tjernlund

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=476161ED.3070603@ge.com \
    --to=gerald.vanbaren@ge.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