Re: [gentoo-mips] Re: What kind of MIPS hardware do we have? (Looking to restart Gentoo/MIPS, need info)

[Manuel Lauss <mano@roarinelk.homelinux.net>]

On Sat, Jul 10, 2010 at 11:13:04PM -0400, Matt Turner wrote:
> On Thu, Jul 8, 2010 at 12:22 PM, Matt Turner <mattst88@gmail.com> wrote:
> > Hi,
> > I'm going to be working on Gentoo/MIPS. I'm planning to provide N32
> > stages, and I want to know what kind of MIPS hardware people have to
> > run Gentoo. With this info, I should be able to better prioritize the
> > tasks.
> >
> > So please reply with what kind of hardware you've got.
> >
> > Thanks!
> > Matt
> 
> Thanks everybody for your responses.
> 
> A bit of background: MIPS has 3 ABIs: o32, n32, n64. o32 is the common
> denominator, but is pretty inefficient. See [1]. As I suspected, all
> the hardware people care about can use the n32 ABI, which is quite a
> bit better.
> 
> To summarize the hardware collection
>  - 5 MIPS III/Loongson little-endian STMicroelectronics systems (Lemote, Gdium)
>  - 11 MIPS IV big-endian SGI systems
>  - 3 MIPS IV little-endian Cobalt systems
>  - 2 MIPS64 selectable-endian Broadcom systems

I have some little-endian MIPS32 hardware which runs latest Gentoo.


> I've got a working n32 big-endian installation, and am preparing an
> n32 little-endian installation at the moment. Once these are set up,
> I'll start preparing some n32 stages.

> I think first priority should be mips4 big-endian. From there, I don't
> know whether I should build a mips4-le stage for cobalt systems, or a
> mips3-le stage that would work for cobalt and Loongson. Do we know of
> any plain MIPS III little-endian hardware?

I believe all the small MIPS32-based routers which run OpenWRT qualify.
Hoever I get the impression you want to focus on the "large" SGI
and 64bit Broadcom systems?

 
> Also, the MIPS port is going to be pretty unmaintainable until we can
> kill off ~mips from ACCEPT_KEYWORDS. Currently, attempting to upgrade
> almost anything causes something to break.

In my experience, lots of packages have problems with GCC-4.4 (removal
of the "h" asm constraint), and above all, the toolchain itself is
pretty problematic:  Lots of linker errors with large libraries (e.g.
xulrunner, qt-webkit, gcj, ...)


Manuel