Subject: Re: Arm Linux (fwd)

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

This is from Russell.

Philip Blundell writes:
> 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.

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

A single Linux kernel should now be able to run on a RiscPC with
ARM610/ARM710/SA110 processors.  This appears to have temporarly broken the
A5K and ARC code, and is under investigation when I have time.

I have been borrowing someones ARM710 card, and I know that Linux now boots
(I allow it to run 'til the end of the kernel initialisation only).  The data
abort handler code needs to be coded though (I don't have any information on
this though), and some way of handling the IMPlementation specific bit in the
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.

> 	- 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.

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).

> 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...).

The ARM Linux X source is not really based on XF86, except for setting up
the keyboard and switching VTs on startup.  My X port as it stands does not
require XF86 in any way, and I believe that XF86 will only make it larger
for older machines, and therefore slower due to swapping.  This is the main
problem on older machines.  RiscPC's, X appears to fly.

There is one improvement that I have planned for it, but I believe that it
may cause more hastles than it is worth - allowing the X server to store
the current key mappings (normally read out of the kernel) in a file.  This
would mean that it should startup quicker than it currently does.

Oh - I am currenly seeing quite a few applications where the performance is
severely reduced - perl for instance.  Perl appears to take ages to do
anything meaningful.

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

Indeed.  This would be a great help - I can then concentrate solely on the
kernel aspects (and maybe a few Acorn specific user level bits), rather than
the whole project.

> 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.

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.

> 	- 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).

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?], 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).

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

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.  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.

> 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.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King      [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Matthew Wilcox <[email-masked]>
Date: Wed, 22 Jan 1997 09:17:22 +0000 (GMT)

> require at least OS_EnterOS, but that may be wrong.

Can't be implemented in a naive manner, maybe.  It would be feasible to
write a RISC OS emulator that kept track of what state a virtual processor
had and decided whether or not to allow certain accesses on that basis.
For example, interrupts would have to be implemented by the use of
signals, calling os_intoff would simply disable signals from being
delivered until os_inton was called again.

The trick is deciding at what level we want to emulate a RISC OS
environment - booting RISC OS on the ARMulator is one possibility, but it
would be extremely slow (and requires additions to the ARMulator to
emulate iomd, vidc et al).  A replacement kernel that handles loading
extension modules is another possibility - but rather tricky.  Writing
replacement modules that implement the RISC OS API is the cleanest
solution, but it's the biggest job to do. 

The main problem as I see it is the 26/32 bitness - does Linux/ARM run in
32 bit modes on capable processors?  Is it possible for different
processes to be run in 26 bit mode?

I'd like to know more about the design of the kernel and its
implementation on the ARM.  Does anyone have any good references for an
overview of the kernel?  I have the source, but it's rather tricky to
understand the design from that.

---

From: [email-masked]
Date: Thu, 23 Jan 1997 22:49:01 +0000 (GMT)

Matthew Wilcox writes:
> emulate iomd, vidc et al).

Dave Gilbert has a version of the ARMulator (with bug fixes) that allows
RiscOS 2 to run.  The ARMulator appears to have some very serious bugs, and
in fact, Linux trips up on some of them at the moment.  This idea I believe
may well be the most viable.

> A replacement kernel that handles loading extension modules is another
> possibility - but rather tricky.  Writing replacement modules that
> implement the RISC OS API is the cleanest solution, but it's the biggest
> job to do. 

Linux already handles loadable modules!  Even dynamic loading and removing
of modules.  This would provide a neat way of providing this, and may even
allow some of the RiscOS modules to be used.  However, since the system is
32bit, any device drivers would have to be re-written.  Memory mapping would
be an interesting issue.

> processes to be run in 26 bit mode?

On the ARM, you don't have 'virtual machines' as you do on the 386.  The
kernel does run in 32 bit, but the binaries run in 26 bit.  32 bit binaries
will be implemented eventually though.

Note also, that the StrongARM does not support 26-bit exception handlers,
but I believe this to be irrelevent.  I have heard rumors that 26-bit
support will be dropped completely later.

One of the problems is that the ARM does not fault priviledged instructions
as the x86 hardware does.  If it did, then there would be a strong possibility
of using most of the RiscOS proms as they stand.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King      [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
    +-+-+ -------------------------------------------------  /\\\  |