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

[Rogan Dawes <rogan@dawes.za.net>]

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