Le 17/08/2010 12:21, Rogan Dawes a écrit : > 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.
Sorry, I'd missed that one. > Additionally, just doing a cp with the above parameters also hangs. > > 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. I do think you're overwriting u-boot with the kernel. What location does your u-boot load at? What location is the manufacturer's u-boot supposed to be loading at? See their TEXT_BASE in the board config file (or link file maybe). FYI, in my u-boot edminiv2 support code, I had issues with big kernels, so I decided to move u-boot's final location as high in RAM as by board allows, so that it never will be overwritten by Linux (unless I load a 63+ MB kernel, that is :) ) > Thanks anyway. > > Rogan You're welcome. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
