Subject: Re: 2.2.2-rmk2 crash on boot

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 1 Mar 1999 19:56:43 +0000 (GMT)

Nicholas Clark writes:
> In the last mail Timothy Baldwin said:
> > Upon trying to boot a compressed 2.2.2-rmk2 (on a Risc PC) I get :
> 2.2.2-rmk4 on a RiscPC gives
> > Uncompressing Linux...
> > invalid compressed format (err=2)
> err=1
> >  -- System halted
> > I used egcs-1.1b patched with egcs-1.1b-arm-diff-981004, and
> egcs-2.91.60
> > binutils-2.9.1.0.15 patched with binutils-2.9.1.0.15-diff-981027.
> 1999 binutils, mid Jan I think

I am just about to try binutils-2.9.1.0.19a to see how well that works.
There is a side effect to this - I'll be binary-compatible with the rest
of the world again (what was that about cows flying?).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 1 Mar 1999 23:15:12 +0000 (GMT)

> of the world again (what was that about cows flying?).

Ok, the results:

binutils-2.9.1.0.19a is acquitted of causing this malevolent behaviour.
Can someone check the behaviour of one of these faulty kernels on
!Linux compiled on the August 29 1998 please?  (when you hit 'Alt',
it should tell you the compilation date).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Timothy Baldwin <[email-masked]>
Date: Wed, 03 Mar 1999 09:56:45 +0000

In message <[email-masked]>

> > > 1999 binutils, mid Jan I think

[snip]

> binutils-2.9.1.0.19a is acquitted of causing this malevolent behaviour.

What did you compile binutils-2.9.1.0.19a with, and which library did
you link it against? And which kernel are you running it under?

linux/arch/arm/boot/compressed/piggy.o contains a valid gzip file, but
linux/arch/arm/boot/compressed/vmlinux and linux/arch/arm/boot/zImage do
not, therefore arm-linux-ld is a likely suspect. This is with
binutils-2.9.1.0.19a statically or dynamically linked against
libc 4.6.27, compiled with binutils-2.9.1.0.19a and egcs-2.91.57 19980901
(egcs-1.1 release). I am currently running kernel 2.0.36 patched with

_tmp_145piggy.lnk contains :

SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}

and the output of make zImg is :

make[1]: Entering directory `/usr/src/linux-2.2.2/testcase-5/arch/arm/boot'
make[2]: Entering directory `/usr/src/linux-2.2.2/testcase-5/arch/arm/boot/compressed'
tmppiggy=_tmp_$$piggy; \
	rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk; \
	arm-linux-objcopy -O binary -R .note -R .comment -S /usr/src/linux-2.2.2/testcase-5/vmlinux $tmppiggy; \
	gzip -f -9 < $tmppiggy > $tmppiggy.gz; \
	echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}" > $tmppiggy.lnk; \
	arm-linux-ld -m elf32arm -r -o piggy.o -b binary $tmppiggy.gz -b elf32-arm -T $tmppiggy.lnk;
arm-linux-ld -m elf32arm -Ttext 0x10008000 -o vmlinux head.o misc.o  ll_char_wr.o font.o piggy.o
make[2]: Leaving directory `/usr/src/linux-2.2.2/testcase-5/arch/arm/boot/compressed'
arm-linux-objcopy -O binary -R .note -R .comment -S compressed/vmlinux zImage
make[1]: Leaving directory `/usr/src/linux-2.2.2/testcase-5/arch/arm/boot'

(final rm removed for testing)

[snip rest]

-- 
http://www.reinhouse.freeserve.co.uk/
PGP key fingerprint = D6 FA 76 1D 68 F6 7B 96  F4 BC F2 62 D2 02 62 8E
Read the uk newsgroups? Then read uk.net.news.announce
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicholas Clark <[email-masked]>
Date: Wed, 3 Mar 1999 16:45:47 +0000 (GMT)

If linux/include/asm-arm/posix_types.h and glibc2.1 <bits/types.h> both want
to define __FD_SET in conflicting ways, which one is the implementation?
Who owns the toes? Who is doing the treading? :-)
And how do I fix it so that things compile (defining __USE_XOPEN is cheating)?

Nick

---

From: Philip Blundell <[email-masked]>
Date: Wed, 03 Mar 1999 17:07:56 +0000

>to define __FD_SET in conflicting ways, which one is the implementation?

Use the glibc one.  You shouldn't include kernel headers in user programs -- 
that means no <linux/*> or <asm/*> files.

p.

---

From: Nicholas Clark <[email-masked]>
Date: Wed, 3 Mar 1999 18:20:08 +0000 (GMT)

> (egcs-1.1 release). I am currently running kernel 2.0.36 patched with

I find that vmlinux and zImage contain a valid gzip file around offset
460000 (ish). I've even checked the zImage file I've copied over to
RISC OS and it's still a valid gzip file in there. Howver, bootloader
loads zImage, starts uncompression code which finishes with err=1 at
DEBG("dyn3 "). So somewhere between ADFS and memory my zImage would
appear to be becoming garbled. (dyn3 appears to be after a dynamicly
deflated block has been read and the huffman tree successfully
constructed, so self-decompression code would appear to be finding
some valid gzip data.)

I'm stumped as to how to proceed from here.

---

From: Nicholas Clark <[email-masked]>
Date: Wed, 3 Mar 1999 18:31:32 +0000 (GMT)

In the last mail Philip Blundell said:
> From [email-masked]  Wed Mar  3 17:21:40 1999
> X-Mailer: exmh version 2.0.2 2/24/98 (debian) 
> To: Nicholas Clark <[email-masked]>
> cc: [email-masked]
> Subject: Re: __FD_SET 
> In-reply-to: Your message of "Wed, 03 Mar 1999 16:45:47 GMT."
>              <[email-masked]> 
> Date: Wed, 03 Mar 1999 17:07:56 +0000
> From: Philip Blundell <[email-masked]>
> Message-Id: <[email-masked]>

> that means no <linux/*> or <asm/*> files.

So the library that I downlaoded that has

#ifdef linux
#include <linux/fs.h>
#include <linux/major.h>
#endif

is a fine example of poor quality programming? 

Nick

---

From: Philip Blundell <[email-masked]>
Date: Wed, 03 Mar 1999 19:33:39 +0000

>is a fine example of poor quality programming? 

That's a slightly harsh way to describe it, but very probably yes.  In some 
cases using <linux/*> headers was the only way to achieve a particular purpose 
but for the most part they were used in error.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 3 Mar 1999 21:12:33 +0000 (GMT)

> constructed, so self-decompression code would appear to be finding

Aha!  Could you upload the zImage to my ftp site incoming dir please?

/pub/armlinux/incoming

Thanks.

   _____

---

From: Timothy Baldwin <[email-masked]>
Date: Fri, 05 Mar 1999 15:08:09 +0000

In message <[email-masked]>

> (egcs-1.1 release). I am currently running kernel 2.0.36 patched with
patch-arm-2.0.36-19990109

I recompiled binutils-2.9.1.0.19a with gcc-2.7.2.2-1 and binutils-2.7-1a2
(those are names of RPMs),  Still no luck [1]. I tried with a hacked [2]
Debian installation, no luck again.

I have discovered that ommiting the -Ttext option from the arm-linux-ld
command line results in vmlinux containing a *valid* gzip file, however
there is still no valid gzip file in zImage.

[1] Even under RMK's 2.0.36 compiled at 20 Thu Jan 21 21:23:26.

[2] I installed a few debs by manually extracting the 2nd gzip'd tar file
from the deb file, as dpkg won't work under kernel 2.0.36.

---

From: Russell King <[email-masked]>
Date: Fri, 5 Mar 1999 18:40:47 +0000 (GMT)

> there is still no valid gzip file in zImage.

Erm, what?  Which vmlinux?  If you're talking about linux/vmlinux, it
never contains a gzip file.

--
Russell King ([email-masked])

---

From: Timothy Baldwin <[email-masked]>
Date: Sat, 06 Mar 1999 09:36:28 +0000

In message <[email-masked]>

> never contains a gzip file.

linux/arch/arm/boot/compressed/vmlinux

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 6 Mar 1999 13:21:37 +0000 (GMT)

> linux/arch/arm/boot/compressed/vmlinux

Ok, if you do an arm-linux-nm on this, find the address of the following symbols,
eg:

10008000 T _start
10013420 D input_data

Find the offset between input_data and _start, ie 0x10013420 - 0x10008000 = 0xb420

Then, use dd to extract the gzipped data from the zImage, eg:

 dd if=zImage of=zImg.gz bs=1 skip=46112

Using gunzip, gunzip the resulting zImg.gz file.  If the gunzip is successful,
the zImage file contains a valid gzip, else it doesn't.

Try this both with -Ttext and without, however I believe that you will find
in all cases a valid gzip file in there.

I don't believe that there is anything wrong with the binutils, since I'm
now using the same as other people with this problem, and I have none of
these.  I believe that the only tool left to consider is egcs (unless you
can prove otherwise).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Timothy Baldwin <[email-masked]>
Date: Sun, 07 Mar 1999 20:05:28 +0000

In message <[email-masked]>

[snip]

> Ok, if you do an arm-linux-nm on this, find the address of the
> following symbols, eg:
> 
> 10008000 T _start
> 10013420 D input_data
> 
> Using gunzip, gunzip the resulting zImg.gz file.  If the gunzip is
> successful, the zImage file contains a valid gzip, else it doesn't.
> 
> Try this both with -Ttext and without, however I believe that you
> will find in all cases a valid gzip file in there.

You believe correctly. Further investigation shows that IscaFS was
incorrectly reading files written by binutils (but not cp). It seems
my confidence in IscaFS was misplaced, I will be submitting a bug
report.

I recitified this by copying the kernel to RISC OS via a MS-DOS formmated
floppy, however I now get a crc error when trying to boot a compressed
kernel.

BTW, the machine in question is 20M DRAM + 1M VRAM Risc PC with RISC OS 3.7
and an ARM610 processor.

[snip]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 7 Mar 1999 20:42:45 +0000 (GMT)

> BTW, the machine in question is 20M DRAM + 1M VRAM Risc PC with RISC OS 3.7

I do hope that you didn't compile the kernel for a StrongARM on a RiscPC.
This is a great nono with egcs (since it will generate half-word instructions
which the RiscPC can't cope with).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicholas Clark <[email-masked]>
Date: Sun, 7 Mar 1999 22:27:25 +0000 (GMT)

> my confidence in IscaFS was misplaced, I will be submitting a bug

Aaargh. I've got (at least) 4 problems, 2 of which are now solved

1: IscaFS didn't understand holey files (binutils makes a zImage with holes
   (parts of file with no disc storage allocated - read as all zeros))
   Phil has fixed this (we think, but)
2: IscaFS still doesn't read the same data for zImage and the result of
   cat zImage; (to remove the holes) - got a problem starting at block 400 ish
   (206th double indirect block, IIRC)

3: egcs was generating LDRH instructions, because it was told I have a
   StrongARM (True, but counterproductive on a RiscPC_)
4: something else is making buggy code, hence my kernel won't boot

> floppy, however I now get a crc error when trying to boot a compressed

RISC OS seems to be pretty poor when it comes to reading MS-DOG disks.

cat zImage >someotherfile
should do the trick.
Or gzip or zip the zImage, and "uncompress" it on this side of IscaFS, so that
you get the CRC check to verify that it came across intact.

> BTW, the machine in question is 20M DRAM + 1M VRAM Risc PC with RISC OS 3.7

"Very interesting" (why a 610?)

Nick

---

From: Timothy Baldwin <[email-masked]>
Date: Sat, 13 Mar 1999 15:00:20 +0000

In message <[email-masked]>
          Russell King - ARM Linux Admin <[email-masked]> wrote:

> This is a great nono with egcs (since it will generate half-word
> instructions which the RiscPC can't cope with).

Don't think so, and certainly not the decompression code.

I have found the "RC5PC" module is causing the problem, if I remove
it the kernel boots succesfully, but with problems with the display. I shall
recompile the kernel with clean source code.

Russell (or anybody else), can you confirm !Linux calls Service_PreReset?

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 13 Mar 1999 16:21:57 +0000 (GMT)

> Russell (or anybody else), can you confirm !Linux calls Service_PreReset?

It does indeed.  This is one of the calls to ensure that the Expansion cards
are put into their reset state.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]