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

Rogan Dawes rogan at dawes.za.net
Mon Aug 16 23:08:42 CEST 2010


On 2010/08/16 10:29 PM, Wolfgang Denk wrote:
> 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.

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 CRC
>>> Ramdisk 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


More information about the U-Boot mailing list