Re: [gentoo-mips] n64 stages for mipsel… any interest?

[Stuart Longland]

On 14/05/17 14:23, Joshua Kinard wrote:
> On 05/13/2017 23:54, Stuart Longland wrote:
>> Hi all,
>>
>> I've decided to dust off the old Lemote Yeeloong that I have kicking
>> around for use as a throw-around netbook for on-the-road use.
>>
>> The aim is to have a machine that can do some basic web browsing (using
>> a decent browser, dillo won't cut it), image editing, and maybe some
>> amateur radio stuff (yes, done PSK31 with this beast before, operating
>> as VK4MM, so it does work).
>>
>> I've found though that Firefox won't build on n32 (build system
>> misbehaves, it does the same on AMD64 x32 too), and while o32 works, its
>> performance is a little, lack-lustre.
>
> I'm actually surprised FF even compiles on mips these days.  How long did it
> take to do an o32 build?  The performance hit might not be a mips-only thing,
> though, if one were to take the Internet's criticism of Mozilla with more than
> a few grains of salt </smirk>

Not sure, last time I tried it was on n32… and I recall it failed early.
 Haven't tried it on o32 since I was last maintaining Gentoo/MIPS.

I did try building Chromium though… it didn't get anywhere either, *and*
I had to force it because it didn't like only having 1GB RAM.

>> Thus as part of this, I am bootstrapping some n64 stages as an
>> experiment.  n64 of course isn't as fast as n32, there's a memory
>> consumption hit, but at least it doesn't suffer the limitations that o32
>> has.  I did take OpenBSD for a spin on this machine (they use n64), and
>> it seemed snappy enough, so we'll try Linux again.
>
> I've not tried n64 in a *long* time.  I do have multilib stages available for
> big-endian that could theoretically be picked apart to act as a seed stage for
> pure n64, but my Octane takes ~2+ weeks to build the current batch of stages
> that I've tried to run to completion.  About to try and kickstart another
> attempt, if 4.11 plays nice.

Yeah, years ago I tried QEMU, at the time best I could do was a P4
1.9GHz host… and the end result was slower than the Qube II and had
about as much RAM.

Now, well it probably won't win a match against Ilya's O2k, and the VM
really does feel sluggish, but it is at least running.  I can throw up
to 2GB RAM at the problem.

Sadly, can't do SMP… it supposedly is supported by QEMU, I suspect
there's a kernel issue there.  So one emulated mips64r2 CPU, 2GB RAM.
It cost me nothing, so I can't complain. :-)

>> I have cross-compiled a n64 environment from AMD64, and so far, I have
>> set up QEMU to run a mips64r2 little-endian VM with 2GB RAM to build the
>> stages with.  Catalyst is building the first stage1 as I type this.
>>
>> I suspect this will take a fortnight or so… I have contemplating
>> resurrecting the old Qube II for this, but it can't compete on RAM, and
>> I haven't yet built the binaries with the NOP fix flag for them to run
>> on Loongson.
>
> gcc-6 build time is brutal.  I mean the kind of stuff you terrify small
> children with to make them eat their vegetables.  Octane takes ~16+ hours with
> 2x 600MHz CPUs.  Anything slower is going to drastically ramp that time up.  I
> haven't had time to try gcc-7.1 yet.

I just tried, and failed, to build gcc-6.3.0 on n64.  It gets to stage 3
then the build system fails with a bootstrap error.  gcc-5.4.0-r3 works
though, so that's what I'm using for this (gcc-6.0.0 and later are
hard-masked).

> I wouldn't even bother with the cobalts at this point, at least as far as
> self-hosting the build system and all.  Those systems nowadays are more targets
> for embedded stuff, with a faster host machine running the builds.  I'd love to
> get mipsel-uclibc-ng or mipsel-musl stages running on one to see how responsive
> they are.

I have contemplated musl… I don't know if it supports n32 or n64 ABI.  I
read somewhere there is support for n64, but never got a toolchain to build.

I'm not sure what the status of uClibc is, it doesn't look well
maintained these days.

>> If I get some stages built, is there any interest in the community?  I'm
>> willing to throw them up somewhere where they can be mirrored (I can
>> host here, but my uplink is ~1Mbps) and made accessible to all.
>>
>> I can also do mips (big-endian) builds if there is sufficient interest,
>> I still have an r4k6 Indy and rm5k2 O2 that can test such builds.  (Also
>> have a IP28 and IP30, but neither are operational AFAIK.  They do make
>> *great* door-stops however.)
>
> There is always interest.  The last set of stages I actually put on the mirrors
> for big-endian is a year old, so I need to start on newer sets and hope there
> aren't any build-breakers hiding in the tree.  I've tried stage-runs every
> three months, and usually get ~90% complete and it's the final stage set that
> burns me.

Well, as I say, once I get them built, I can throw them up here and
those who are interested can mirror them.  (Maybe if doing it on Gentoo
mirrors, we have a 'contrib' section for such builds.  That way, it's
known that the builds came from "outside".)

> IP30 definitely works, and is still the most stable of the SGI platforms (I
> literally just got a 4.11 kernel cobbled together a few minutes ago, after Ralf
> updated lmo git earlier tonight):
>
> # uname -a
> Linux dol-guldur 4.11.0-mipsgit-20170513 #2 SMP Sun May 14 00:06:14 EDT 2017
> mips64 R14000 V2.4 FPU V0.0 SGI Octane GNU/Linux
>
> Still has many of the old bugs, such as the DMA issues w/ >2GB memory and all,
> but I've got some understanding of the underlying issue, just no time to put
> something together that solves the bug.

That's good to know.  I think mine is a hardware issue.  Noticed it had
sucked in lots of dust, so attacked it with a vacuum cleaner.

Big mistake.  It never booted after that.  (Not that it was working
perfectly beforehand.)

Mine was "special"… 175MHz r10k, and it had a power supply part number
that the Linux kernel didn't recognise, so I had to manually patch it to
get things working properly.  The IP28 I have is better specced.

> I have two IP27 machines now, an Onyx2 that exposes a really difficult NUMA bug
> somewhere in the kernel, and a more recent Origin 200 that as of tonight, seems
> to boot fine and isn't hung up (literally) by the NUMA bug like the Onyx2 is.
>
> I haven't tried IP28 in several versions.  I last tried to boot it with an
> experimental netboot image in 4.4.x, and was able to poke around the
> filesystem, but any significant disk activity knocks it right over.  I suspect
> work is needed to chase down more speculative execution issues.

You didn't slaughter the chicken right. :-)

In my case, the neighbours would object if I started slaughtering their
chooks.  Those things were always flaky, even under IRIX.

> IP32 should still work, but I haven't booted that in a while.  I am probably
> going to reload my IP32 with a uclibc-ng-based userland at some point, as the
> gcc-6 build times under a glibc userland would take way too long on that
> platform.  uclibc-ng code executes much faster.  I wish I had my musl chroot
> still, as that libc is even quicker than uclibc-ng.
>
> No idea on IP22.  My Indy's RTC is dead, and I haven't dared to attempt
> soldering a replacement battery into it yet.

Likewise, it's a case of dig up what the MAC address should be, and
start punching the detail back in again.  About the only incentive for
messing with it is it has double the RAM of the O2 here.

musl is definitely worth investigating further.  glibc really does get
too bloated for systems with <512MB RAM.

> In any event, I can probably stitch together a semi-usable netboot for you if
> you want to try and resurrect the IP30.  The last time I tried one, I wasn't
> able to get NFS support added into the userland side because uclibc-ng has
> issues with libtirpc, which is required for rpcbind and friends.

Yeah, no rush on IP30.  I suspect the only "boot" my IP30 needs is a
sturdy steel-capped one.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.