Subject: Decstation /150 kernel (cvs) problems

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 02:56:22 +0100

Hi,
it seems the current cvs kernel does not work on my /150 - Does anyone
have similar expiriences ? It simply reboots for me ...

>>boot 3/rz0 2/linux.test
delo V0.7 Copyright 2000 Florian Lohoff <[email-masked]>
Loading /etc/delo.conf .. ok
Loading /boot/vmlinux-2.4.14 ................ ok

KN04 V2.1k    (PC: 0x80148b9c, SP: 0x8043fef0)
delo V0.7 Copyright 2000 Florian Lohoff <[email-masked]>
Loading /etc/delo.conf .. ok
Loading /boot/vmlinux .................... ok
This DECstation is a DS5000/1xx
Loading R4000 MMU routines.
CPU revision is: 00000430
Primary instruction cache 8kb, linesize 16 bytes.                              
[...]

repeat:~# cat /proc/cpuinfo
cpu                     : MIPS
cpu model               : R4000SC V3.0
system type             : Digital DECstation 5000/1xx
BogoMIPS                : 49.68
byteorder               : little endian
unaligned accesses      : 0
wait instruction        : no
microsecond timers      : no
extra interrupt vector  : no
hardware watchpoint     : yes
VCED exceptions         : 6565
VCEI exceptions         : 11303

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

---

From: "Houten K.H.C. van (Karel)" <[email-masked]>
Date: Tue, 27 Nov 2001 08:53:40 +0100

Hi Florian,

> ...

I've noticed that recent kernels can't be booted by delo.
As far as I have dug into that, it might be the changed loadaddr,
that is hardcoded in delo...
TFTP booting the same kernel does indeed start the kernel
(for me it usually crashes or hangs some moments later).

Regards,
-- 
Karel van Houten

----------------------------------------------------------
The box said "Requires Windows 95 or better."
I can't understand why it won't work on my Linux computer. 
----------------------------------------------------------

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 11:48:49 +0100

> that is hardcoded in delo...

Delo should load the kernel to a specific address and then move
the single ELF segments to their address in the ELF header (copyelf.c).

> (for me it usually crashes or hangs some moments later).

*Urgs* I'am just having a look at it... It looks the elf segments have
changed moved and its either overwriting itself or the prom.

delo V0.7 Copyright 2000 Florian Lohoff <[email-masked]>
Loading /etc/delo.conf .. ok                                  
Loading /boot/vmlinux-2.4.14 ................ ok              
fhdr->e_entry = fhdr->e_shoff = 1549940/17a674                
fhdr->e_phoff = 52/34                                         
fhdr->e_shentsize = 40
fhdr->e_shnum = 20
fhdr->e_shstrndx = fhdr->e_phentsize = fhdr->e_phnum =  0 0017a674
00000000 00000000 00000000 00000000 00000000
 1 0017a69c 00000001 80040000 00001000 00131ed0 00000000
memcpy( 2 0017a6c4 00000001 80171ed0 00132ed0 00000e6c 00000000
memcpy( 3 0017a6ec 00000001 80172d3c 00133d3c 000035b4 00000000
memcpy( 4 0017a714 00000001 801762f0 001372f0 00001b98 00000000
memcpy( 5 0017a73c 00000001 80177e88 00138e88 00000000 00000000
 6 0017a764 00000001 80177e88 00138e88 00001a38 00000000
memcpy( 7 0017a78c 00000001 8017a000 0013b000 0000c30c 00000000
memcpy( 8 0017a7b4 00000001 8018630c 0014730c 0000040c 00000000
memcpy( 9 0017a7dc 00000001 80186720 00147720 000000a0 00000000
memcpy(10 0017a804 00000001 801867c0 001477c0 00000070 00000000
memcpy(11 0017a82c 00000001 80187000 00148000 00000260 00000000
memcpy(12 0017a854 70000006 80187260 00148260 00000018 00000000
13 0017a87c 00000001 80187280 00148280 00011d80 00000000
memcpy(14 0017a8a4 00000008 80199000 0015a000 000256e0 00000000
memset(15 0017a8cc 00000001 801be6e0 0015a000 00003a33 00000000
memcpy(16 0017a8f4 00000001 00000000 0015da34 0001cb80 00000000
memcpy(

When having a look at the kernel file it looks broken - Have a look
at segment 16 which is type PROGBITS but address "0" 

(flo@paradigm)/tmp/i/linux# readelf -e vmlinux 
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x8004046c
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1549940 (bytes into file)
  Flags:                             0x10000001, noreorder, mips2
UNKNOWN
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         20
  Section header string table index: 17

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        80040000 001000 131ed0 00  AX 0   0 8192
  [ 2] .fixup            PROGBITS        80171ed0 132ed0 000e6c 00  AX 0   0  1
  [ 3] .kstrtab          PROGBITS        80172d3c 133d3c 0035b4 00   A 0   0  4
  [ 4] __ex_table        PROGBITS        801762f0 1372f0 001b98 00   A 0   0  4
  [ 5] __dbe_table       PROGBITS        80177e88 138e88 000000 00   A 0   0  1
  [ 6] __ksymtab         PROGBITS        80177e88 138e88 001a38 00   A 0   0  4
  [ 7] .text.init        PROGBITS        8017a000 13b000 00c30c 00  AX 0   0  4
  [ 8] .data.init        PROGBITS        8018630c 14730c 00040c 00  WA 0   0  4
  [ 9] .setup.init       PROGBITS        80186720 147720 0000a0 00  WA 0   0  4
  [10] .initcall.init    PROGBITS        801867c0 1477c0 000070 00  WA 0   0  4
  [11] .data.cacheline_a PROGBITS        80187000 148000 000260 00  WA 0   0 32
  [12] .reginfo          MIPS_REGINFO    80187260 148260 000018 18   A 0   0  4
  [13] .data             PROGBITS        80187280 148280 011d80 00  WA 0   0 32
  [14] .bss              NOBITS          80199000 15a000 0256e0 00  WA 0   0 32
  [15] .comment          PROGBITS        801be6e0 15a000 003a33 00 0   0  1
  [16] .pdr              PROGBITS        00000000 15da34 01cb80 00 0   0  4
  [17] .shstrtab         STRTAB          00000000 17a5b4 0000bd 00 0   0  1
  [18] .symtab           SYMTAB          00000000 17a994 01dfe0 10 19 cf2  4
  [19] .strtab           STRTAB          00000000 198974 01e130 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)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
Align
  REGINFO        0x148260 0x80187260 0x80187260 0x00018 0x00018 R   0x4
  LOAD           0x001000 0x80040000 0x80040000 0x159000 0x17e6e0 RWE
0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .reginfo 
   01     .text .fixup .kstrtab __ex_table __ksymtab .text.init
.data.init .setup.init .initcall.init .data.cacheline_aligned .reginfo
.data .bss 

(flo@paradigm)/tmp/i/linux# mipsel-linux-gcc --version
3.0.2
(flo@paradigm)/tmp/i/linux# mipsel-linux-as --version
GNU assembler 2.11.92.0.10 Debian/GNU Linux
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `mipsel-linux'.

Flo

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 11:59:03 +0100

> changed moved and its either overwriting itself or the prom.

Ok - this fixes the problem by not only ignoring "length 0" sections but
also sections with address 0 

--- delo-0.7/loader/copyelf.c	Sat Oct 14 19:29:00 2000
+++ delo-0.7-flo/loader/copyelf.c	Tue Nov 27 11:51:29 2001
@@ -42,7 +42,7 @@
 			shdr->sh_offset, shdr->sh_size);
 #endif
 
-		if (shdr->sh_size <= 0) 
+		if (shdr->sh_size <= 0 || shdr->sh_addr == 0) 
 			continue;
 
 		if (shdr->sh_type == SHT_PROGBITS) {

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 27 Nov 2001 13:07:09 +0100 (MET)

> also sections with address 0 

 Huh?  You should be dealing with segments and not sections (as you are
loading and not linking the image) and then only LOADable ones.  I believe
there is no segment mapped at zero for the current kernel.  If a segment
has a null load address then it still have to be loaded -- you may
consider placing part of it away for the time being or just relocating the
loader.

$ mipsel-linux-objdump -p vmlinux-mips-2.4.14-20011123

vmlinux-mips-2.4.14-20011123:     file format elf32-tradlittlemips

Program Header:
0x70000000 off    0x0028e2e0 vaddr 0x802ce2e0 paddr 0x802ce2e0 align 2**2
         filesz 0x00000018 memsz 0x00000018 flags r--
    LOAD off    0x00001000 vaddr 0x80040000 paddr 0x80040000 align 2**12
         filesz 0x002744a8 memsz 0x002744a8 flags r-x
    LOAD off    0x00276000 vaddr 0x802b6000 paddr 0x802b6000 align 2**12
         filesz 0x0004c000 memsz 0x0006a890 flags rwx
private flags = 10000001: [no abi set] [mips2] [not 32bitmode]

There are only two LOADable segments, at 0x80040000 and at 0x802b6000.
None is at zero. ;-)

 If in doubt, just see how I'm loading ELF images in mopd.  Or ask me a
question. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 13:54:49 +0100

> loading and not linking the image) and then only LOADable ones.  I believe

I waded through the sections list copieng all sections which are of
type PROGBITS which is basically the same. Also i cleared all NOBITS
sections. The problem was a progbits section with length > 0 and addr
= 0 which is IMHO bogus.

>  If in doubt, just see how I'm loading ELF images in mopd.  Or ask me a

I'll look into that one...

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 27 Nov 2001 16:08:47 +0100 (MET)

> type PROGBITS which is basically the same. Also i cleared all NOBITS

 It's not the same, sorry -- for sections you would need to handle ones
marked ALLOC in flags.  Of these you need to load ones of type PROGBITS
and zero-fill ones of type NOBITS.  Others may be discarded.  For Linux
you may actually skip NOBITS as well, as the head code zero-fills common
sections itself, but handling them is saner IMO. 

 Still using segments is the proper way and it's simpler as well. 
Additionally for platforms that use physical (or in any way different)
addressing upon boot, you may (and should) use segments' physical
addresses that are not available (assigned) to sections.

> sections. The problem was a progbits section with length > 0 and addr

 Not bogus -- the only section which matches your criteria I'm seeing is
".pdr": 

$ mipsel-linux-readelf -S vmlinux-mips-2.4.14-20011123
There are 21 section headers, starting at offset 0x2f8e54:

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        80040000 001000 2699c0 00 AX   0   0 8192
[...]
  [17] .pdr              PROGBITS        00000000 2c4954 034440 00      0   0  4
[...]
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)

But it's not marked as allocatable, so it does not belong to the run-time
image.  See also the "System V Application Binary Interface, Edition 4.1",
chapter 4 for sections and 5 for segments. 

  Maciej

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 16:36:02 +0100

> sections itself, but handling them is saner IMO. 

This is mostly what i do - As the ext2 code loads in the whole file
as a chunk i am loading it after the booloader - Then copy it to the
end of the first 8Megs (Which is the minimum memory on a decstation)
and then copy the chunks marked PROGBITS to their final location.

Not optimal but it worked for all the cases where the ELF is ok.

>  Not bogus -- the only section which matches your criteria I'm seeing is

Yep - And that the one where the current copyelf function crashes the
box.

> chapter 4 for sections and 5 for segments. 

;) I am no elf god by far - I was just in the need of a bootloader so
i looked in the elf headers and collected the bits i thought were
usefull.

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 27 Nov 2001 18:23:11 +0100 (MET)

> and then copy the chunks marked PROGBITS to their final location.

 That's ugly -- isn't there a possibility to read a file on a
block-by-block basis?

> i looked in the elf headers and collected the bits i thought were

 Neither am I, but come on -- the ELF format is next to trivial to handle
and the spec is just a few pages -- the relevant part of chapter 5 fits in
three pages.

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 28 Nov 2001 14:19:34 +0100

>  That's ugly -- isn't there a possibility to read a file on a

I am using the libext2 which basically might do that - i am unshure.
I am currently using 

retval=ext2fs_block_iterate(fs, inode, 0, 0, delo_dump_block, 0);

Which basically loads in all the blocks by calling "delo_dump_block"
for each block with the block on the device to load and the block number
this is in the file.

Flo