Subject: Re: Arm Linux

From: Philip Blundell <[email-masked]>
Date: Wed, 22 Jan 1997 01:29:44 +0000 (GMT)

On Wed, 22 Jan 1997, rmk wrote:

> It should not very difficult - I have been redesigning the processor support
> in ARM Linux, and now have it done the correct way ;)

:)
 
> page tables (= Updatable on the ARM610).  The ARM610 port I believe is just
> another case of the above - the ARM610 and ARM710 I believe are very much
> alike.

They are.  As far as I can tell the only difference is the cache size, and
someone from NetBSD posted that there is some difference in abort handling
as well.  I've got both data sheets here, but I haven't trawled through
them with a fine-toothed comb to see if there are any other differences. 

> I have sorted out the memory management level code, however, I have to upload
> a new set of patches (sometime) for Alan to look into).

Right.  Well, no great rush.

> > 3. Tools and stuff.
> > 	- ELF.  Linux is moving to ELF, and we don't want to be left
> > 	  behind.  ELF is important for shared libraries, especially...
> 
> I'd prefer to hold off on this until a standard appears.  The reason is that
> it requires registration, and there are some complex issues that have to be
> addressed.  I do have some tools that will read ELF arm in a very minor way,
> but it would be totally incorrect to create our own standard until one appears
> from ARM Ltd.

I think we should work with ARM Ltd to produce a standard, if need be.
IMHO, ELF is important.  There is no point investing effort in dead
technology. 

> The reason for this is that if we implement our own, and a standard does
> appear, then there will be major incompatabilities in the library and
> object files. 

Yes, but if we run with a.out now, then all library and object files will
be utterly useless when ELF does appear. 

> > 	- glibc, or libc.so.6, is the new Linux shared library.  It needs
> > 	  to be ported to the ARM.
> 
> This can be done after we have ELF support (since the latest libc versions are
> ELF only).

I know.  OTOH, preliminary work can be started before we have ELF.  For
example, ARM-code versions of many functions must be written - anybody who
enjoys writing optimised assembler is welcome to pitch in to this effort. 

It is important that we have a stable C library.  If we are still running
from a ported libc 4, that is not good enough - even if you've been
amazingly dilligent, the chances are that it still contains bugs, and that
performance is going to be less than that of glibc.  It also lacks many
features, like threads, and introduces a compatibility nightmare (right
now, I'm going through the pain of making code compile for glibc -- I
don't want to have to do this in reverse for the ARM at a later date). 

> Also, the 2.1.x kernels come into this category.  The 2.1.x kernels have an
> altered memory management checking system (it no longer verifies addresses
> before using them [will this cause problems on old hardware?]

I was thinking about this the other week.  I believe we should be OK.  Can
you provide any examples of scenarios that will go wrong?

> instead they build up tables of possible faulting instructions.  This
> will be extremely difficult for the ARM - we have an unrolled user
> memcpy routines in the kernel == loads of different addresses for
> faulting instructions, and the problem of how to generate the tables
> without ELF).

I believe the first of these has already been addressed (by davem, I
think) - you can give a _range_ of faulting instructions.  I think this
should cover virtually every case, since exceptions only tend to turn up
in constructs like:

if (copy_from_user(...)) return -EINVAL;

where the only instructions that can fault are the user-space accesses,
and any one of them faulting means the same thing.  If there are any more
complex uses of exceptions we may have to think more carefully, but I
don't think there is any fundamental problem.

The second is more of an issue, and is yet another reason why I believe we
should go for ELF.

> So which great person decided to go all out for ELF?  Is he mad?

He was probably just fed up with building a.out shared libraries.  In
the real world you _cannot_ insist that everybody pick a unique base
address for their library.  It totally stifles development. 
 
> ELF will cause fundamental problems on the ARM3 machines - ELF appears to
> require a physical page to be mapped in twice, which is absolutely impossible
> on the ARM3 and older.

That's bad.  I shall have to have a think about that one. 

> > 4. Weird stuff.
> > 	- Some sort of emulator to allow RISC OS binaries to run might be
> > 	  a fun thing to have.
> 
> I think that this may be more of a disadvantage than an advantage.  There
> will obviously be several SWI's that just cannot be implemented - OS_EnterOS,
> OS_Memory, OS_SetMemMapEntries, OS_IntOff etc.  I believe that basic may
> require at least OS_EnterOS, but that may be wrong.

Yes, obviously.  I wasn't suggesting we implement the whole of RISC OS,
but I believe something that can run simple applications would be doable,
entertaining and potentially useful.  I can't see how it could be a
disadvantage.

phil

---

From: Philip Blundell <[email-masked]>
Date: Wed, 22 Jan 1997 13:18:12 +0000 (GMT)

On Wed, 22 Jan 1997, rmk wrote:

> before using them [will this cause problems on old hardware?], instead they
> build up tables of possible faulting instructions.  This will be extremely
> difficult for the ARM - we have an unrolled user memcpy routines in the kernel
> == loads of different addresses for faulting instructions, and the problem of
> how to generate the tables without ELF).
> 

A more serious problem with 2.1, actually, which we need ELF to fix, is
that it starts to make heavier use of special sections (via gcc __asm__
magic).  Exception fixup stuff goes in a new section, so that it's taken
out of line, and there are moves afoot to put all the kernel
initialisation code in another section so it can be thrown away after
boot time.  I have a feeling Richard's new modules code does some stuff
with ELF as well.

P.

---

From: [email-masked]
Date: Wed, 22 Jan 1997 14:58:58 +0100 (MET)

I've recently started out writing an adfs-fs for linux. I have now come to
the point where I can see it isn't going to be one of 'those projects you
never finish' so before really putting huge amounts of time into it I'd like
to know whether a) somebody else is writing one too, and how far they've
gotten already b) somebody else HAS already written one.

Cheers,

-- 
Eli-Jean Leyssens, alias Pervect of Topix
email: [email-masked]

      --- It's an OS Bill, but not as we know it ---

---

From: Philip Blundell <[email-masked]>
Date: Wed, 22 Jan 1997 15:05:42 +0000 (GMT)

On Wed, 22 Jan 1997, rmk wrote:

> on the ARM3 and older.  On the StrongARM, it may be possible, but it'll mean
> being careful with the caches.  It may cause cache consistency problems on the
> ARM6/ARM7 though since they use a combined data & instruction cache.

On a more philosophical point, I don't believe we should sacrifice
features or performance on new machines for the sake of retaining ARM3
compatibility.  Linux on my A5000 is never going to be more than an
amusing toy, whereas Linux on the 610/710/StrongARM has real-world
applications.  Thus, if it _does_ turn out that we can't implement ELF on
the ARM3, tough - people with old machines will have to stick to a.out and
take the consequences, but we should still develop ELF for the benefit of
those with the newer technology.  

P.