On 10/16/2016 17:45, Waldemar Brodkorb wrote:
[snip]
I have 2xO2 and 2xIndy.
The modern O2:
hinv
System: IP32
Processor: 300 Mhz R5000, with FPU
Primary I-cache size: 32 Kbytes
Primary D-cache size: 32 Kbytes
Secondary cache size: 1024 Kbytes
Memory size: 128 Mbytes
Graphics: CRM, Rev C
Audio: A3 version 1
SCSI Disk: scsi(0)disk(1)
SCSI CDROM: scsi(0)cdrom(4)
This is the one you'll want to use with Linux. The 300MHz R5000's are actually
RM5261's by PMC Sierra (who bought them via their QED acquisition many years
ago). Linux refers to them as "Nevada" (CONFIG_CPU_NEVADA). You can add up to
1GB RAM, but when configuring the framebuffer (GBEFB) in the kernel, don't set
its RAM higher than 4MB (else an Oops due to a *really* old bug no one's chased
down yet).
I'm actually trying to get this netboot working so that I can re-install my O2
w/ a uClibc-ng-based rootfs. It's currently on an n32 glibc rootfs, but with
gcc's increasingly-larger compile times and glibc's bloat, that machine,
despite its 350MHz RM7000 CPU, just takes too long to do stuff (gcc is about a
~24-hour job). 64-bit PCI-X is also a little off, but 32-bit PCI should work
fine as long as the driver isn't braindead and assumes little-endian.
The classic O2:
hinv
System: IP32
Processor: 175 Mhz R10000, with FPU
Primary I-cache size: 32 Kbytes
Primary D-cache size: 32 Kbytes
Secondary cache size: 1024 Kbytes
Memory size: 128 Mbytes
Graphics: CRM, Rev C
Audio: A3 version 1
SCSI Disk: scsi(0)disk(2)
SCSI CDROM: scsi(0)cdrom(4)
So I should bootup a system on the modern O2?
OpenBSD is running 64Bit kernel and userland on O2 and I think I
remember they fixed the r10k issues somehow.
Yeah, OpenBSD solved the R10K issues, I *think*, by padding the affected
instructions out with tons of 'cache' instructions, which I think is one of the
stated solutions for dealing w/ R10K's speculative execution feature on the
non-coherent platforms (I think at the cost of a significant performance hit).
I was told once that Linux's memory design and TLB handling is too complicated
for a similar approach, but I haven't tried looking into the issue at all
lately. R12K CPUs have a hardware bit in their config register called "Delay
Speculative Dirty" (DSD) that's supposed to help mitigate the problem, but you
apparently still have to add some cache barriers before loads or stores (or
both?). I recently picked one of those up, but haven't had a chance to try it
out yet.
What are you running on the Octane? Linux 64 Bit or 32
Bit?
(n32,o32,n64 in case of 64Bit)
Octanes can only boot a 64-bit kernel (same as their IP27 cousins), due to
their firmware only supporting 64-bit ELF format. All of my SGI's run
N32/glibc-based userlands, though when I format the O2, it'll be back to O32
until I figure out how good uclibc's N32 support is. I've also got a multilib
chroot based on glibc that mixes O32, N32, and N64, but wasn't able to complete
a fresh stage build with it due to some really weird glibc bug that popped up
during the stage3 build cycle. I have to get glibc-2.24 into play and give it
another go at some point.
Best regards
Waldemar
_______________________________________________
devel mailing list
devel(a)uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
--
Joshua Kinard
Gentoo/MIPS
kumba(a)gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic