Re: Question for David Miller or anyone else about R6000 code

Re: Question for David Miller or anyone else about R6000 code

[Kevin D. Kissell]

The R10000/R12000 programs are still within SGI,
and are not supported directly by MIPS Technologies
Inc.   The MIPS/Linux kernel today does not support
the R10000 (there's a panic("CPU too expensive");
somewhere if the Processor ID for R10K is detected),
but the CPU should not be at all difficult to support in
the kernel - it was a design constraint of the R10K
that it run the same Windows NT kernel as the
R4400, so the CP0 is a pretty strict superset of 
the R4K.   The hard part of an R10K/O2 port would
be more in the drivers than in the CPU support.
The O2 went for a high-bandwidth "unified memory
architecture" design which has very little resemblence
to any other Linux platform of which I am aware.
I've seen references on this and other mailing lists
to people working on getting Linux onto the O2.
Hopefully, they will respond.

            Regards,

            Kevin K.

-----Original Message-----
From: Marc Esipovich <marc@mucom.co.il>
To: Kevin D. Kissell <kevink@mips.com>
Cc: Linux SGI <linux@cthulhu.engr.sgi.com>
Date: Monday, December 06, 1999 11:33 AM
Subject: Re: Question for David Miller or anyone else about R6000 code


>Hello,
>
> How about R10000 on O2 ? are you working on that aswell?
> Do you have or know where to get documentation of O2's hardware,
> I've opened mine up, the only thing I was able to recognize were
> two Adaptec 7880P controllers (if I recall the model number
> correctly),  could you point me to some place which has docs?
>
> Thanks,
> Marc Esipovich.
>
>--
>root is only a few clicks away...
>
>

Re: Question for David Miller or anyone else about R6000 code

[Ralf Baechle]

On Mon, Dec 06, 1999 at 12:41:08PM +0100, Kevin D. Kissell wrote:

> The R10000/R12000 programs are still within SGI,
> and are not supported directly by MIPS Technologies
> Inc.   The MIPS/Linux kernel today does not support
> the R10000 (there's a panic("CPU too expensive");
> somewhere if the Processor ID for R10K is detected),

MIPS64 has R10k support.  I didn't even try to fix it for MIPS32 because
that kernel only supports upto 512mb memory.  And as you say it was
easy to implement.

  Ralf

Question for David Miller or anyone else about R6000 code

[Kevin D. Kissell]

I tried sending this to David Miller at his SGI email
address, just in case it would work.  Of course, it
didn't.  David, if you are reading this mailing list,
I'd appreciate your comments.  And anyone else
having knowledge should feel free to respond as
well!

David:

I don't know that you are still at SGI - indeed, with
all the changes in recent months, I would be a bit
surprised if you were - but this is the last email
address I have for you.

I'm working on cleaning up and enhancing the
MIPS/Linux code to support the new families
of CPUs coming out of MIPS Technologies Inc.
In doing so, I've come across and fixed a number
of bugs, most of which I've also passed back to
Ralf Baechle for integration with the moving
target at linux.sgi.com.   But I came across 
something this morning that, while not a problem
for us, puzzles me.   In arch/mips/mm/r6000.c,
which has your name on it, there is a compiler
directive to use MIPS III instructions, and the
resulting code does indeed end up containing
64-bit (daddiu, etc.) instructions.   I've never
actually programmed an R6000, but all of the
information I have on that processor indicates
that it is a MIPS II, 32-bit design, and that those
instructions should therefore cause exceptions.

Am I mistaken, or is that directive a bug?

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

Re: Question for David Miller or anyone else about R6000 code

[Marc Esipovich]

Hello,

	How about R10000 on O2 ? are you working on that aswell?
	Do you have or know where to get documentation of O2's hardware,
	I've opened mine up, the only thing I was able to recognize were
	two Adaptec 7880P controllers (if I recall the model number
	correctly),  could you point me to some place which has docs?

	Thanks,
		Marc Esipovich.

--
root is only a few clicks away...

Re: Question for David Miller or anyone else about R6000 code

[Ralf Baechle]

On Mon, Dec 06, 1999 at 10:58:10AM +0100, Kevin D. Kissell wrote:

> I'm working on cleaning up and enhancing the
> MIPS/Linux code to support the new families
> of CPUs coming out of MIPS Technologies Inc.
> In doing so, I've come across and fixed a number
> of bugs, most of which I've also passed back to
> Ralf Baechle for integration with the moving
> target at linux.sgi.com.   But I came across 
> something this morning that, while not a problem
> for us, puzzles me.   In arch/mips/mm/r6000.c,
> which has your name on it, there is a compiler
> directive to use MIPS III instructions, and the
> resulting code does indeed end up containing
> 64-bit (daddiu, etc.) instructions.   I've never
> actually programmed an R6000, but all of the
> information I have on that processor indicates
> that it is a MIPS II, 32-bit design, and that those
> instructions should therefore cause exceptions.
> 
> Am I mistaken, or is that directive a bug?

It obviously is.  The R6000 code isn't supposed to work and given that
currently none of the Linux/MIPS hackers has a) R6000 documentation and
b) an R6000 machine an R6000 port ever happening is highly unprobable.
As the result of this I think I'm going to just burry the R6000 support
and while I'm at it also the R8000.

  Ralf

Re: Question for David Miller or anyone else about R6000 code

[William Fisher]

> 
> On Mon, Dec 06, 1999 at 10:58:10AM +0100, Kevin D. Kissell wrote:
> 
> > I'm working on cleaning up and enhancing the
> > MIPS/Linux code to support the new families
> > of CPUs coming out of MIPS Technologies Inc.
> > In doing so, I've come across and fixed a number
> > of bugs, most of which I've also passed back to
> > Ralf Baechle for integration with the moving
> > target at linux.sgi.com.   But I came across 
> > something this morning that, while not a problem
> > for us, puzzles me.   In arch/mips/mm/r6000.c,
> > which has your name on it, there is a compiler
> > directive to use MIPS III instructions, and the
> > resulting code does indeed end up containing
> > 64-bit (daddiu, etc.) instructions.   I've never
> > actually programmed an R6000, but all of the
> > information I have on that processor indicates
> > that it is a MIPS II, 32-bit design, and that those
> > instructions should therefore cause exceptions.
> > 
> > Am I mistaken, or is that directive a bug?
> 
> It obviously is.  The R6000 code isn't supposed to work and given that
> currently none of the Linux/MIPS hackers has a) R6000 documentation and
> b) an R6000 machine an R6000 port ever happening is highly unprobable.
> As the result of this I think I'm going to just burry the R6000 support
> and while I'm at it also the R8000.
> 
>   Ralf
> 
	Since the R6000 was an ECL machine produced in late 1992, just
	before the MIPS/SGI merger. There were only a few machines sold
	and the machine was designed to be a Fortran FP specialist.

	Hence the R6000 is long since dead. We still have the MIPS risc/os 5.01
	operating system source code, so if anybody has lots of free cycles
	to waste, I'm sure we can send them locore.

-- Bill

Re: Question for David Miller or anyone else about R6000 code

[William Fisher]

> 
> On Mon, Dec 06, 1999 at 10:58:10AM +0100, Kevin D. Kissell wrote:
> 
> > I'm working on cleaning up and enhancing the
> > MIPS/Linux code to support the new families
> > of CPUs coming out of MIPS Technologies Inc.
> > In doing so, I've come across and fixed a number
> > of bugs, most of which I've also passed back to
> > Ralf Baechle for integration with the moving
> > target at linux.sgi.com.   But I came across 
> > something this morning that, while not a problem
> > for us, puzzles me.   In arch/mips/mm/r6000.c,
> > which has your name on it, there is a compiler
> > directive to use MIPS III instructions, and the
> > resulting code does indeed end up containing
> > 64-bit (daddiu, etc.) instructions.   I've never
> > actually programmed an R6000, but all of the
> > information I have on that processor indicates
> > that it is a MIPS II, 32-bit design, and that those
> > instructions should therefore cause exceptions.
> > 
> > Am I mistaken, or is that directive a bug?
> 
> It obviously is.  The R6000 code isn't supposed to work and given that
> currently none of the Linux/MIPS hackers has a) R6000 documentation and
> b) an R6000 machine an R6000 port ever happening is highly unprobable.
> As the result of this I think I'm going to just burry the R6000 support
> and while I'm at it also the R8000.
> 
>   Ralf
> 
	Since the R6000 was an ECL machine produced in late 1992, just
	before the MIPS/SGI merger. There were only a few machines sold
	and the machine was designed to be a Fortran FP specialist.

	Hence the R6000 is long since dead. We still have the MIPS risc/os 5.01
	operating system source code, so if anybody has lots of free cycles
	to waste, I'm sure we can send them locore.

-- Bill

Re: Question for David Miller or anyone else about R6000 code

[Alistair Lambie]

William Fisher wrote:
> 
> >
> > On Mon, Dec 06, 1999 at 10:58:10AM +0100, Kevin D. Kissell wrote:
> >
> > > I'm working on cleaning up and enhancing the
> > > MIPS/Linux code to support the new families
> > > of CPUs coming out of MIPS Technologies Inc.
> > > In doing so, I've come across and fixed a number
> > > of bugs, most of which I've also passed back to
> > > Ralf Baechle for integration with the moving
> > > target at linux.sgi.com.   But I came across
> > > something this morning that, while not a problem
> > > for us, puzzles me.   In arch/mips/mm/r6000.c,
> > > which has your name on it, there is a compiler
> > > directive to use MIPS III instructions, and the
> > > resulting code does indeed end up containing
> > > 64-bit (daddiu, etc.) instructions.   I've never
> > > actually programmed an R6000, but all of the
> > > information I have on that processor indicates
> > > that it is a MIPS II, 32-bit design, and that those
> > > instructions should therefore cause exceptions.
> > >
> > > Am I mistaken, or is that directive a bug?
> >
> > It obviously is.  The R6000 code isn't supposed to work and given that
> > currently none of the Linux/MIPS hackers has a) R6000 documentation and
> > b) an R6000 machine an R6000 port ever happening is highly unprobable.
> > As the result of this I think I'm going to just burry the R6000 support
> > and while I'm at it also the R8000.
> >
> >   Ralf
> >
>         Since the R6000 was an ECL machine produced in late 1992, just
>         before the MIPS/SGI merger. There were only a few machines sold
>         and the machine was designed to be a Fortran FP specialist.
> 
>         Hence the R6000 is long since dead. We still have the MIPS risc/os 5.01
>         operating system source code, so if anybody has lots of free cycles
>         to waste, I'm sure we can send them locore.
> 

Don't forget CDC used the R6000 and ramped it to 90MHz.  They also got
it going in an SMP configuration with 4 processors from what I can
remember.  I guess it is possible that someone could actually want to
burn some cycles on this, although they had better have a cheap source
of power and good airconditioning :-)

Alistair

-- 
Alistair Lambie                                alambie@csd.sgi.com
SGI Global Product Support
Level 5, Cigna House,                                M/S: INZ-3780
PO Box 24 093,                                  Ph: +64-4-494 6325
40 Mercer St, Wellington,                      Fax: +64-4-494 6321
New Zealand                                 Mobile: +64-21-635 262

Re: Question for David Miller or anyone else about R6000 code

[Ralf Baechle]

On Wed, Dec 08, 1999 at 05:30:49PM +1300, Alistair Lambie wrote:

> Don't forget CDC used the R6000 and ramped it to 90MHz.  They also got
> it going in an SMP configuration with 4 processors from what I can
> remember.  I guess it is possible that someone could actually want to
> burn some cycles on this, although they had better have a cheap source
> of power and good airconditioning :-)

At one time some Linux/m68k hacker was seriously looking into porting
Linux to a 3-CPU 256mb CDC which at that time was used as
ftp.uni-erlangen.de.

As usual the largest problem was technical documentation for the machine
and the CPU; the R6k is covered very badly by the freely available
documentation.

  Ralf

Re: Question for David Miller or anyone else about R6000 code

[William J. Earl]

William Fisher writes:
...
 > 	Since the R6000 was an ECL machine produced in late 1992, just
 > 	before the MIPS/SGI merger. There were only a few machines sold
 > 	and the machine was designed to be a Fortran FP specialist.
 > 
 > 	Hence the R6000 is long since dead. We still have the MIPS risc/os 5.01
 > 	operating system source code, so if anybody has lots of free cycles
 > 	to waste, I'm sure we can send them locore.

      Actually, CDC later sold quite a few multiple-processor machines, after
MIPS was merged into SGI.  They are not very practical, however, as they
use a lot of power and are only a little faster than a 100 MHZ R4000SC.

Re: Question for David Miller or anyone else about R6000 code

[William J. Earl]

William Fisher writes:
...
 > 	Since the R6000 was an ECL machine produced in late 1992, just
 > 	before the MIPS/SGI merger. There were only a few machines sold
 > 	and the machine was designed to be a Fortran FP specialist.
 > 
 > 	Hence the R6000 is long since dead. We still have the MIPS risc/os 5.01
 > 	operating system source code, so if anybody has lots of free cycles
 > 	to waste, I'm sure we can send them locore.

      Actually, CDC later sold quite a few multiple-processor machines, after
MIPS was merged into SGI.  They are not very practical, however, as they
use a lot of power and are only a little faster than a 100 MHZ R4000SC.