R10000 SGI O2

R10000 SGI O2

[Stockli Reto]

I will give a try later to have my SGI O2 R10000 175MHz running Linux
and will report found problems and possible solutions. 

For not repeating here what has already been done:
Has anyone ever tried the same before and what are the problems to
encounter? I will most likely boot from a bootp linux server. Is there a
chance that I get a console on my O2 or do I only have a serial
connection.

Thanks for any nice introductory remarks!
Cheers,

Reto

-- 
Reto Stöckli				Bldg:   Uni Irchel  Room: 25 J53
Climate Research ETH			Phone:  +41 (0)1 635 5209
Winterthurerstrasse 190			Fax: 	+41 (0)1 362 5197
8057 Zürich 				Email:  stockli@geo.umnw.ethz.ch
Switzerland				Web:    http://www.geo.umnw.ethz.ch

Re: R10000 SGI O2

[Keith M Wesolowski]

On Tue, Feb 13, 2001 at 05:25:25PM +0100, Stockli Reto wrote:

> I will give a try later to have my SGI O2 R10000 175MHz running Linux
> and will report found problems and possible solutions. 

Well, the most serious problem is known: that architecture isn't
supported.

> For not repeating here what has already been done:
> Has anyone ever tried the same before and what are the problems to
> encounter? I will most likely boot from a bootp linux server. Is there a
> chance that I get a console on my O2 or do I only have a serial
> connection.

There is no chance whatever that you will get anything.  If you want
to have any chance at all of getting this to work I would recommend
you ask Harald for his latest patch; it provides some level of support
for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
cache-noncoherency problem as r10k I2 does, and to the best of my
knowledge nobody has ever really tried to even boot one.

Not to discourage you at all...there's just a lot of work to do.

-- 
Keith M Wesolowski			wesolows@chem.unr.edu

Re: R10000 SGI O2

[Ralf Baechle]

On Tue, Feb 13, 2001 at 07:07:16PM -0800, Keith M Wesolowski wrote:

> > For not repeating here what has already been done:
> > Has anyone ever tried the same before and what are the problems to
> > encounter? I will most likely boot from a bootp linux server. Is there a
> > chance that I get a console on my O2 or do I only have a serial
> > connection.
> 
> There is no chance whatever that you will get anything.  If you want
> to have any chance at all of getting this to work I would recommend
> you ask Harald for his latest patch; it provides some level of support
> for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> cache-noncoherency problem as r10k I2 does, and to the best of my
> knowledge nobody has ever really tried to even boot one.
> 
> Not to discourage you at all...there's just a lot of work to do.

It's really hard work to do.  R12000 O2s however should be much easier to
do; the processor feature which causes so much grief in the O2 can be
disabled there.

  Ralf

Re: R10000 SGI O2

[Stockli Reto]

Hi There

> 
> On Tue, Feb 13, 2001 at 07:07:16PM -0800, Keith M Wesolowski wrote:
> 
> > > For not repeating here what has already been done:
> > > Has anyone ever tried the same before and what are the problems to
> > > encounter? I will most likely boot from a bootp linux server. Is there a
> > > chance that I get a console on my O2 or do I only have a serial
> > > connection.
> >
> > There is no chance whatever that you will get anything.  If you want
> > to have any chance at all of getting this to work I would recommend
> > you ask Harald for his latest patch; it provides some level of support
> > for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> > cache-noncoherency problem as r10k I2 does, and to the best of my
> > knowledge nobody has ever really tried to even boot one.
> >
> > Not to discourage you at all...there's just a lot of work to do.
> 
> It's really hard work to do.  R12000 O2s however should be much easier to
> do; the processor feature which causes so much grief in the O2 can be
> disabled there.
> 
>   Ralf

Thanks Keith and Ralf for your information on running a R10000 O2 with
Linux. I knew that the video and sound HW as well as some of the
machine's graphics features were not supported by any linux drivers,
because it's even hard on SGI/Irix to find useful documentation about
this hardware! I guess this is the point why so few developers have
programmed applications that would take advantage of the very nice
capabilities of the machine.

So, I still would like to contribute something to the implementation of
Linux on SGI machines and I have this O2 standing on my desk. I have
installed and maintained some I386 based linux systems, but am not
really into fixing kernels. As I see there's no kernel that will boot
rightaway (with or without screen console). Let me know if the situation
is hopeless or if I can make a step taking a current mips-kernel (any
specific R10000-patch around there?) and start to consult R10000/ SGI O2
manuals.

It would be nice, but maybe I'm too much on the admin/user side and for
sure I am not into developing kernels. Anyway, curious I am...

Cheers,
Reto

Re: R10000 SGI O2

[Ralf Baechle]

Gruezi,

On Mon, Feb 19, 2001 at 09:49:44AM +0100, Stockli Reto wrote:

> Thanks Keith and Ralf for your information on running a R10000 O2 with
> Linux. I knew that the video and sound HW as well as some of the
> machine's graphics features were not supported by any linux drivers,
> because it's even hard on SGI/Irix to find useful documentation about
> this hardware! I guess this is the point why so few developers have
> programmed applications that would take advantage of the very nice
> capabilities of the machine.

You're mixing two completly different things.  SGI never released hardware
programming information for the O2 to the general public.  The graphics
APIs however have been published and there is a ton more good reasons to
stick with those like those APIs beying consistent beyond just the O2 and
even SGI platforms.

> So, I still would like to contribute something to the implementation of
> Linux on SGI machines and I have this O2 standing on my desk. I have
> installed and maintained some I386 based linux systems, but am not
> really into fixing kernels. As I see there's no kernel that will boot
> rightaway (with or without screen console). Let me know if the situation
> is hopeless or if I can make a step taking a current mips-kernel (any
> specific R10000-patch around there?) and start to consult R10000/ SGI O2
> manuals.

Only the mips64 kernel has R10000 support.  Anyway you want to use the
mips64 kernel as an O2 can have more memory than 32-bit kernel can handle.

> It would be nice, but maybe I'm too much on the admin/user side and for
> sure I am not into developing kernels. Anyway, curious I am...

Everybody was a newbie once at a time ...

  Ralf

Re: R10000 SGI O2

[Soren S. Jorvang]

On Fri, Feb 16, 2001 at 05:59:02PM -0800, Ralf Baechle wrote:
> > for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> > cache-noncoherency problem as r10k I2 does, and to the best of my
> > knowledge nobody has ever really tried to even boot one.
> > 
> > Not to discourage you at all...there's just a lot of work to do.
> 
> It's really hard work to do.  R12000 O2s however should be much easier to
> do; the processor feature which causes so much grief in the O2 can be
> disabled there.

Unfortunately, noone I have talked to seems to know how
specifically to turn off speculative writes..

Does anyone on this list happen to know?


-- 
Soren

Re: R10000 SGI O2

[Ralf Baechle]

On Thu, Feb 22, 2001 at 04:23:58AM +0100, Soren S. Jorvang wrote:

> > > for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> > > cache-noncoherency problem as r10k I2 does, and to the best of my
> > > knowledge nobody has ever really tried to even boot one.
> > > 
> > > Not to discourage you at all...there's just a lot of work to do.
> > 
> > It's really hard work to do.  R12000 O2s however should be much easier to
> > do; the processor feature which causes so much grief in the O2 can be
> > disabled there.
> 
> Unfortunately, noone I have talked to seems to know how
> specifically to turn off speculative writes..

> 
> Does anyone on this list happen to know?

RTFM ;-)

B.2 DSD (Delay Speculative Dirty)

  The Boot Mode bit 24 corresponds to the Config register[24] bit and this
  controls DSD during kernel and supervisor modes. However, the DSD mode can
  also be enabled in the user mode by setting the Status register[24]
  bit. Config register[24] is read-only and can be set only at boot time. If
  the DSD mode is set -

  a) R12000 will not set the Dirty bit for a secondary cache block until the
     store instruction is the oldest in the Active List and is about to be
     executed. (An interrupt could cause a case where the dirty bit is set
     (store is no longer speculative), but the store does not immediately
     graduate. We believe this case should not cause any problem. This mode
     does prevent speculative stores from setting the dirty bit.

  b) This mode will have slightly lower performance due to the delay in the
     setting of the Dirty bit. This delay will occur just once per block
     refill from main memory, when it is necessary to set the dirty
     bit. Setting the bit requires about ten cycles; but usually the
     processor will continue to overlap execution of other instructions.
     Once a block becomes dirty in secondary cache, this mode has no
     performance effect.

  c) In this mode, a miss in secondary cache, due to a store instruction
     which is not already the oldest in the pipeline, will cause a refill to
     the clean exclusive state. A hit to a shared line will immediately
     cause an upgrade to clean exclusive . Thus, bus operations (which are
     relatively slow) will still begin speculatively. Independent of the DSD
     mode, R12000 will delay a cached, non-coherent load until it is the
     oldest instruction. This change is implemented because a speculative
     load accessing an unmapped xkphys address as cached, non-coherent might
     bring data into the secondary cache without the proper coherency
     checks. R12000 is doing no changes to prevent it from speculatively
     refilling cache lines in shared or clean states except the xkphys case
     described above.

So as you see the details are actually a bit more complicated than just
disabling speculative stores; the actual problem are dirty lines which might
be written back to memory on an O2 or Indigo 2 R10000.  DSD doesn't help
with speculative loads but these are easier to handle.

  Ralf

Re: R10000 SGI O2

[Soren S. Jorvang]

On Fri, Feb 23, 2001 at 01:04:23AM +0100, Ralf Baechle wrote:
> > Does anyone on this list happen to know?
> 
> RTFM ;-)
> 
> B.2 DSD (Delay Speculative Dirty)

Wow, actual R12K documentation!

Is that freely available somewhere? Maybe I just didn't look
hard enough, but it's not very easy to find at least..


-- 
Soren

Re: R10000 SGI O2

[Ralf Baechle]

On Fri, Feb 23, 2001 at 01:11:08AM +0100, Soren S. Jorvang wrote:

> > > Does anyone on this list happen to know?
> > 
> > RTFM ;-)
> > 
> > B.2 DSD (Delay Speculative Dirty)
> 
> Wow, actual R12K documentation!
> 
> Is that freely available somewhere? Maybe I just didn't look
> hard enough, but it's not very easy to find at least..

http://www.nec.com

The manual isn't exactly great so they don't tell you that the values in
c0_prid did change also and there are more inaccuracies.

  Ralf