Subject: R10000 SGI O2

From: Stockli Reto <[email-masked]>
Date: Tue, 13 Feb 2001 17:25:25 +0100

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:  [email-masked]
Switzerland				Web:    http://www.geo.umnw.ethz.ch

---

From: Keith M Wesolowski <[email-masked]>
Date: Tue, 13 Feb 2001 19:07:16 -0800

> and will report found problems and possible solutions. 

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

> chance that I get a console on my O2 or do I only have a serial

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			[email-masked]

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 16 Feb 2001 17:59:02 -0800

> 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

---

From: Stockli Reto <[email-masked]>
Date: Mon, 19 Feb 2001 09:49:44 +0100

Hi There

> do; the processor feature which causes so much grief in the O2 can be

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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 21 Feb 2001 07:12:09 +0100

Gruezi,

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

> specific R10000-patch around there?) and start to consult R10000/ SGI O2

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.

> sure I am not into developing kernels. Anyway, curious I am...

Everybody was a newbie once at a time ...

  Ralf

---

From: "Soren S. Jorvang" <[email-masked]>
Date: Thu, 22 Feb 2001 04:23:58 +0100

> do; the processor feature which causes so much grief in the O2 can be

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

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 23 Feb 2001 01:04:23 +0100

> 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

---

From: "Soren S. Jorvang" <[email-masked]>
Date: Fri, 23 Feb 2001 01:11:08 +0100

> 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

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 23 Feb 2001 02:08:17 +0100

> 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