Subject: Re: Arm Linux

From: Charles Esson <[email-masked]>
Date: Mon, 20 Jan 1997 09:29:31 +1100

I brought a RISC PC 700, my interest is the strong-arm so if the ARM710
CPU that was pulled out to put in the strong-arm is yours if it is of
any use to you.

I brought the RISC PC 700 in the hope that there would be a port to it,
and I could use this as the base for my efforts.

My real interest is to get it running on our hardware.

I've spent 20 years supporting and writing real time operating systems,
assemblers and applications for the 68k and in the dim past the PDP11.
My interest is the software hardware interface. My linux experience is
close to nil, but time will fix that.

I slept on it last night and concluded this has just got to happen. The
strong-arm is a great chip, 0.5 watts, 220 mips. This is just unheard of
performance and opens up so many possibilities, further the Arm
instruction set is something to be admired. Linux is great opportunity
for the computer industry. A good, well supported operating system with
source available would be a great boost to the real time industry.  

So if I look at the list, and ask what I am able and interested in
doing.
Kernel
-ARM 6 No
-Missing drivers for the QR-21A81-02, I will write as our hardware
design will be based on this card.
-Merge with Linus source tree, obviously no.

General
-X I will need this but it would not be something I would do with joy.
-Debian. I've had a long hard think about this, and it would seem like a
dam good idea as it would help the arm along in the general market. But
looking under he tools there are more immediate problems.

Tools
-gcc If the problem is translation of the intermediate code to
assembler, perhaps. If the problem is the compiler itself, no it would
require specialized knowledge that I don't have and are unwilling to
learn. This however is something we could live with in the short term
-binutils. Maybe.
-ELF. To my mind if the kernel is up and running  then this is the next
cab of the rank, and I will put up my hand. I have this horrible feeling
however that this will involve mods to the gcc backend.
-glibc, or libc.so.6. If someone else wants to do the ELF stuff, I will
put up my hand for this one, but as I understand it, one of the
advantages of ELF is the simplification of library support, making ELF
the first problem.  
 
Well that’s about where I sit, the biggest problem I see is that someone
has to organize who does what so there isn’t a duplication of effort,
and we have to move to a team approach so the job gets done.

Another 2 pence worth.

-- 
Charles Esson Colour Vision Systems
11 Park Street, Bacchus March,
Victoria, Australia 3340.
Phone: 61 53 673155, Fax: 61 53 674480

---

From: Philip Blundell <[email-masked]>
Date: Sun, 19 Jan 1997 23:15:25 +0000 (GMT)

> performance and opens up so many possibilities, further the Arm

That's true.

> -Merge with Linus source tree, obviously no.

No, that will have to be Russell really. 

> learn. This however is something we could live with in the short term

Yes.  I'm not too keen on digging around in the compiler myself really -
compilers aren't exactly my area of interest.  As you say, it can wait;
it's good enough for now. 

> however that this will involve mods to the gcc backend.

Yes.  This will probably need changes to gcc and binutils.  However, it's
not just a Linux problem and we might be able to liase with the NetBSD
people.  Ditto with X, actually. 

> advantages of ELF is the simplification of library support, making ELF

Yes.  glibc is something I'd envisaged doing myself, but I'm always keen
for other people to help.  ELF isn't a prerequisite to _start_ the work,
but it will be required sooner rather than later. 

> and we have to move to a team approach so the job gets done.

Quite.  I'm quite prepared to keep track of who's doing what.  There seem
to be precious few people who _are_ prepared to do any programming, so I
don't imagine it will be too arduous. 

phil