Subject: MIPS port kickoff meeting

From: [email-masked] (Ariel Faigon)
Date: Fri, 19 Apr 1996 17:22:35 -0700 (PDT)

Hi LinuxMIPSies,

This is becoming real. Please mark your calendars.

We have Jamaica in B10U, which holds 12 people, from 4-5pm
on Wednesday April 24th.

I know it may conflict with someone's schedule but p l e a s e
try your best to show up.

THE MEETING HAS ONE MAIN GOAL:

	To ensure that when David Miller lands at SGI he wastes
	zero time on ramping up.  We can do a lot until he comes.

The idea Jim Barton, Larry and I had is:
	1) Office + two Indys (connected via a serial line to support
	   gdb remote protocol) already waiting, phone, email etc.
	2) Development tools installed
	3) The latest linux sources on the machine. After trying to
	   compile them and see how smoothly this goes.
	4) This may require the most work:
	   A 99% stripped down IRIX or set-top box thing that is
	   basically only the device drivers to boot and do:
		"hello console"
		"hello network"
		"hello disk"
		"hello keyboard"
		"hello console graphics"

	Given all this, David can boot Linux in a few days I guess :-)

Agenda:
	1) Quick round table: introduce everyone
	2) Sort out some details:
		Are we going for a 64-bit kernel?
		What MIPS instruction set should we support
		[e.g. 3K is important for the embedded market]
		What dev tools should we use?
		elf/coff stabs/dwarf gcc/cc etc. etc.
	4) Suggest more ways to accelerate David Miller's ramp up
	5) List action items
	6) Get volunteers for help on the above

Lastly, since David's Acceptance is final.  I think it is time
to put David himself on this mailing list too, he certainly has
some ideas on how to help us help him.

-- 
Peace, Ariel

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 22 Apr 1996 21:40:01 -0400

From: [email-masked] (Ariel Faigon)
   Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)

   Great, now you can tell the list what do you need :-)

Oh boy.

   Seriously, we've been thinking about how we could make you most
   productive and not waste your time when you arrive here.

   Here's a recent posting of mine, so you get the idea just in case
   Simon or Bob or Larry didn't tell you about all this yet...

   Feel free to bombard us with requests/questions.
   There are about 20 people on the linux list at SGI
   (you can query [email-masked]  for the details)

Already did that an hour ago ;)

(note: I looked back over this mail after composing it and I want to
       warn people who are not familiar with me yet that I am very
       sarcastic and am full of ridicule even when discussing
       important topics.  Please don't take it that I lack tact
       or am not being serious, because that simply isn't the case.)

Here is what I need:

	The following utilities I need for development.
	1) CVS/RCS, latest on prep.ai.mit.edu is fine
	2) Emacs-19.31 (rms should release within 2 weeks)
	3) All GNU smidgen-type utilies as the default binaries
	   (this include fileutils/sh-utils/sharutils/diffutils/
	    findutils/...)
	   Actually, Let me just stop short and say, if there is a
	   source tarball for it on prep.ai.mit.edu:/pub/gnu I would
	   like the latest installed on the machine I develop on.
	4) xfishtank (don't laugh)
	5) fvwm
	6) teco (Must support full teco command set as described
	   in original DEC manuals! TECO is _the_ renaissance editor!)

	The following would be nice, but if it will give people
	bladder problems to do these then don't go out of your
	way:
	1) MIPS 4[40]00 manual is some online format (not postscript,
	   something I can cut and paste out of an emacs buffer etc.
	   so maybe info or pure ascii text would be fine, I could
	   care less about the formatting, I just want the words
	   there)
	2) Docs on the ethernet/scsi interfaces and I/O bus
	   architecture for the first machine I will be getting
	   this to work on, again text/info format would be nice.
	   Of course I will probably just stuff in the ready
	   drivers you might be getting to me into Linux but I want
	   to write my own from scratch in the near future after
	   that.
	3) I know as much as a bum on the street about SGI machines
	   and the various lines, a nice "roadmap to sgi workstations
	   and servers, plus the hardware gook thats inside" type
	   thing would be very useful to me.

	I will feel more comfortable if:
	1) I became very familiar with who the heavy low level MIPS
	   assembly level hackers are who I will be dealing with while
	   I am there.  Please tell me who they are, introduce, make
	   us say hello to each other, you get the idea.

	2) I know the policy on loud music in the office I'll be in
	   ;-)

I've thought it over and to me the best plan for things this summer to
me is:
	a) R4400 32-bit "proof of concept, yeah we can pull it off"
	   port happens first, side effect is that I become intimate
	   enough with the chip that I can do things more efficiently.
	b) From here we look into the 64-bit stuff and whether that is
	   is even desirable on 64-bit.  (this would be my first
	   64-bit port outside of my initial UltraSparc hacks)
	c) Also think about the work needed to turn that code into
	   r3000 friendly code.  Should not be too much as I've done
	   the "write it on recent architecture design then backport
	   it to older design which had some limitations" already and
	   this didn't end up being so bad.

Expect more as I think it up... this should keep you guys busy for
now.

(Any dead-head tape traders at SGI engineering?  Just wondering, may
 want to start talking to them now ;-)

Later,
David S. Miller
[email-masked]

---

From: "Alistair Lambie" <[email-masked]>
Date: Tue, 23 Apr 1996 14:15:23 +0000

On Apr 19,  5:22pm, Ariel Faigon wrote:
> Subject: MIPS port kickoff meeting
> Hi LinuxMIPSies,
>
Umm...could be a problem.  It's a holiday here in New Zealand, otherwise :-)

> 		elf/coff stabs/dwarf gcc/cc etc. etc.

My 2c worth:
   1. We should definitely do 32bit, probably 64bit as well.  There is a
      big base of R3k machines out there that are going to start getting
      left behind soon.
   2. We need to go for lowest common denominator (MIPS I) and then add
      conditionals (in the low level bits) later.  The c code can of course be
      compiled as the user wants it.
   3. We need to support machines that don't have a graphics head (servers).
      This requires serial drivers.
   4. We should really tie this project in with what is happening at
      http://lena.fnet.fr/.  Their goal has been to get Linux on ARCS systems
      running little endian, but there is a need for a MIPS port for MIPS (the
      company) R3k machines which needs to be big endian.
   5. Should we use the 'milo' bootloader?

	6.
> 	6) Get volunteers for help on the above
Probably not much I can do from here.  Maybe some Beta testing a bit further
down the track (test for bit inversion in the southern hemisphere :-) ).

I still have an interest in getting Linux on to the old MIPS boxes, so maybe
with a few quick hacks after David has worked his magic I can get this to
happen.  I suspect that this would also help CSD out as I know they still get
support calls from people who have these machines and are falling all over the
place with the development environment (svr3, bsd43, svr4).  Often they are
little more than people playing and having a Linux offering may be the best way
to get them out of our hair.  Also, RISC/os is getting a bit long in the tooth
now and there are still some nasty little bugs in it, often comms related which
more often than not is what the person wanted it for!

One thing that would be nice is for someone to minute the meeting to the list
so that those of us who can't attend can see what's happening.  I guess it is
also a good way of documenting the progress as things move along!

Cheers, Alistair

-- 
Alistair Lambie					    [email-masked]
Silicon Graphics New Zealand				  SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower,				    Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ			  	   Fax: +64-4-802 1459

---

From: [email-masked] (Ariel Faigon)
Date: Mon, 22 Apr 1996 19:16:30 -0700 (PDT)

>       or am not being serious, because that simply isn't the case.)
Feel free to express yourself, my english (colloquial and otherwsie)
is bad anyway, and I guess the others don't care :-)

>	1) CVS/RCS, latest on prep.ai.mit.edu is fine
RCS comes default with IRIX today. But I know it is not
the latest. OK, and I'll add cvs.

>	   like the latest installed on the machine I develop on.
Many of these are in our freeware project. Ready to install with
the click of a mouse. (Yes, one of the cool things about SGI is
a joe-user software installer infinitely better than RPM/glint.)

(yon) 84 /var/tmp> which find
/usr/freeware/bin/find
(yon) 85  /var/tmp> which tar
/usr/freeware/bin/tar
(yon) 86 /var/tmp> which grep
/usr/freeware/bin/grep
(yon) 87 /var/tmp> which chmod
/usr/freeware/bin/chmod

I'll add the missing ones. That's easy.

BTW, we called it '/usr/freeware' rather than '/usr/gnu' because
many packages are from other sources and because some of our
customers asked us to stay away from their /usr/local.

>	4) xfishtank (don't laugh)
Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)

>	   in original DEC manuals! TECO is _the_ renaissance editor!)
I'll try to build these too.

>	   care less about the formatting, I just want the words

For MIPS ABI stuff: try the following web site,

	http://www.mipsabi.org/
Especially:
	http://www.mipsabi.org/Tech/Technical.html

Tell us what's missing there.

As for the MIPS programmer's Assembly manual. There is an excellent one
internally on the Web... I'll try to get you a copy soon.

>	   thing would be very useful to me.
I'll leave these to some other folks on the list.

>	   us say hello to each other, you get the idea.
I believe the most knowledgable low-level gurus on the list are
Bill Earl and Jim Barton, I'm sure there are more, I just don't
know everyone on the list personally ...

>	2) I know the policy on loud music in the office I'll be in
I'm trying to get you an office right by mine :-)

>	   this didn't end up being so bad.
Cool.

> want to start talking to them now ;-)
You'll find lots of them here ;-)

-- 
Peace, Ariel

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 22 Apr 1996 22:27:56 -0400

From: [email-masked] (Ariel Faigon)
   Date: Mon, 22 Apr 1996 19:16:30 -0700 (PDT)

Cool, I feel much more comfortable now ;)

Nope, not a conspiracy.  Grab a copy of:

caip.rutgers.edu:/pub/davem/penguin.gif

Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
and dirty kernel code for 20 hours straight with no sleep and direct
intraveinus coffee keeping you going, and tell me that isn't the damn
most funniest thing you've ever seen in your life. (note said
description is the state I am in right now, whee... oh yeah, and the
penguin picture was found in Linus's home directory on
linux.cs.helsinki.fi one late night I was hacking on there :)

	   http://www.mipsabi.org/
   Especially:

Noted, I'll check some of that out.  Thanks.

Oh, yummy, heaven on earth.

Later,
David S. Miller
[email-masked]

---

From: [email-masked] (jon madison)
Date: Mon, 22 Apr 1996 21:55:33 -0500 (EST)

Ariel Faigon quoted, a little while back,
#>	5) fvwm
ariel, if you can't i'll swing it (i run bowman here...(bowman's
a 'better' fvwm (looks like NeXTStep...the GoodStuff is like NeXT's
dock)

j.

-- 
jon madison, silicon graphics, inc. 
us: <URL: http://www.sgi.com/>
mailto:[email-masked]        
me: <URL: http://klingon.iupucs.iupui.edu/~jmadison/>

---

From: [email-masked] (William J. Earl)
Date: Tue, 23 Apr 1996 09:35:24 -0700

>    Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)
...
 > 	   care less about the formatting, I just want the words

     The manuals are online, generally at www,mips.com.  For example,

	http://www.mips.com/r4400/UMan/R4400_UM_cv.html

is the latest R4400 manual.

     Our newer processors for low-end systems are the R4600 and now the
R5000.  Most Indy systems now ship with R5000 processors, and the Indy should
be the target for the initial port, since it is in current production and
widely available.

     The R4600 and R5000 are generally similar, except that the R4600
has 16 KB primary caches and is MIPS III, whereas the R5000 has 32 KB
primary caches and is MIPS IV.  Both are fairly similar to the R4000PC
and R4400PC, in the sense that they do not have a secondary cache
which enforces primary cache virtual index coherency.  (Many Indy
R4600 and R5000 systems do have secondary caches, but they do not
supply virtual coherency exceptions.)  The R4600 and R5000 are good
targets for an initial port, because they have the fewest errata, and
hence require the fewest kernel workarounds.  The R4000 workarounds,
in particular, are pretty messy.

     The R4600 and R5000 data sheets may be found via

	http://www.idt.com/risc/Welcome.html

(under the 64-bit RISC microprocessors category).  The manuals are not online
on public servers, but I can track down copies.  There is some more 
R4600 and R5000 information under

	http://www.qedinc.com/

There is a comparison of the R4400 and the R4600 at

	http://www.mips.com/r4400/Des_Com/Des_Com_cv.html

The MIPS IV architecture document is

	http://www.mips.com/arch/MIPS4_cv.html

This is of relatively minor importance for a basic port, but can be used
to good effect to improve graphics and application performance.  There are
a few minor kernel support issues.

     Once the basic port is done, extending it to the other common processors,
such as the R3000, R4000, R4400, and R10000, will be fairly simple.  The R6000
(not common and obsolete for some years now) and the R8000 would be somewhat
more work to support, since they differ more from the other processors in 
the kernel interface.  

 > 	   to write my own from scratch in the near future after

      I have the documents for the memory controller for Indy, and I think
I can locate most of the others.  They are only on paper, however, but I can
get copies.

 > 	   thing would be very useful to me.

     There are tables of the systems under

	http://ssales.corp.sgi.com/products/html/periodic_table.html

Unfortunately, these are inside the firewall.

 > 	   us say hello to each other, you get the idea.

     I am probably the best initial contact for Indy issues, and I can
introduce you to people familiar with the various drivers and so on.

...
 > 	   enough with the chip that I can do things more efficiently.

     As I mentioned above, the R4600 and R5000 processors are a simpler
initial target, and the Indy R4600 is the most common configuration.

 > 	   64-bit port outside of my initial UltraSparc hacks)

     This is mainly interesting on the larger systems.  64-bit kernels
do take more space and time (due to extra cache misses, if nothing else),
and most applications don't need more than 32-bit addresses.  The 32-bit
kernel should, however, support using 64-bit arithmetic (MIPS III and IV)
even in 32-bit programs, since there are substantial performance gains
available for certain applications.  The kernel itself can use 64-bit
arithmetic to good effect as well.  (This is how IRIX works.)

 > 	   this didn't end up being so bad.

     The R3000 is not drastically different from the R4600.  The main
differences are somewhat different TLB and cache control routines, and, of
course, the MIPS I instruction set.

---

From: "Greg Chesson" <[email-masked]>
Date: Tue, 23 Apr 1996 09:39:29 -0700

There are US Gov't customers for Linux on SGI boxes who require
64-bit OS.  So, let's support tho 32-bit ARCS boxes without compromising
opportunities to sell new boxes (with 64-bit Linux).

g

---

From: "Bob Mende Pie" <[email-masked]>
Date: Tue, 23 Apr 1996 09:56:42 -0700

> 	5) fvwm

I've got 2.0.42 compiled and running ... But if dave wants to live in the dark
ages of fvwm 1.x thats fine with me.

> 	   in original DEC manuals! TECO is _the_ renaissance editor!)

I've got it compiled, but beats the hell out of me if it works :-)  Ill make
you a deal, if I see you edit a file with it I bring you my honest to god DEC
PDP-11 teco manual.

-- 
				      /Bob...			 [email-masked]
				http://reality.sgi.com/mende/

---

From: "Jim Barton" <[email-masked]>
Date: Tue, 23 Apr 1996 10:06:11 -0700

The purpose for basing the port on R3000 is *not* to support obsolete
workstations and servers; our time and effort need to be directed to the
future, not the past. If the guys in OZ want to port it, fine.

Basing on an R3000 is important because of it's exploding use as an
embedded processor; it's showing up in your laser printers, phone
switches, robots, airplanes, satellite receivers, and so on. One thing
Larry and I are interested in is seeing if Linux is really suitable
as an embedded OS to support these (and more) applications.

What you typically find is an r3k core surrounded by various application-
specific peripherals, e.g, MPEG decoders, sound chips, DMA controllers,
serial controllers. The OS is usually in ROM, and the device manufacturer
adds special drivers to the mix. Real-time constraints come into play;
in particular, it would be interesting to consider what additions to Linux
make it work well for real-time applications. Posix 1003.4 is pretty
heavy-weight, but perhaps we can have a light-weight implementation.

In the workstation/server world, the R4000 is the processor to aim at.
It is significantly different than the r3k in TLB layout, but little
else in 32-bit mode, so the same code should basically work both places.
I believe different binaries should be built for the r4k and r3k - certain
pieces of MIPS II ISA can accelerate performance, and the compilers take
advantage of that.

Given that the workstation/server world is moving to 64 bit, I believe we
need a 64-bit version of Linux as well. The design of the MIPS III ISA
is actually pretty clean for keeping the same source between 32-bit and
64-bit kernels, as long as you are careful about your types.

The r4k is also interesting because it is at the heart of the Nintendo
Ultra-64 game, and the R4300i processor it uses is starting to show up
in various Japanese computer products. The volumes of this device are
projected in the 10s of millions of units, so it is significant. Linux
in your Ultra-64 box? Hmmmm. Might actually be interesting ...

So, we need to be able to build three versions from the same source.
I think the R10K can be ignored for now, and it *only* runs in 64-bit
kernel mode. 64-bit user mode can also be ignored for now - there are
few applications for 64-bit programs except in the high-end scientific
markets. The R8K is obsolete.

-- jmb

---

From: "David S. Miller" <[email-masked]>
Date: Tue, 23 Apr 1996 21:56:27 -0400

Date: Tue, 23 Apr 1996 09:35:24 -0700
   From: [email-masked] (William J. Earl)

This having been noted, is my account at sgi going to be setup soon so
that perhaps I could telnet in using the firewall and look at the docs
mentioned from an internal machine?

Later,
David S. Miller
[email-masked]

---

From: "David S. Miller" <[email-masked]>
Date: Tue, 23 Apr 1996 21:58:25 -0400

From: "Bob Mende Pie" <[email-masked]>
   Date: Tue, 23 Apr 1996 09:56:42 -0700

Someone else is building 1.24l for me right now methinks... better
check this out before bucking heads ;)

     [1 J^P$L$$
     J <.-Z; .,(S,$ -D .)FX1 @F^B $K :L I $ G1 L>$$

Later,
David S. Miller
[email-masked]

---

From: "David S. Miller" <[email-masked]>
Date: Tue, 23 Apr 1996 22:05:40 -0400

From: "Greg Chesson" <[email-masked]>
   Date: Tue, 23 Apr 1996 09:39:29 -0700

   There are US Gov't customers for Linux on SGI boxes who require
   64-bit OS.  So, let's support tho 32-bit ARCS boxes without
   compromising opportunities to sell new boxes (with 64-bit Linux).

Like I said I'll do the 32-bit port and work from there based upon how
I feel after that.

Remember I've got one kernel here which works on every 32-bit CPU type
Sun has every put into a box with almost no performance loss.  I can
do it too for MIPS and I will.  The goal being that some day I will be
able to slap the same kernel image into an INDY as I can for an ONYX
and a LEGO.

And also, I will design it such that, as in the traditional Linux
kernel model, you can config all this shit out and get the streamlined
minimal kernel which only works with a certain configuation. (MM code,
config it out because this is for an embedded system)

Later,
David S. Miller
[email-masked]

---

From: "Greg Chesson" <[email-masked]>
Date: Tue, 23 Apr 1996 21:31:38 -0700

agreed.
we should begin with the version of Linux that is the most natural
port for you.  The other versions can come later.  Note however that
Lego may prefer a 64-bit kernel.

g

---

From: [email-masked] (Ariel Faigon)
Date: Tue, 23 Apr 1996 22:32:55 -0700 (PDT)

>   Unfortunately, these are inside the firewall.

	http://www.sgi.com/Technology/index.html

Is outside the firewall and has similar content (click on
"Periodic Tables")

I also found some MIPS Assembly guides under Silicon Surf
(they actually are pointers to www.mips.com) for example:

	http://www.mips.com/r4400/UMan/R4000.book_5.html

Includes the R4K instruction set and much more.
(I believe Bill mentioned this)

I tried to mirror what's in our technical library, but it turns
out it is all generated from SGML by DynaWeb using gci scripts
so its too hairy to deal with. Anyway, the above is just as good.

-- 
Peace, Ariel