public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: gvb.uboot <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] mpc83xx boot error
Date: Wed, 12 Dec 2007 19:44:46 -0500	[thread overview]
Message-ID: <4760807E.5030006@gmail.com> (raw)
In-Reply-To: <000c01c83d15$259c7fc0$6405a8c0@absolut>

Russell McGuire wrote:
> All,
> 
> I have downloaded the latest U-boot 1.3.0 dirty <a week old> and 
> compiled it up for a 8360E-MDS board.
> 
> I have downloaded the latest version of the DTC 1.0.0-ge1109207 today, 
> and compiled up a preconfigured dts file
> 
> and burnt that into flash. Also I have downloaded denx?s latest 
> linux-git tree 2.6.23.1 and configured it for said board.
> 
> However, when I try to boot Linux, I get an immediate error as follows:
> 
>>  bootm $kerneladdr - $blobaddr
> 
> ?. Bla bla standard printf??
> 
> Uncompressing the Kernel Image ? OK
> 
> Booting using the fdt at 0xe0080000
> 
> Loading device tree to 0x007fe000, end 0x007ff432 ? ERROR: fdt move 
> failed ? must reset board to recover. Resetting the board.
> 
> I am coming at this from my experience with U-boot 1.1.2 and 1.1.6 and a 
> 1 yr old version of the dtc compiler.
> 
> Are there new options, or less options that should be used with the dtc 
> compiler to avoid this error?
> 
> I know before we had to fix the version of the blob, so perhaps I am 
> compiling the blob wrong? The dts file compiles fine with no warnings.
> 
> dtc ?I dts ?O dtb ?f ?V 0x10
> 
> Using this without ?V 0x10 gives me a different error
> 
> dtc ?I dts ?O dtb -f
> 
> WARNING: could not create /chosen FDT_ERR_NOSPACE
> 
> ERROR: /chosen node create failed - must RESET the board to recover
> 
> Anybody have any ideas?

Hi Russell,

* You need to use version 17 (simply don't specify -V 0x10).
* As Kim mentioned, you need -S padding to allow extra space for the
     /chosen node.
* Since you burned the blob into flash, bootm has to relocate the blob
    to RAM.  This is what is giving you the "fdt move failed" error in
    your first example, it is moving the blob to 0x007fe000 - is this
    a valid address (seems like it should be)?  Perhaps it is simply
    because you didn't pad it?  Perhaps we let a bug slip in?

Good luck,
gvb

  parent reply	other threads:[~2007-12-13  0:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-12 23:17 [U-Boot-Users] mpc83xx boot error Russell McGuire
2007-12-12 23:21 ` Kim Phillips
2007-12-13  0:44 ` gvb.uboot [this message]
2007-12-13  0:54   ` gvb.uboot
  -- strict thread matches above, loose matches on Subject: below --
2008-02-28 12:06 Marc Leeman
2008-02-28 12:36 ` Jerry Van Baren
2008-02-28 13:03   ` Marc Leeman

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=4760807E.5030006@gmail.com \
    --to=gvb.uboot@gmail.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