Re: Kirkwood hang on boot; possibly uninitialised bss

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

Kate K wrote:
>On 22 May 2012 16:39, Nick Hudson <nick.hudson%gmx.co.uk@localhost> wrote:
>> As it's
>> a .space and not .zero then it's probably getting filled by the linker with
>> whatever the linker thinks the fill is for the data output section. You could
>> check the kernel directly.

>I'm confused by this, too. I'm not sure exactly what I'm looking for.

[snip]

>How can I inspect netbsd.bin? I'd like to confirm that this object ends up
>there with all bytes 0, too.

You can inspect netbsd using nm and objdump.

% arm--netbsdelf-nm netbsd | sort > lst1

% grep consinit_called lst1
c038ab7c d consinit_called.9374

Sorting the output will also let you see which variables are near to
consinit_called in case it is being overwritten by something else.

% arm--netbsdelf-objdump -j .data -s netbsd > lst2

...
 c038ab40 a00901c0 b40901c0 c80901c0 dc0901c0  ................
 c038ab50 9ca127c0 00000000 00000000 6c000000  ..'.........l...
 c038ab60 02000000 28aa0ec0 54aa0ec0 28cd0ec0  ....(...T...(...
 c038ab70 18cd0ec0 00000000 00000000 00000000  ................
 c038ab80 00c20100 004b0000 00000000 00000000  .....K..........
 c038ab90 0000ffff 00000000 00000000 c4c10ec0  ................
 c038aba0 3d050000 04000000 ccbf28c0 74130000  =.........(.t...
 c038abb0 01000000 f0bf28c0 74130000 02000000  ......(.t.......
...


>Other than that, I have absolutely no idea what to investigate next.
>Is this a bug in linking? Surely not.

You should be able to use sprintf() at this stage in the boot, you can
use it to print values to a buffer then pass it to your KW_PUTS()
function.

It is linking fine for me, how are you building the kernel ?

Robert Swindells