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

Rogan Dawes
2010-08-17T10:21:32Z

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