Subject: 2.5.x on Indy r4600

From: Jan-Benedict Glaw <[email-masked]>
Date: Fri, 16 May 2003 15:46:11 +0200

Hi!

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...).

Because 2.4.x basically runs on this machine, I suspect the linker
script changes. I've tried some older versions (added missing symbols
into them) to see if I can overcome these loading problems. Up to now, I
failed. Here's my kernel image's "objdump -h" output:

$ mips-linux-objdump -h indy-kernel

indy-kernel:     file format elf32-tradbigmips

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00176bfc  88002000  88002000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00022fd0  88178c00  88178c00  00177c00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .kstrtab      00005b2c  8819bbd0  8819bbd0  0019abd0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 __ex_table    00001ad8  881a1700  881a1700  001a0700  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 __dbe_table   00000000  881a31d8  881a31d8  001a21d8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 __ksymtab     000029a0  881a31d8  881a31d8  001a21d8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .data         0001d000  881a6000  881a6000  001a5000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
  7 .data.cacheline_aligned 00001c40  881c3000  881c3000  001c2000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data.init_task 00002000  881c6000  881c6000  001c4000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reginfo      00000018  881c8000  881c8000  001c6000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE
 10 .init.text    000126c4  881c8018  881c8018  001c6018  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .init.data    00002f1c  881da6dc  881da6dc  001d86dc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .init.setup   000000d0  881dd600  881dd600  001db600  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 13 .initcall.init 000000d8  881dd6d0  881dd6d0  001db6d0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 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

Does anybody have some suggestions for me?

MfG, JBG
-- 
   Jan-Benedict Glaw       [email-masked]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 16 May 2003 16:30:36 +0200 (MET DST)

> be completely dead: no serial break, no power button, no reset
[...]
> Idx Name          Size      VMA       LMA       File off  Algn
[...]
>  19 .mdebug.abi32 00000000  00000000  00000000  0020bff8  2**0

 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: [email-masked], PGP key available        +

---

From: Jan-Benedict Glaw <[email-masked]>
Date: Fri, 16 May 2003 16:54:52 +0200

On Fri, 2003-05-16 16:30:36 +0200, Maciej W. Rozycki <[email-masked]>
> On Fri, 16 May 2003, Jan-Benedict Glaw wrote:

[Non-booting 2.5.x on Indy]

> -- `objdump -p' would determine it definitely.  Better yet, please try

$ mips-linux-objdump -p indy-kernel

Program Header:
0x70000000 off    0x001c6000 vaddr 0x881c8000 paddr 0x881c8000 align 2**2
         filesz 0x00000018 memsz 0x00000018 flags r--
    LOAD off    0x00001000 vaddr 0x88002000 paddr 0x88002000 align 2**12
         filesz 0x001a3b78 memsz 0x001a3b78 flags r-x
    LOAD off    0x001a5000 vaddr 0x881a6000 paddr 0x881a6000 align 2**12
         filesz 0x0001ec40 memsz 0x0001ec40 flags rw-
    LOAD off    0x001c4000 vaddr 0x881c6000 paddr 0x881c6000 align 2**12
         filesz 0x00018080 memsz 0x00054640 flags rwx
private flags = 10001001: [abi=O32] [mips2] [not 32bitmode]

> `readelf -Sl', which reports additional data beyond what's obtainable with

$ mips-linux-readelf -Sl indy-kernel

There are 24 section headers, starting at offset 0x20c0dc:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        88002000 001000 176bfc 00  AX  0   0 32
  [ 2] .rodata           PROGBITS        88178c00 177c00 022fd0 00   A  0   0 16
  [ 3] .kstrtab          PROGBITS        8819bbd0 19abd0 005b2c 00   A  0   0  4
  [ 4] __ex_table        PROGBITS        881a1700 1a0700 001ad8 00   A  0   0  4
  [ 5] __dbe_table       PROGBITS        881a31d8 1a21d8 000000 00   A  0   0  1
  [ 6] __ksymtab         PROGBITS        881a31d8 1a21d8 0029a0 00   A  0   0  4
  [ 7] .data             PROGBITS        881a6000 1a5000 01d000 00  WA  0   0 4096
  [ 8] .data.cacheline_a PROGBITS        881c3000 1c2000 001c40 00  WA  0   0 32
  [ 9] .data.init_task   PROGBITS        881c6000 1c4000 002000 00  WA  0   0  4
  [10] .reginfo          MIPS_REGINFO    881c8000 1c6000 000018 18   A  0   0  4
  [11] .init.text        PROGBITS        881c8018 1c6018 0126c4 00  AX  0   0  4
  [12] .init.data        PROGBITS        881da6dc 1d86dc 002f1c 00  WA  0   0  4
  [13] .init.setup       PROGBITS        881dd600 1db600 0000d0 00  WA  0   0  4
  [14] .initcall.init    PROGBITS        881dd6d0 1db6d0 0000d8 00  WA  0   0  4
  [15] .init.ramfs       PROGBITS        881de000 1dc000 000080 00  WA  0   0  1
  [16] .sbss             NOBITS          881df000 1dd000 000010 00 WAp  0   0  8
  [17] .bss              NOBITS          881df020 1dd010 03b620 00  WA  0   0 32
  [18] .comment          PROGBITS        8821a640 1dd010 003e08 00      0   0  1
  [19] .pdr              PROGBITS        00000000 1e0e18 02b1e0 00      0   0  4
  [20] .mdebug.abi32     PROGBITS        00000000 20bff8 000000 00      0   0  1
  [21] .shstrtab         STRTAB          00000000 20bff8 0000e2 00      0   0  1
  [22] .symtab           SYMTAB          00000000 20c49c 02bb90 10     23 137f  4
  [23] .strtab           STRTAB          00000000 23802c 02e857 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x881c8058
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  REGINFO        0x1c6000 0x881c8000 0x881c8000 0x00018 0x00018 R   0x4
  LOAD           0x001000 0x88002000 0x88002000 0x1a3b78 0x1a3b78 R E 0x1000
  LOAD           0x1a5000 0x881a6000 0x881a6000 0x1ec40 0x1ec40 RW  0x1000
  LOAD           0x1c4000 0x881c6000 0x881c6000 0x18080 0x54640 RWE 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .reginfo 
   01     .text .rodata .kstrtab __ex_table __ksymtab 
   02     .data .data.cacheline_aligned 
   03     .data.init_task .reginfo .init.text .init.data .init.setup .initcall.init .init.ramfs .sbss .bss 

> `objdump'.  But why that unloadable data is requested at all? 

Thanks for looking at it! Maybe I'll get it up at some time:)

MfG, JBG

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 16 May 2003 17:47:58 +0200 (MET DST)

> private flags = 10001001: [abi=O32] [mips2] [not 32bitmode]

 Hmm, it looks reasonable and the end is indeed at 0x1dc07f (= 0x1c4000 +
0x18080 - 1).

>   LOAD           0x1c4000 0x881c6000 0x881c6000 0x18080 0x54640 RWE 0x1000

 And this looks fine, too.

 But there is a notable difference to 2.4 kernels, at least these I
inspected.  There are three loadable segments as opposed to two for 2.4
and the boot loader may be unhappy about it, e.g. it may have a bug that
gets hit.  You might want to reduce the number of segments (by changing
section flags -- look for ".section" gas directives).

---

From: Thiemo Seufer <[email-masked]>
Date: Fri, 16 May 2003 17:56:59 +0200

> section flags -- look for ".section" gas directives).

It's simpler to combine the relevant sections in the linker script than
to change the code.

Thiemo