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@uclibc-ng.org > http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel > -- Joshua Kinard Gentoo/MIPS ku...@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 _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
