Discussion of issues relevant to all ARM-based NetBSD ports

Kate F | 22 May 2012 14:42

Kirkwood hang on boot; possibly uninitialised bss

Hi all,

I'm using NetBSD-current on a D-Link DNS-325 NAS. It's a Marvell
Kirkwood 88F6281, which appears to be supported by the evbarm port
according to the kernel source.

My problem is a hang when booting.

I've made myself a kernel using the sys/arch/evbarm/conf/DNS323
configuration. The DNS-323 is actually a different SoC, but
I believe this is discovered by mvsoc_model(), and I can confirm
that kirkwood_intr_bootstrap() is called.

In other words, I think makeoptions BOARDTYPE="dns323" and
options EVBARM_BOARDTYPE=dns323 are not actually used, and
therefore that using the DNS323 on a 325 machine is okay.

Booting from U-boot:

  Marvell>> tftpboot 2000000 netbsd.gz.ub; bootm 2000000

  [snip]

  Bytes transferred = 2117011 (204d93 hex)
  ## Booting image at 02000000 ...
     Image Name:   NetBSD/dns323 6.99.7
     Created:      2012-05-21  22:17:58 UTC
     Image Type:   ARM NetBSD Kernel Image (gzip compressed)
     Data Size:    2116947 Bytes =  2 MB
     Load Address: 00008000

(Continue reading)

Robert Swindells | 22 May 2012 16:35

Picon

Re: Kirkwood hang on boot; possibly uninitialised bss


Kate F wrote:
>I'm using NetBSD-current on a D-Link DNS-325 NAS. It's a Marvell
>Kirkwood 88F6281, which appears to be supported by the evbarm port
>according to the kernel source.
>
>My problem is a hang when booting.
>
>I've made myself a kernel using the sys/arch/evbarm/conf/DNS323
>configuration. The DNS-323 is actually a different SoC, but
>I believe this is discovered by mvsoc_model(), and I can confirm
>that kirkwood_intr_bootstrap() is called.
>
>In other words, I think makeoptions BOARDTYPE="dns323" and
>options EVBARM_BOARDTYPE=dns323 are not actually used, and
>therefore that using the DNS323 on a 325 machine is okay.
>
>
>Booting from U-boot:
>
>  Marvell>> tftpboot 2000000 netbsd.gz.ub; bootm 2000000

[snip]

A current kernel boots fine on my Sheevaplug with the same SoC.

From what I can see on the web, the only real difference between the
DNS-325 and a Sheevaplug is that your D-Link device only has one
bank of DRAM fitted.

(Continue reading)

Kate F | 23 May 2012 06:24

Re: Kirkwood hang on boot; possibly uninitialised bss

On 22 May 2012 15:35, Robert Swindells <rjs <at> fdy2.co.uk> wrote:
>
> A current kernel boots fine on my Sheevaplug with the same SoC.
>
> From what I can see on the web, the only real difference between the
> DNS-325 and a Sheevaplug is that your D-Link device only has one
> bank of DRAM fitted.
>
> You could try modifying the code in initarm() that sets up the
> bootconfig structure to just set up one dram block.
>
> Robert Swindells

I'm a bit confused by this.

This page [1] says the RAM for the DNS-325 is provided as two chips:

  2xSEC K4T1G084QF-HCF7:128Mx8  <at> 400 CL6 (256MB total)

From dmesg of Linux on a SheevaPlug [3]
(which I presume is the same as yours):

  SDRAM_CS0 ....base 00000000, size 256MB
  SDRAM_CS1 ....base 10000000, size 256MB
  SDRAM_CS2 ....disable
  SDRAM_CS3 ....disable

And U-boot:

  DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6

(Continue reading)

Nick Hudson | 22 May 2012 17:39

Picon

Re: Kirkwood hang on boot; possibly uninitialised bss

On Tuesday 22 May 2012 13:42:49 Kate F wrote:
[...]
> So here I presume consinit_called isn't having its static storage
> initialised to 0, as I would expect. nm marvell_machdep.o says
> consinit_called does indeed live in the data segment:
> 
>   000004a4 T consinit
>   00000000 d consinit_called.9898
> 
> And gcc's marvell_machdep.s corresponds:
> 
>       .data
>       .align  2
>       .set    .LANCHOR0,. + 0
>       .type   consinit_called.9898, %object
>       .size   consinit_called.9898, 4
>   consinit_called.9898:
>       .space  4
> 
> So I believe the data segment is not being initialised correctly.

The data section should be read as is from the boot file into memory. 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.

> Unfortunately this is where I fall short; I have no idea where to look
> next, or what to do about it.
> 
> Any suggestions, please?

(Continue reading)

Kate F | 23 May 2012 17:41

Re: Kirkwood hang on boot; possibly uninitialised bss

On 22 May 2012 16:39, Nick Hudson <nick.hudson <at> gmx.co.uk> 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.

Hi Nick,

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

objdump -D marvell_macdep.o shows me:

  00000000 <consinit_called.9907>:
     0:   00000000        andeq   r0, r0, r0

readelf -x .data marvell_macdep.o shows the same:

  Hex dump of section '.data':
    0x00000000 00000000 00c20100 004b0000 00000000 .........K......
    0x00000010 00000000 0000ffff

Just to be clear, I'm reading these as consinit_called.9907 lives in offset 0
relative to .data (and I presume the .9907 is gcc's invented ID, because it
differs from a previous compilation).

So consinit_called in marvell_macdep.o has all bytes initially 0.
That obviously differs from the behaviour I'm seeing at runtime.

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

(Continue reading)

Robert Swindells | 23 May 2012 18:35

Picon

Re: Kirkwood hang on boot; possibly uninitialised bss


Kate K wrote:
>On 22 May 2012 16:39, Nick Hudson <nick.hudson <at> gmx.co.uk> 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...

(Continue reading)

Kate F | 24 May 2012 19:06

Re: Kirkwood hang on boot; possibly uninitialised bss

On 23 May 2012 17:35, Robert Swindells <rjs <at> fdy2.co.uk> wrote:
>
> 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.......
> ...
>
> 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 ?

(Continue reading)

Robert Swindells | 24 May 2012 22:06

Picon

Re: Kirkwood hang on boot; possibly uninitialised bss

Kate F wrote:
>On 23 May 2012 17:35, Robert Swindells <rjs <at> fdy2.co.uk> 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.

(Continue reading)

Return

Return to gmane.os.netbsd.ports.arm.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane