Re: Kirkwood hang on boot; possibly uninitialised bss

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

Kate F wrote:
>On 23 May 2012 17:35, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>> It is linking fine for me, how are you building the kernel ?
>
>I'm cross-compiling from a Linux amd64 machine:
>
>  ./build.sh -u -m evbarm kernel=XYZ

For speed, after build.sh has created the tools for you it will
create nbmake-evbarm, this is a wrapper around nbmake to set up 
the build environment, you should be able to run it in your
kernel build directory - src/sys/arch/evbarm/compile/XYZ in
your example.

[snip]

>So to recap:
>
> - the value in the kernel image is correct (all zeroes);

Yes.

> - the value in the kernel image after tftpboot copies it
>   (to 0x2000000 onwards) is correct;

I don't think you have verified this, to make the netbsd.gz.ub file
'netbsd' has been gzipped before prepending a U-boot header that
identifies it as a NetBSD kernel.

I don't think this part is likely to go wrong though.

> - the value after relocating to the load address 0x8000
>   is now somehow FCE1EBCB

The kernel doesn't get relocated as such, U-boot either copies or
uncompresses it down to the load address specified in the U-boot
header.

The boot process then relies on using PC-relative addressing for
everything until the code in marvell_start.S has set up a simple
pagetable.

In order for everything to work properly the final mapping defined in
mmu_init_table needs to be correct, it is:

        VA 0xc0000000..0xc7ffffff to PA 0x00000000..0x07ffffff

If the kernel gets copied to the wrong place by U-boot then stuff will
also be at incorrect addresses when the MMU is turned on.

The comment near the top of marvell_start.S is wrong, we started out
building the kernel to run at 0x00200000 then gradually moved it down
to 0x00008000.

I would try to find out where the kernel has actually been put by
U-boot.

Robert Swindells