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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot