On 2010/08/16 10:29 PM, Wolfgang Denk wrote:
Dear Rogan Dawes,
In message4C699C6E.2010706@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.
Hi Wolfgang,
This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.
Verifying Checksum ... Bad Data CRCRamdisk image is corrupt or invalid
Is there RAM at 0x00800000 ?
Again, this is from the default vendor ramdisk that ships with the device.
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.
I looked at the CPU datasheet, which shows that:
DDR SDRAM CS0 is by default 256 MB at 0000.0000–0FFF.FFFF
There doesn't appear to be any code in the orion5x setup that sets this to anything else:
$ git grep ORION5X_ATTR_DRAM_CS0 arch/arm/include/asm/arch-orion5x/cpu.h: ORION5X_ATTR_DRAM_CS0 = 0x0e, $
The device has 64MB RAM in two banks.
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...
Patch to follow this mail.
Thanks for your help!
Rogan