Subject: 2.0.35 for Brutus

From: Nicolas Pitre <[email-masked]>
Date: Mon, 14 Sep 1998 17:52:14 -0400 (EDT)

Hi!

OK now I'm up to this:

Console: colour A-series 53x29x256, 1 virtual console (max 63)
Calibrating delay loop.. ok - 152.37 BogoMIPS
Memory: 11320k/16384k available (436k kernel code, 36k reserved, 496k
data)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Linux version 2.0.35 (nico@xanadu) (gcc version egcs-2.92.04 19980906
(gcc2 ss-8
Starting kswapd v 1.4.2.2
Keyboard driver v1.01
**** Turning off console printing ****
LSB: Done with kbd_init
SA1100 Serial driver version 4.13 with no serial options enabled
tty00 at 0xe0050000 (irq = 17) is a SA1100 UART
audio-sa1100: registered as device 42
Ramdisk driver initialized : 16 ramdisks of 16384K size
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
rc.sysinit: memory violation at pc=0x00000000, lr=0x6001f950 (bad
address=0x000)
rc.sysinit: memory violation at pc=0x03fffe1c, lr=0xbffffd88 (bad
address=0x03f)
init: memory violation at pc=0x03fffbc8, lr=0xbffffb64 (bad
address=0x03fffbc8,)

Does someone can tell me what's wrong?

P.S: the patch against latest 2.0.35 ARM Linux tree is available at
ftp.cam.org/users/nico/

P.P.S: hope this time I'll get AT LEAST one response... :)

Thanks

Nicolas Pitre, B. ing.
[email-masked]

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 15 Sep 1998 11:45:45 +0200

> Console: colour A-series 53x29x256, 1 virtual console (max 63)

I wonder if that's really right?

> Linux version 2.0.35 (nico@xanadu) (gcc version egcs-2.92.04 19980906

That smells like trouble..

> Does someone can tell me what's wrong?

Those memory violations from rc.sysinit look similar to the ones I got
last time I compiled an ARMLinux kernel with a non-gcc 2.7.2.x compiler.
Mine was gcc 2.7.95 or something (ie a prerelease of 2.8.0).  Can you
try recompiling with 2.7.2.x and see if that makes a difference?

-- 
Matthew Wilcox <[email-masked]>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 15 Sep 1998 09:59:36 -0400 (EDT)

> I wonder if that's really right?

Don't know.  The console screen seem to work i.e. display something OK.
But I don't care much about it for now...

> try recompiling with 2.7.2.x and see if that makes a difference?

I can compile and run beautifully the 2.0.30 tree from the Itsy team with
the same compiler...  So I assume that's not a compiler problem.

Nicolas Pitre, B. ing.
[email-masked]

---

From: Deborah Wallach <[email-masked]>
Date: Tue, 15 Sep 1998 09:19:56 -0700

> the same compiler...  So I assume that's not a compiler problem.

   Not necessarily a valid assumption.  I know Russell still uses gcc
   2.7.2.2, so that will be what he tests with.  The Itsy team may well be
   using a different compiler (egcs or gcc 2.8).

We're currently using the egcs-1.0.3 release.  Many many versions of gcc
2.8 and various binutils resulted in kernels that didn't work properly for
us, some in somewhat subtle ways.

			-Deborah Wallach

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 15 Sep 1998 19:06:59 +0200

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 15 Sep 1998 19:51:59 +0100 (BST)

> the same compiler...  So I assume that's not a compiler problem.

Linux 2.0 must, repeat must be compiled using GCC 2.7.2.2 - neither I, nor
any i386 Linux guru will provide any help for people trying to use a
different compiler.

Linux 2.0 is heavily optimised for GCC 2.7.2.2 only.  If you get it to work,
I wish to great success.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 15 Sep 1998 16:35:03 -0400 (EDT)

> using a different compiler (egcs or gcc 2.8).

OK I just tried the following combinations:

gcc-2.7.2.2 + binutils-2.7 (what is announced on ARM Linux web site)
egcs-1.03a + binutils-2.8.1.0.15 (Dave Gilbert's cross compiling
instructions, which is also what the Itsy team is using I think)
gcc-2.8.1 + binutils-2.9.1.0.6 (from netwinder.org FTP site)
egcs-19980906 with Phil Blundell's egcs patch + binutils-2.9.1.0.12

I also tried to mix some of the above.

Every compilations and executions of the 2.0.35 kernel gave the same
results!
So I must conclude that it's not a compiler problem since I can run a
2.0.30 kernel smoothly at least with the two egcs combinations.

Nicolas Pitre, B. ing.
[email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 15 Sep 1998 17:57:35 -0400 (EDT)

> any i386 Linux guru will provide any help for people trying to use a

Taken.  So I did.

> Linux 2.0 is heavily optimised for GCC 2.7.2.2 only.  If you get it to work,

Should I spend more effort making Linux for Brutus working on 2.1.121+ or
2.0.35 is still a good target?

Nicolas Pitre, B. ing.
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 15 Sep 1998 23:27:35 +0100

>any i386 Linux guru will provide any help for people trying to use a

To be fair, most of the problems with 2.0 on the i386 were due to bad asm() 
constraints in the Intel-specific headers, not any fundamental problem with 
the code.  Getting it working on the ARM with gcc 2.8 or later probably 
wouldn't be all that big a deal, though you'd have to have a fairly compelling 
reason to want to do it.

Incidentally, gcc 2.7.2.3 should be OK as well.  The changes from 2.7.2.2 were 
trivial.

p.