[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C699C6E.2010706 at dawes.za.net> you wrote:
>
> > DNS323B1>  bootm FF820000
> > ## Booting kernel from Legacy Image at ff820000 ...
> >      Image Name:   Linux-2.6.12.6-arm1
> >      Image Type:   ARM Linux Kernel Image (uncompressed)
> >      Data Size:    1490204 Bytes = 1.4 MiB
> >      Load Address: 00008000
> >      Entry Point:  00008000
> >      Verifying Checksum ... OK
> >      Loading Kernel Image ...
> >
> > and it hangs there.

Are you absolutely sure that you have RAM in your system at 0x8000?
I doubt that your Load Address/Entry Point settings are correct.

> > Moving memory from ff820040 to 00008000
> >
> > Is that because the uImage header is 64 bytes?

The offset 0x40 is becaus eof the header, the 0x00008000 is because
your Load Address setting.

> > ## Loading init Ramdisk from Legacy Image at ff9a0000 ...
> >      Image Name:   Ramdisk
> >      Image Type:   ARM Linux RAMDisk Image (gzip compressed)
> >      Data Size:    5240600 Bytes = 5 MiB
> >      Load Address: 00800000
> >      Entry Point:  00800000
> >      Verifying Checksum ... Bad Data CRC
> > Ramdisk image is corrupt or invalid

Is there RAM at 0x00800000 ?

> So, I checked what was at that address:

Hm... instead of trying random things I recommend to apply common
sense. Have a look at the memory map for your system - which memory
types and register banks etc. are mapped to which address ragens?
Where is your RAM and how big is it?  I seriously doubt that you have
RAM at these low addresses.

> The first 1kB was not particularly interesting (to me). But the next 
> chunk showed something interesting at 000df6e0:
> 
> 000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 
> ....md.b.000df00
> 000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 
> 0.400...........
> 
> i.e. the command I had just executed.
> 
> So, it seems that for some reason, even though I tried to place my chain 
> loaded u-boot out of harms way at 0x3000000, for some reason, it was 
> still allocating memory at a lower address, precisely where the kernel 
> is supposed to be copied to for execution.
> 
> Can anyone explain why this happens? Or what I can do to fix it?

We don;t yuour hardware, we don't know your board configuration, we
don't know your code...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Was heißt Windows auf Indianisch? - "Weißer  Mann,  der  auf  Sanduhr
wartet!"