From: Joshua Kinard <kumba@gentoo.org>
To: gentoo-mips@lists.gentoo.org
Subject: Re: [gentoo-mips] n64 stages for mipsel… any interest?
Date: Sun, 14 May 2017 00:23:22 -0400 [thread overview]
Message-ID: <3796e43c-ae9a-64eb-7208-76f4a324f05c@gentoo.org> (raw)
In-Reply-To: <48972734-ee5f-c966-b03a-48f134bbcab2@longlandclan.id.au>
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>
> 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.
> 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 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.
> 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.
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.
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.
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.
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.
--
Joshua Kinard
Gentoo/MIPS
kumba@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
next prev parent reply other threads:[~2017-05-14 4:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-14 3:54 [gentoo-mips] n64 stages for mipsel… any interest? Stuart Longland
2017-05-14 4:23 ` Joshua Kinard [this message]
2017-05-14 5:56 ` Stuart Longland
2017-05-26 7:28 ` Stuart Longland
2017-06-06 13:10 ` Stuart Longland
2017-06-09 7:15 ` Stuart Longland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3796e43c-ae9a-64eb-7208-76f4a324f05c@gentoo.org \
--to=kumba@gentoo.org \
--cc=gentoo-mips@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox