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