linux-mips
[Top] [All Lists]

Re: 2.5.x on Indy r4600

To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Subject: Re: 2.5.x on Indy r4600
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Fri, 16 May 2003 16:30:36 +0200 (MET DST)
Cc: linux-mips@linux-mips.org
In-reply-to: <20030516134611.GH27494@lug-owl.de>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
On Fri, 16 May 2003, Jan-Benedict Glaw wrote:

> I'm currently tryin' to get 2.5.x running on MIPS (for background,
> please read http://www.lug-owl.de/~jbglaw/linux-ports/ ). I got current
> CVS HEAD to build (with minor tweaks), but my Indy doesn't completely
> load the kernel (via tftp). It starts loading the kernel, but TFTP
> packet #3810 (containing bytes 1950208..1950719 resp. 1dc200..1dc3ff
> from the kernel file) gets NACKed with error (5), code 3 (wrt. ethereal,
> this is "Disk full or allocation exceeded"). After this, the box seems to
> be completely dead: no serial break, no power button, no reset
> button...).
[...]
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
[...]
>  14 .init.ramfs   00000080  881de000  881de000  001dc000  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>  15 .sbss         00000010  881df000  881df000  001dd000  2**3
>                   ALLOC
>  16 .bss          0003b620  881df020  881df020  001dd010  2**5
>                   ALLOC
>  17 .comment      00003e08  8821a640  8821a640  001dd010  2**0
>                   CONTENTS, READONLY
>  18 .pdr          0002b1e0  00000000  00000000  001e0e18  2**2
>                   CONTENTS, READONLY
>  19 .mdebug.abi32 00000000  00000000  00000000  0020bff8  2**0
>                   CONTENTS, READONLY

 Hmm, the NACK is reasonable as probably nothing beyond 1dc07f is loadable
-- `objdump -p' would determine it definitely.  Better yet, please try
`readelf -Sl', which reports additional data beyond what's obtainable with
`objdump'.  But why that unloadable data is requested at all? 

 There is something strange about the .comment section -- it's not
allocatable, yet it has addresses set.  Anyway, it need not be relevant
here as section headers are not interpreted by your boot loader.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


<Prev in Thread] Current Thread [Next in Thread>