On 2010/08/17 12:41 PM, Albert ARIBAUD wrote:
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.
No problem, there was a lot of data there.
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).
My U-Boot is configured to load at 0x3000000 (48MB), as far out of the way as possible. That is, using the mkimage tool, which is how I get my rebuilt u-boot onto the machine. This is my command line:
$ make clean mrproper dns323_b1_config && make && \ mkimage -A arm -O u-boot -T kernel -C none \ -a 0x3000000 -e 0x3000000 -n "UBoot dns323" \ -d u-boot.bin uImage.bin
My TEXT_BASE is identical to yours: 0x100000
Does that make a difference, if the u-boot image is chain loaded from another one?
This is what I found in the vendor code:
./board/mv88fxx81/db88f5181/config_tiny.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_prpmc.mk:TEXT_BASE = 0x02f10000 ./board/mv88fxx81/db88f5181/config_def.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_tiny_voip.mk:TEXT_BASE = 0x00f40000 ./board/mv88fxx81/db88f1181/config.mk:TEXT_BASE = 0x00f00000
I'm not sure which config has been used for the version of u-boot on my board, though.
At any rate, those are all substantially higher than I am currently using.
I'll try with a higher value, and see what happens.
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 :) )
That was my reasoning with the 48MB, too :-)
Rogan