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

[Rogan Dawes]

On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
> (quick note to Wolfgang: yes, there is RAM at 0x00008000 on these 
> machines. All orion5x based machines have RAM start at 0, and u-boot 
> makes sure SDRAM is set up this way)
> 
> Rogan,
> 
> You cannot tell from your log output that memmove never completes. It 
> could as well be the kernel not outputting to the console, or failing to 
> start at all even though the move was ok.

Actually, I can tell that the memmove never completes (or if it does, it
alters the code flow in the process):

>> So I changed memmove_wd to use the watchdog style of memmove'ing, in
>> small chunks to try to track down where the problem arises. I used 1kB
>> chunks, and got:
>>
>> Moving 1024 of 611612 bytes from ff8f6840 to 000de800
>> Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
>> Moving 1024 of 609564 bytes from ff8f7040 to 000df000
>>
>> before it finally hung.

I had a debug statement in the loop, printing out the above at each
iteration. Since it never completed the loop, copying/moving the entire
kernel (609564 bytes remaining), I think it is safe to assume that it
never got to the point of trying to boot the kernel.

Additionally, just doing a cp with the above parameters also hangs.

> The first thing you should do is make sure that you pass the right 
> machine-id, but also that you pass ATAGs correctly to the kernel -- it 
> seems that at least some LaCie custom u-boot  implementations use an env 
> variable ('mainlineKernel', IIRC) to differenciate between mainline and 
> LaCie custom kernels. Maybe your HW was designed the same way. Best is 
> you look up the u-boot source code provided by the manufacturer of your 
> machine.
> 
> The second thing is to make sure your kernel uses the right console. Are 
> you using netconsole? Maybe the manufacturer's kernel does not have 
> netconsole. Do you use a serial (RS-232) console? Make sure the kernel 
> has command line arguments to use it too.
> 
> Amicalement,

I'll check those once I have got the copy working correctly :-)

FWIW, I'm using a serial console, not netconsole. And the bootargs
include the console definition.

Based on what Wolfgang has said, perhaps the address space registers are
set up differently in the vendor u-boot to what the current mainline is
doing. I'll check that next, I think.

I'm just struggling to understand how the last command that I executed
ended up in the memory where I was trying to copy the kernel to. That
suggests that U-boot is actively using that memory for some reason, and
copying the kernel image over the top of it seems like a very good way
to cause u-boot to stop behaving consistently, and hang.

Thanks anyway.

Rogan