Subject: Re: Mips project Go or Wait?

From: Andreas Busse <[email-masked]>
Date: Wed, 4 Aug 93 16:45:47 +0200

> Hello,
>      I wanted to throw out some thoughs about this project and see what
> people thought.  It seems to me that two things are certain:
> 
> 	1) The price/performance ratio of RISC processors will only get
> 	   better in the future.

Correct. Although nobody can pay the latest developments.
Look at the R4000PC. Only *one* year ago it was around $2000,
now it's at about $600...

>	2) It will take a (fairly) long to design and debug this thing.

Don't know. This depends on how complete the NEC ARCset is. So far I
know solves it most of our problems. In case it is true that the
ARCset is a *complete* design, we would only have to make some
changes to satisfy the requirement of the group. Perhaps we have to
make no changes at all !

> I know that it would be difficult, but given the above, I believe that it
> would be good to try to predict how long it will take to design the board
> and its operating system, and to try to predict what the cost of the components
> will be at that time, and design on the basis of that.  I realize that this
> approach is full of risks, and would be difficult to do, but I am afraid that
> if this approach is not taken, the board my be obsolete by the time it is
> usable.

Neil made the assumption that it will take a bit more than half a man-year
to port the kernel and drivers. This depends on how many filesystems we will
support. For me, ext2fs and the ISO fs would be enough.
Everything else *should* compile out of the box, except the X11-server stuff.
That sounds not too bad, isn't it ?

I can't say how long it takes to make the hardware working, because it
depends on what we want.

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  [email-masked]
-------------------------------------------------------------------------------

---

From: [email-masked] (Hannu Savolainen)
Date: Wed, 4 Aug 93 21:37:39 EET DST

> That sounds not too bad, isn't it ?
It should not be difficult to port the filesystems since they don't
access hardware. Also most of the SCSI driver code should be easy to
port since we have to write just a low level driver for one SCSI
chip/host adapter. If we have the ISA bus, porting the ISA device
drivers could be possible by just rewriting the inline assembler macros
used by the drivers. A well written device driver is not CPU dependent.
There could be some problems if the new CPU is big endian.

Hannu

---

From: Drew Eckhardt <[email-masked]>
Date: Wed, 04 Aug 1993 18:01:08 -0600

Neil made the assumption that it will take a bit more than half a man-year
    to port the kernel and drivers. This depends on how many filesystems we wil
   l
    support. For me, ext2fs and the ISO fs would be enough.

It has little to do with how many filesystems we support, as the filesystems 
should be devoid of any system dependant code.  Endianess is pretty easy to 
deal with where we need binary compatability with existing filesystems (ie
MSDOS since you may want to read DOS floppies). 

As far as how long device drivers take :

IDE, serial, parallel, etc. where we've got the same parts as in the PC - 
we simply add appropriate #ifdef LINUX_MIPS or whatever to the kernel sources
around code that does memory mapped I/O instead of using the port commands.

SCSI - it looks like the SCSI driver I'm writing right now (NCR5380) 
will have taken about 20 man-hours (including me reading the NCR5380 
databook, designing the driver architecture, writing the code, etc) by 
the time it goes into ALPHA test.  The 5390's are even easier to program. 

Ie : device drivers are not a significant problem.

I think the hard parts will be taking care of the major 386isms, ie the 
scheduler and VM which is really prone to race conditions.  Since people have 
access to other MIPS architecture machines (ie, Decstations) and sample MIPS 
code to work with (BSD4.4 runs on the Decstations) this can happen in parallel 
with the hardware development.

    Everything else *should* compile out of the box, except the X11-server stuf
   f.
    That sounds not too bad, isn't it ?

I don't think there will be any significant technical problems getting 
the software up. 

Speaking of kernel development for the MIPS : we need to start a discussion
on how to best make the kernel sources multi-architecture, so that one 
release of Linux runs on MIPS, Intel, and Motorola platforms.

The AMIGA people didn't bother to do this, so they need a different 
kernel distribution and can never take advantage of new features 
when they're added.

---

From: [email-masked] (Jeremy Fitzhardinge)
Date: Thu, 5 Aug 1993 13:19:44 +1000 (EST)

> support. For me, ext2fs and the ISO fs would be enough.

The filesystems are entirely in the machine-independant code.
I don't think many changes at all will be needed for porting all of
the filesystems.  The MMU, DMA, interrupt handling and simplest device
drivers (console, serial, naif SCSI/ether) will probably be the longest to
get going because the machine is useless until they do.

> That sounds not too bad, isn't it ?

With a dumb frame buffer there will be very little work getting X11 going.
There's already lots of support in the MIT code for 8 bit deep dumb
frame buffers.  It'll just be a matter of reading the keyboard and mouse
properly (I think - I could be completely wrong).

Libraries could be a challenge to port.  Not because its very difficult
or machine dependant, but all kinds of correct decisions need to be made.
For example, if I were to port linux to an 4000, should off_t etc be
64 bit?  If so, should the library and compile environment have support
for a 32 bit environment and a 64 bit one (by having the 32 bit syscall
lib functions convert their args and returns to 64 bit).

> I can't say how long it takes to make the hardware working, because it

Bearing in mind that 4000 based commercial machines are becoming available
*now* at reasonable or nearly reasonable prices.  For example, a brocure
from a company called "Tangent" turned up here selling an R4000 based
machine (can't remember which variant) running at 100MHz, 16MB ram,
16k cache (cannot sure if its I+D combined or 16k each), 200MB disk, hi
res graphics (~1000x1000x8) with 64 bit path to CPU + S3 accellerator,
E?ISA slots, monitor and Windows NT (SVR4 port available) for $4000 US.
That was the base machine with others up to 150MHz, more cache and memory
and so on.  A similar machine is $10000 here, but that's predictable.
Whether or not thay can actually deliver is another question.  Its also
possible that they'd sell motherboards alone.

I'm not cash starved and I'm keen to port linux to a Mips machine
(I've started already, mainly by looking at the i386 kernel for machine
dependancies and isolating them), so this kind of thing is an option
for me.  It also means there's some chance of a Mips kernel waiting for
any board that gets built.

	J

---

From: Drew Eckhardt <[email-masked]>
Date: Wed, 04 Aug 1993 21:35:43 -0600

There's also 32 bit server code (from DEC) in the contrib hierchy.

Take a look at the various papers from Convex ('92 Winter USENIX proceedings),
BSD CSRG, etc. on supporting Big Files.

---

From: [email-masked] (Jeremy Fitzhardinge)
Date: Thu, 5 Aug 1993 15:48:21 +1000 (EST)

> release of Linux runs on MIPS, Intel, and Motorola platforms.

I've already started this.  I have the root source dir.  Under it is
common/ with everything that's machine independant (filesystems, most
syscalls, etc).  There's another tree with cpu/arch, eg, i386/isa,
m68k/common, m68k/amiga, mips/common, mips/riscy, mips/idt and so on.
Currently I have a i386/isa with all the obviously intel specific stuff
in it (most things with __asm__(), dma, interrupt device drivers and so
on), and common with everything else.  It almost compiles, but I haven't
upgraded it to pl11.  Once it compiles, I want to try and move some
of the more gratuitous dependancies into portable code (like the asm()
in printf for doing a divide).

The include dir is also split, with the machine dependant stuff being
looked at before the common.  Of course, common code will include machine
dependancies from headers.

I think the port should avoid unnecessary changes to linux itself - it
should be a port and nothing more.  That doesn't exclude architecture
specific optimisations, but they are not necessary for the initial port.
Once its done, then other changes can happen.  This means that there
should be as much shared code as possible (which is why each cpu has a
common directory).  Also, the port will be for little endian mips, and
the tlb stuff will look like the intel mmu, because its easy to do so,
and there's no efficiency problems from doing so.  Using this approach
there can be a maximum of sharing with the intel linux.

I'm mostly interested in coordinating the initial port; that is getting
core of linux running on a mips chip.  I think it should be done by a very
small number of people in close communication, with a strong direction.
After that, it's easy to get more people working at once on porting device
drivers, essential usermode stuff (libraries), and so on.  From there,
it's everyone go.

I'd like to get a mips platform to start porting with before any hardware
is built, so there is something solid to start with -- there's little
enough time to make this compeditive as it is.

> kernel distribution and can never take advantage of new features 

Yes, I was dissapointed by this.  The whole port looked a quite hackish.
It wasn't even very useful to find out where they had found intel
specific stuff, because they didn't localize it but just replaced it
with Moto things.  But it does work, I gather, and that's a start.
Perhaps when we have a good multi-architecture tree the moto stuff will
slot in easily.  I notice that they are trying to make it work on the
Amiga, ST and Mac.

	J

---

From: Bill Broadley <[email-masked]>
Date: Thu, 5 Aug 1993 03:21:33 -0500 (EDT)

> possible that they'd sell motherboards alone.

Well 16 MB ram is about $400, 340 MB IDE disk is around $298.  Sounds like
they are charging $3300 for a motherboard+video+case+monitor sounds alot
more then the planned under $1k for video+scsi+ethernet+motherboard to me.

-- 
Bill					1st>	[email-masked]
[email-masked] <2nd 	3rd> 	             [email-masked]
Linux is great.         Bike to live, live to bike.                      PGP-ok

---

From: [email-masked] (Guido Leenders)
Date: Thu, 5 Aug 93 10:57:24 MET DST

> in printf for doing a divide).

That was a great idea. I just want to make two suggestions:

1. Maybe you could contact Linus about this. You might try to
   convince him to incorporate this source tree into the official
   releases, so we don't have to catch up with new releases 
   all the time.
   Of course it's not at all totally sure that this project will
   ever get done, but it's a general good thing, since maybe
   someone in the future will try to make a port to (say) Alpha.
2. Maybe you could move the common-directory, to get more object-oriented,
   e.g.
	  i386  (common i386-stuff)
		 --- isa (isa-specific)
	  m68k  (common 68000-stuff)
		 --- amiga
		 --- mac
		 --- atari

Just a few thoughts.

Guido

--
Guido Leenders
[email-masked]
Eindhoven University of Technology
the Netherlands

---

From: [email-masked] (Cyberman)
Date: Thu, 05 Aug 93 16:31:12 EDT

> kernel distribution and can never take advantage of new features 

WELL one way to do this is too do what the people who made nethack did.
Have people submit additions and patches and let them corelate 
modifications.  Also they when for system independance by using the
ussual conditional compiling.  They had one config.h for selecting the
OS options and one OS specific config.  In linux case perhaps a general
purpose config.h and a processor specific config and then a machine 
specific configuration.  The only problem I've had compiling nethack 
under this strategy are unimplemented system functions like stty gtty and 
lock.  I hate having to work around such things (grin).  

Cyberman

 "Everything is vanity ..."
"Even a fool looks wise if he keeps his mouth shut"
"A man to his own, is a person left to his own devices"
"Bewary of thinking you are always right, Hitler did"

Computer Engineer - hopeing to get employement