From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] mpc83xx boot error
Date: Thu, 28 Feb 2008 07:36:16 -0500 [thread overview]
Message-ID: <47C6AAC0.9040902@ge.com> (raw)
In-Reply-To: <20080228120612.GP16684@chiana.homelinux.org>
Marc Leeman wrote:
>>> * 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?
>>>
>> Oops, I missed the -R 8 that Kim recommended (very correctly). This
>> makes more reserved map entries which is important as well as the -S
>> extra space.
>
> I don't think this fully describes it, I just came across the same error
> when porting from 1.3.1 to 1.3.2-rc2:
>
> dtc -I dts -O dtb -S 0x3000 -R 8
>
> with dtc 1.1.0
>
> still gives the following when booting u-boot-1.3.2-rc2:
>
> ## Booting image at fe700000 ...
> Image Name: Linux-2.6.24
> Created: 2008-02-25 15:38:37 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 930624 Bytes = 908.8 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0xfefe0000
> Loading Device Tree to 007fe000, end 007ff4e1 ... OK
> WARNING: could not create /chosen FDT_ERR_NOSPACE.
> ERROR: /chosen node create failed - must RESET the board to recover.
> Resetting the board.
Hi Marc,
Hmmm, this is an interesting line:
> Loading Device Tree to 007fe000, end 007ff4e1 ... OK
I have not looked who generates this printout, but it seems to indicate
the fdt is 0x14e1 in length.
Is the "interesting line" indicating that the blob got moved *and
truncated*? If it is being truncated, that would be why it runs out of
space creating the /chosen node.
What sort of image/combination are you booting? I'm booting a separate
linux image, fdt blob, and RAM disk and my boot sequence looks
different, including not having the "Loading Device Tree..." line.
=> tftp $ramdiskaddr $ramdiskfile ; tftp $fdtaddr $fdtfile ; tftp
$loadaddr $bootfile
UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
Using FSL UEC0 device
TFTP from server 192.168.47.8; our IP address is 192.168.47.214
Filename 'mpc8360emds/uRamdisk'.
Load address: 0x1000000
Loading: T #################################################################
########################################
done
Bytes transferred = 1531127 (175cf7 hex)
Using FSL UEC0 device
TFTP from server 192.168.47.8; our IP address is 192.168.47.214
Filename 'mpc8360emds/mpc836x_mds.dtb'.
Load address: 0x400000
Loading: #
done
Bytes transferred = 12288 (3000 hex)
Using FSL UEC0 device
TFTP from server 192.168.47.8; our IP address is 192.168.47.214
Filename 'mpc8360emds/uImage'.
Load address: 0x200000
Loading: #################################################################
##########################
done
Bytes transferred = 1329289 (144889 hex)
=> bootm $loadaddr $ramdiskaddr $fdtaddr
## Booting image at 00200000 ...
Image Name: Linux-2.6.25-rc3-00001-g5fb74e4-
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1329225 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01000000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1531063 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using the fdt at 0x400000
Loading Ramdisk to 0fe2b000, end 0ffa0cb7 ... OK
Using MPC836x MDS machine description
Linux version 2.6.25-rc3-00001-g5fb74e4-dirty (vanbaren at dellserver) (gcc
version
4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Mon Feb 25 20:38:46 EST 2008
Found initrd at 0xcfe2b000:0xcffa0cb7
console [udbg0] enabled
setup_arch: bootmem
mpc836x_mds_setup_arch()
:
[snip]
:
root:~>
Best regards,
gvb
next prev parent reply other threads:[~2008-02-28 12:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-28 12:06 [U-Boot-Users] mpc83xx boot error Marc Leeman
2008-02-28 12:36 ` Jerry Van Baren [this message]
2008-02-28 13:03 ` Marc Leeman
2008-02-28 14:03 ` [U-Boot-Users] mpc83xx SPI Richard Parsons
2008-02-28 14:41 ` Ben Warren
2008-02-28 14:48 ` Richard Parsons
-- strict thread matches above, loose matches on Subject: below --
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
2007-12-13 0:54 ` gvb.uboot
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=47C6AAC0.9040902@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 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.