Hi Joshua, Joshua Kinard wrote, > 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).
Thanks for the hints. > 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. You don't like cross-compiling, right? uClibc-ng seems not only be interesting for embedded devices, but also for classic old unix hardware :) > > 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. Thanks for your very detailed answer. > > 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. I tested n32 support on my Lemote Yeelong, so you should at least be able to boot. A longer time ago I had Xorg and Firefox running on the book. Firefox only support n32. The Lemote has a page size of 16k, so it showed some interesting bugs in uClibc/uClibc-ng in the past. best regards Waldemar _______________________________________________ devel mailing list [email protected] http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
