[U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex

[U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex

[jeffhemstreet at yahoo.com]

I have been searching the web, but I have not seen any mention of this kind of problem.

I am using a custom 405ex board based on Kilauea, with NAND boot.  (256MB NAND and 256MB DDR DRAM.)  The DRAM passes all tests, and the board boots into Linux fine.  When adding code to the initrd, we found that any image > 16MB seemed to cause this problem after being loaded.
I also tested on Kilauea, and it happens but only with a uboot 1.3.3 image running from NAND, the default NOR image does not fail.  (1.3.2 rc2 ?)

To reproduce, I download an initrd (uRamdisk) using tftp in uboot and then use 'iminfo' and it causes a machine check.  The strings from the image_get_xxx() functions appear to be bogus and printf crashes.  (image_get_os, image_get_arch...)  I am debugging it now, but I was hoping someone else had seen this already.

===== FROM UBOOT CONSOLE =====

=> tftp 200000 uRamdisk
... download completes ...
=> iminfo
## Checking Image at 00200000 ...
   Legacy image found
   Image Name:   Linux-2.6.25.5
   Created:      2008-08-20  22:17:07 UTC
   Image Type:   Machine Check Exception.
Caused by (from msr): regs 0ff0f310 Data machine check.
NIP: 00000000 XER: 0000005F LR: 0FFCA940 REGS: 0ff0f310 TRAP: 0200 DEAR: 00000000
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
 
GPR00: 00000000 0FF0F400 0FF0FF44 60C21FAD 00000000 0FF0F450 01048A68 FFFFFFFF
GPR08: 0FFA1BD8 60C21FAD 0FFD8838 00000002 00002FAF 00000000 0FFEAB00 0FFD83F4
GPR16: 0FFD8418 0FFD8424 0FF0F994 0FF0F894 0FF0F7DD 00000000 0FF0F750 0FFE1468
GPR24: 0FF0F418 0FF0F45C 00000000 60C21FAD FFFFFFFF 0FF0F5D7 0FFEC204 0FF0F450
Call backtrace:
0FF0F45C 0FFCAB9C 0FFBE4C8 9AE6C2BD
machine check

==========

Any information would help.
Thank you,
Jeff

Jeff Hemstreet
jeffhemstreet at yahoo.com


      

[U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex

[vb]

I am not sure how much this is related, but it is a known problem that
older tftp servers can't serve files larger than 16Mbytes in size.

hth,
/vb

On Fri, Aug 22, 2008 at 12:57 PM,  <jeffhemstreet@yahoo.com> wrote:
> I have been searching the web, but I have not seen any mention of this kind of problem.
>
> I am using a custom 405ex board based on Kilauea, with NAND boot.  (256MB NAND and 256MB DDR DRAM.)  The DRAM passes all tests, and the board boots into Linux fine.  When adding code to the initrd, we found that any image > 16MB seemed to cause this problem after being loaded.
> I also tested on Kilauea, and it happens but only with a uboot 1.3.3 image running from NAND, the default NOR image does not fail.  (1.3.2 rc2 ?)
>
> To reproduce, I download an initrd (uRamdisk) using tftp in uboot and then use 'iminfo' and it causes a machine check.  The strings from the image_get_xxx() functions appear to be bogus and printf crashes.  (image_get_os, image_get_arch...)  I am debugging it now, but I was hoping someone else had seen this already.
>
> ===== FROM UBOOT CONSOLE =====
>
> => tftp 200000 uRamdisk
> ... download completes ...
> => iminfo
> ## Checking Image at 00200000 ...
>   Legacy image found
>   Image Name:   Linux-2.6.25.5
>   Created:      2008-08-20  22:17:07 UTC
>   Image Type:   Machine Check Exception.
> Caused by (from msr): regs 0ff0f310 Data machine check.
> NIP: 00000000 XER: 0000005F LR: 0FFCA940 REGS: 0ff0f310 TRAP: 0200 DEAR: 00000000
> MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
>
> GPR00: 00000000 0FF0F400 0FF0FF44 60C21FAD 00000000 0FF0F450 01048A68 FFFFFFFF
> GPR08: 0FFA1BD8 60C21FAD 0FFD8838 00000002 00002FAF 00000000 0FFEAB00 0FFD83F4
> GPR16: 0FFD8418 0FFD8424 0FF0F994 0FF0F894 0FF0F7DD 00000000 0FF0F750 0FFE1468
> GPR24: 0FF0F418 0FF0F45C 00000000 60C21FAD FFFFFFFF 0FF0F5D7 0FFEC204 0FF0F450
> Call backtrace:
> 0FF0F45C 0FFCAB9C 0FFBE4C8 9AE6C2BD
> machine check
>
> ==========
>
> Any information would help.
> Thank you,
> Jeff
>
> Jeff Hemstreet
> jeffhemstreet at yahoo.com
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex

[jeffhemstreet at yahoo.com]

I am using a new tftp server from fedora 8.  (not sure of the exact version, but the system is up to date)

I found the issue... it is with the NAND image (NUB).  The NUB destination address is the TEXT_BASE address defined in the top level Makefile

The SPL loads the NUB, and then the NUB relocates itself to the top of
RAM (at 0xFF23000 in my case).  This relocation fixes the Global table,
but the tables for the iminfo command contain pointers to strings for
the OS, ARCH, type etc.  These string pointer all point back to the NUB
TEXT_BASE address, which was set to 0x1000000 (16MB).  When downloading
an image > 16MB to 0x200000, it overwrites the original image.  I
thought all the strings would be relative at this location, but the
string pointers are global addresses.  I relocated the NUB dest address to
higher in RAM for now to get around the issue.

The easiest way around this I believe is to hard code a location for the SPL to load the NUB to and then not relocate the NUB.

I thought I remembered something about some strings being accessed from the original location of the UBoot image.

 


----- Original Message ----
From: vb <vb@vsbe.com>
To: jeffhemstreet at yahoo.com
Cc: u-boot at lists.denx.de
Sent: Friday, August 22, 2008 4:41:49 PM
Subject: Re: [U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex

I am not sure how much this is related, but it is a known problem that
older tftp servers can't serve files larger than 16Mbytes in size.

hth,
/vb

On Fri, Aug 22, 2008 at 12:57 PM,  <jeffhemstreet@yahoo.com> wrote:
> I have been searching the web, but I have not seen any mention of this kind of problem.
>
> I am using a custom 405ex board based on Kilauea, with NAND boot.  (256MB NAND and 256MB DDR DRAM.)  The DRAM passes all tests, and the board boots into Linux fine.  When adding code to the initrd, we found that any image > 16MB seemed to cause this problem after being loaded.
> I also tested on Kilauea, and it happens but only with a uboot 1.3.3 image running from NAND, the default NOR image does not fail.  (1.3.2 rc2 ?)
>
> To reproduce, I download an initrd (uRamdisk) using tftp in uboot and then use 'iminfo' and it causes a machine check.  The strings from the image_get_xxx() functions appear to be bogus and printf crashes.  (image_get_os, image_get_arch...)  I am debugging it now, but I was hoping someone else had seen this already.
>
> ===== FROM UBOOT CONSOLE =====
>
> => tftp 200000 uRamdisk
> ... download completes ...
> => iminfo
> ## Checking Image at 00200000 ...
>   Legacy image found
>   Image Name:   Linux-2.6.25.5
>   Created:      2008-08-20  22:17:07 UTC
>   Image Type:   Machine Check Exception.
> Caused by (from msr): regs 0ff0f310 Data machine check.
> NIP: 00000000 XER: 0000005F LR: 0FFCA940 REGS: 0ff0f310 TRAP: 0200 DEAR: 00000000
> MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
>
> GPR00: 00000000 0FF0F400 0FF0FF44 60C21FAD 00000000 0FF0F450 01048A68 FFFFFFFF
> GPR08: 0FFA1BD8 60C21FAD 0FFD8838 00000002 00002FAF 00000000 0FFEAB00 0FFD83F4
> GPR16: 0FFD8418 0FFD8424 0FF0F994 0FF0F894 0FF0F7DD 00000000 0FF0F750 0FFE1468
> GPR24: 0FF0F418 0FF0F45C 00000000 60C21FAD FFFFFFFF 0FF0F5D7 0FFEC204 0FF0F450
> Call backtrace:
> 0FF0F45C 0FFCAB9C 0FFBE4C8 9AE6C2BD
> machine check
>
> ==========
>
> Any information would help.
> Thank you,
> Jeff
>
> Jeff Hemstreet
> jeffhemstreet at yahoo.com
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



      

[U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex

[Stefan Roese]

Hi Jeff,

On Monday 25 August 2008, jeffhemstreet at yahoo.com wrote:
> I found the issue... it is with the NAND image (NUB).  The NUB destination
> address is the TEXT_BASE address defined in the top level Makefile
>
> The SPL loads the NUB, and then the NUB relocates itself to the top of
> RAM (at 0xFF23000 in my case).  This relocation fixes the Global table,
> but the tables for the iminfo command contain pointers to strings for
> the OS, ARCH, type etc.  These string pointer all point back to the NUB
> TEXT_BASE address, which was set to 0x1000000 (16MB).

I just checked this issue on a NAND booting Canyonlands (460EX) board. I added 
some debug code to print the "uimage_os" pointer from common/image.c. On my 
target this pointer is relocated to the end of SDRAM too. So it's not 
pointing to the NUB TEXT_BASE.

Are you sure that those string pointer are incorrect in your case? Perhaps 
some other pointers or functions pointer are not relocated correctly.

> When downloading 
> an image > 16MB to 0x200000, it overwrites the original image.  I
> thought all the strings would be relative at this location, but the
> string pointers are global addresses.  I relocated the NUB dest address to
> higher in RAM for now to get around the issue.
>
> The easiest way around this I believe is to hard code a location for the
> SPL to load the NUB to and then not relocate the NUB.

We don't really want to go this way. Biggest problem would be that we would 
loose the ability to run with different memory size configurations. And if we 
really have some relocation problems (which is very likely), then they will 
hit us in the non NAND-booting case too. So all boards ports that relocate 
will have those problems and they should be solved at the root.

> I thought I remembered something about some strings being accessed from the
> original location of the UBoot image.

It would be great if you could test a little more and let us know where 
exactly the relocation problem lies. As mentioned above the string pointers 
from image.c should be fine.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================