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
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Reply via email to