From mboxrd@z Thu Jan 1 00:00:00 1970 From: gvb.uboot Date: Wed, 12 Dec 2007 19:54:16 -0500 Subject: [U-Boot-Users] mpc83xx boot error In-Reply-To: <4760807E.5030006@gmail.com> References: <000c01c83d15$259c7fc0$6405a8c0@absolut> <4760807E.5030006@gmail.com> Message-ID: <476082B8.3050406@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de gvb.uboot wrote: > Russell McGuire wrote: >> All, >> >> I have downloaded the latest U-boot 1.3.0 dirty 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 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. gvb