Subject: Re: Arm Linux

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

On Sun, 19 Jan 1997, Charles Esson wrote:

> development board ( Digital are now selling the QR-21A81-02 for
> AUD$3205), and what, I find out the port delay it is not a slow modem
> but a lack of resources, not complaining mind you.

There are actually various things delaying the port, and some of them are
rather inter-related.  I've Cc'd this back to the mailing list.

Firstly, there's lack of time.  Russell, as he said in his last note (and,
to do him justice, he hasn't made any secret of this before) is very busy. 

Secondly, there's lack of developers.  This is partly because very few
people seem to have actually stepped forwards and said `I will do
such-and-such work'.  Partly it's because Russell doesn't manage to
release sources very often, and so even those are willing have a hard time
doing anything useful. 

Thirdly, there's lack of general resources.  The only ARM-based hardware I
have at my disposal right now is an old A5000, and that's not a good
machine to develop on.  I hope to get hold of an ARM700 card and a
StrongARM of some sort in due course, but it may take some time.  Luckily
I _do_ have an Alpha and a Pentium that I can cross-compile on in the
interim.  Russell doesn't have a fast Internet link.

For what it's worth, this (in no particular order) is my mental list of
things that I think would be current worthwhile projects for somebody to
take on.  Obviously that's not to say that nothing else is worthwhile, but
these are the ones that I believe would make things significantly better.

1. Kernel stuff

	- ARM6 support.  This ought not to be very difficult, given that
	  we have ARM3 and StrongARM already (and a good fraction of the
	  ARM6 stuff is in there anyway).  There are plenty of people with 
	  either RiscPCs or other ARM6-based hardware who would like to
	  run Linux.

	- More and better device drivers.  This is an ongoing one,
	  obviously.  I think Dave Gilbert is handling the old
	  `Archimedes' hardware at the moment.

	- Merge with Linus' source tree.  I think work is ongoing by
	  Russell on this, and the major obstacle at the moment is
	  probably Linus' lack of spare time.

2. General user-space stuff

	- X.  The Xserver for Archimedes hardware isn't really rocket
	  science, since VIDC just gives you a flat framebuffer.  At the
	  moment I think we only have quite an old version, and it would
	  be nice to have the latest XFree86 ported (they really ought to
	  think about changing the name eventually...).

	- Debian.  Bruce Perens has shown some interest in having a Debian
	  port for the ARM, and it seems like a good idea. 

3. Tools and stuff.

	- gcc.  At the moment GCC doesn't generate such good code for the
	  ARM as Norcroft does, and this is a bit of a shame.

	- binutils.  Last time I looked, binutils for the ARM was buggy.   

	- ELF.  Linux is moving to ELF, and we don't want to be left
	  behind.  ELF is important for shared libraries, especially...

	- glibc, or libc.so.6, is the new Linux shared library.  It needs
	  to be ported to the ARM.

4. Weird stuff.

	- Some sort of emulator to allow RISC OS binaries to run might be
	  a fun thing to have.

So, there's much to do.  Do any of those things call out to anybody
reading this and say `Implement me!'?  If so, let me know.

phil

---

From: Joseph Heenan <[email-masked]>
Date: Sun, 19 Jan 1997 14:56:53 +0000

In message <[email-masked]>
          Philip Blundell <[email-masked]> wrote:
  [some brutally trimmed text:]
> release sources very often, and so even those are willing have a hard time

I'd like to do something - but I can't even run linux at the moment
(ARM 700). I have a pentium sitting next to me than I could use to
cross compile things, but that's kind of hindered by not having any
source.

I have not idea what's involved in getting it to work on a 700 -
I can't see it been too much, like you say, but I don't want to stand
up and say "I'll do this", and then find it's way outside of my
capabilities.

> Russell doesn't have a fast Internet link.

I have a zip drive that I can connect upto a PC at uni - if people
want things uploading, I can do it if it's sent to me on a zipdisc...

> 	  either RiscPCs or other ARM6-based hardware who would like to

*waves hand in air*

> 	  think about changing the name eventually...).

How much is involved in this?
(Low-level VIDC hacking?)

> 	  port for the ARM, and it seems like a good idea. 

I'd assume (perhaps wrongly) that this is mostly just a question of
grabbing the sources and compiling things. I could perhaps do this,
depending on what sort of timescale things are going to happen on.

> 	  ARM as Norcroft does, and this is a bit of a shame.

This isn't just arm-linux, though - and I thought there was already
someone working on this.

> 	- Some sort of emulator to allow RISC OS binaries to run might be

fun, yes. Whether it could actually have any practical value or not
is another matter ;-)

As far as I can see, from what's on the ftp site, I can't do anything
without having access to an A5000, and I don't :-(

-- 
Joseph Heenan
email: [email-masked], [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 20 Jan 1997 01:26:42 +0000 (GMT)

> cross compile things, but that's kind of hindered by not having any

Hopefully, source we _will_ have soon.  If Russell sends me the disk then
I can put up on an ftp site for other people to download. 

> up and say "I'll do this", and then find it's way outside of my

I think it ought to be well within the capabilities of somebody who knows
a reasonable amount about the ARM family, has the hardware, and has some
experience of the kernel.

> want things uploading, I can do it if it's sent to me on a zipdisc...

Yes; I have a SyQuest drive in my (Internet-connected) machine.

> (Low-level VIDC hacking?)

Not even much of that.  As things stand, the screen mode is set up by RISC
OS and left alone by Linux.  It would be nice to have a way to change it,
but it's not vital. 

> depending on what sort of timescale things are going to happen on.

Basically yes.  There are things like alignment errors that will need to
be fixed up -- as far as I know, the ARM3 is currently unique among Linux
machines in that it absolutely _cannot_ do an unaligned access.  The Intel
will do the access happily; the Alpha and the SPARC (and the ARM6+ with
MMU on, I think) will fault and you can emulate it in software, but the
ARM3 will silently discard the low address lines.  Other than that,
someone will need to write an installation system and the rest is just a
question, as you say, of compiling things up.

> This isn't just arm-linux, though - and I thought there was already

Indeed.  With this (and X as well) we should liase with the NetBSD people.

> fun, yes. Whether it could actually have any practical value or not

It could do.  Things like BBC BASIC and Norcroft C might be beneficial to
be able to run under Linux, and I don't think it even ought to be too
tricky.  

> without having access to an A5000, and I don't :-(

That certainly does seem to be the state of play at the moment.

P.

---

From: Joseph Heenan <[email-masked]>
Date: Mon, 20 Jan 1997 12:13:12 +0000 (GMT)

> I can put up on an ftp site for other people to download. 

ah. That would be /very/ useful. Then I can pester someone about how
to get a cross-compiler working :-)

> OS and left alone by Linux.  It would be nice to have a way to change it,

oh right - something like this is somewhat lower on my priorities
than actually getting the thing runnning in the first place, though ;-)

> [Debian and compiling it]
> 

Perhaps I've got the wrong end of the stick here - I'd assumed
debian would be a lot of C sources that just need perhaps the odd
bit of inline assembler rewriting. Surely the C compiler should handle
all the platform specific things, apart from inline assembler?

> Indeed.  With this (and X as well) we should liase with the NetBSD people.

Agreed.

> be able to run under Linux, and I don't think it even ought to be too

Basic sounds like quite a good idea. Shame it's copyright, really -
a basic interpretter running under general unix has some sort of appeal
to it :-)
I'm sure gcc will get to the point of generating code as good as
Norcroft again at some point - and Norcroft isn't without its own
problems. :-)

-- 
Joseph Heenan, Computer Systems Engineering Student, Warwick Uni
email - [email-masked]   [email-masked]
www   - http://www.csv.warwick.ac.uk/~esuvf/

---

From: Philip Blundell <[email-masked]>
Date: Mon, 20 Jan 1997 12:25:15 +0000 (GMT)

> all the platform specific things, apart from inline assembler?

No.  To take a contrived example, imagine you have this:

unsigned char foo[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
unsigned int *bar;

bar = (unsigned int *)(foo+1);
printf("bar = %08x\n", *bar);

On Intel, this gives:

kings-cross:~$ ./align
bar = 05040302
kings-cross:~$

On Alpha, this gives:

paddington:~$ ./align 
align(1964): unaligned trap at 0000000120000a74: 000000011ffff711 28 2
bar = 05040302
paddington:~$

But on an old ARM, you will get `bar = 0x04030201'.  The reason is that
the dereference of `bar' compiles to an LDR instruction.  In general, the
compiler can't know the alignment at compile-time, so there's not a lot
else it *can* do.  Old ARM machines silently discard the low two address
bits when you ask them to do a word access.  This differs, as I said
before, from the Intel (where you get the correct access performed, albeit
more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS
has to patch up in software).

This sort of thing doesn't crop up *that* often, but it does happen, and
code will go wrong when it does.  There is *very* little inline assembler
in most things, and I doubt much porting work will be needed in general.
A lot of autoconf scripts will probably need to be taught about Linux/ARM,
but other than that...

> a basic interpretter running under general unix has some sort of appeal

Yes.  OTOH, although it's copyright, if it's in ROM it can be used fairly
freely.  Someone sufficiently sick could probably write a snippet of code
to be run as root that rummages around the RISC OS ROMs and pulls out the
BASIC module. 

P.

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 21 Jan 1997 17:16:51 +0000 (GMT)

> 	  behind.  ELF is important for shared libraries,

I'd like to generally get more involved with all the compiler stuff.  I
need to improve my C and I want to make some contribution back to GNU.  I
have the 2.6.3 sources at home & I've been reading the docs but I want to
understand GCC better before I make any firm commitments to doing
anything. 

> 	- Some sort of emulator to allow RISC OS binaries to run might be

Knowing me, this is the sort of project which I would start.  And then
never get finished.  I could help here if other people are willing to work
with me, but I'm not taking it on myself.  Rewriting RISC OS in C designed
to run on top of a fully-fledged unix sounds like quite a good idea anyway
;-)

P.S.  I think I may have sent you something destined for the list by
accident.  Would it be possible to forward it back to me?

---

From: Philip Blundell <[email-masked]>
Date: Tue, 21 Jan 1997 17:19:31 +0000 (GMT)

> understand GCC better before I make any firm commitments to doing

Right.  You probably want to get the 2.7.2 sources, just for the sake of
being up to date.  I must find out how imminent 2.8 is as well. 
 
> to run on top of a fully-fledged unix sounds like quite a good idea anyway

Mmm.  Well, I'd be interested in doing that myself, but at fairly low
priority (glibc is top of my list right now).  Interesting though a RISC
OS emulator would be, I think it probably ought to wait for a while.  
 
> accident.  Would it be possible to forward it back to me?

I have done.

phil