> > Log message:
> > Handle unknown processor types as r5k family on O2, and r10k family
> > otherwise. This will get a chance for r16k cpus to get configured
> > correctly.
>
> Hi Miod,
>
> In this case, it's probably a good idea to retell a rumor told to me by
> an SGI employee a number of years ago.
>
> As you know, the O2 supports the R5000, R7000, R10000 and R12000
> families of CPU modules. I have two somewhat odd/rare O2's here; one
> has a 300MHz R5000 ("RM5200" a.k.a. "RM5271") and the other has a
> 400MHz R12000.
>
> The original 350Mhz R7000 CPU module for the O2 was very buggy, and I
> believe it did not have L3 cache. From what I was told from folks at
> SGI, the only reason why the 300MHz RM5200 was created, was to support
> an "existing customer" running proprietary binaries. A hint was given
> that said customer was actually the US government/military, and they had
> trouble with the R7000 and later processors with some of their apps.
>
> I never found out the exact problems caused by the R7000 and later
> processors trying to run binaries compiled for the original R5000. As
> far as I know, there is no errata about the issues due to the source
> (US gov/mil signal processing apps), but the problems were significant
> enough to force the creation of the RM5200, even though the road map
> for the R5000 series had supposedly ended.
>
> I've got not way to prove if what I was told by the SGI employee is
> bullshit or not. It might only be a pointless rumor, but who knows.
>
> Unless we're going to create an IRIX compatibility layer, the issue of
> supporting existing IRIX binaries, and the unstated troubles caused by
> them, probably won't bother us.
>
> The decision to treat unknown processors on the O2 as R5000 is most
> likely sound, but then again, it *might* come back to bite us.
That particular change was in the area which decides which cache
handling routines to use.
At the moment, the OpenBSD codebase has two sets of cache routines: one
set for R10k and compatible processors, and one set for R5k and
compatible processors (which really handles anything from R4600 to
RM7000, silicon bugs permitting, including L3 cache on R7000
processors).
O2 systems with RM5200 or R7000 processors get their processor
identified correctly, and are known to work (although I can't confirm
R7000 based O2 still work nowadays, they used to and I don't see
anything causing them to stop work in the last few years).
The rationale for this change is that high end (IP27/IP35) design exist
with R16k processors, and as long as we don't know how the R16k
processor advertizes itself, it will be an ``unrecognized'' processor.
Before that change, IP27/IP35 systems with R16k would have been assigned
the R5k-compatible cache routine, and bad things would happen. After
that change, they will use the proper R10k-compatible cache routines.
O2 which do not have explicitely identified R10k or R12k processors will
continue to pick the R5k cache code. This was already the case before
that change, and there is nothing wrong with this.
Miod
