Mailing List Archive

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

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.

On 14/05/17 15:56, Stuart Longland wrote:
> 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).

Well, a progress update… I have stage 1 and 2 tarballs built. Yes,
that's after nearly a fortnight of compiling… with me putting the build
host into hibernate mode since the machine emulates a vacuum cleaner in
more ways than one!

It has just started the stage 3, then coughed up the following:
> Total: 30 packages (28 new, 2 reinstalls), Size of downloads: 8974 KiB
>
> * Error: circular dependencies:
>
> (sys-libs/libcap-2.25:0/0::gentoo, ebuild scheduled for merge) depends on
> (virtual/pam-0-r1:0/0::gentoo, ebuild scheduled for merge) (buildtime)
> (sys-libs/pam-1.3.0:0/0::gentoo, ebuild scheduled for merge) (runtime)
> (sys-libs/libcap-2.25:0/0::gentoo, ebuild scheduled for merge) (buildtime)
>
> It might be possible to break this cycle
> by applying the following change:
> - sys-libs/pam-1.3.0 (Change USE: -filecaps)
>
> Note that this change can be reverted, once the package has been installed.
>
> !!! catalyst: run script failed.
>
>
> Traceback (most recent call last):
> File "modules/generic_stage_target.py", line 1244, in run_local
> "run script failed.",env=self.env)
> File "/usr/lib64/catalyst/modules/catalyst_support.py", line 541, in cmd
> raise CatalystError,myexc
> CatalystError
> None
>
> !!! catalyst: Stage build aborting due to error.

Not sure if anyone else doing stage builds has struck that (haven't seen
it on x86 and AMD64). I've just re-started Catalyst, hit ^Z at the
appropriate point and chrooted in myself to temporarily merge
sys-libs/pam (with USE=-filecaps as suggested) to see if I can work it
past that first blocker.

(You'd think portage would be smart enough to figure this out itself?
Ahh well.)

Seems strange though… maybe something is up with the n64 profiles, or
maybe something got missed at stage 2. If that's all that goes wrong
though, I should have shiny new experimental n64 little-endian stages
for people in a week or so.

I might also see what's up with SMP support on this VM so I can throw a
bit more CPU muscle at the problem. Seems a waste to have 5 host CPU
cores doing practically nothing and one getting flogged by a VM when the
same host will churn out x86 and AMD64 stages within a day.
--
Stuart Longland (aka Redhatter, VK4MSL)

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

On 14/05/17 13:54, Stuart Longland wrote:
> 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.
>
> 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.

Well, after much compiling with a slow QEMU VM… here's the first batch.

http://www.longlandclan.id.au/~stuartl/gentoo/mips/n64/

I have not yet tried these out, *at all*, this is just the raw output
from Catalyst. I've simply thrown them up here with GnuPG signatures,
and will be trying them out sometime this weekend on my Yeeloong, which
is presently running OpenBSD/loongson.

These *should* work on Loongson 2E/2F, and anything else that is at
least MIPS-III ISA.

I have since found out that they will *NOT* work on MIPS64r6 (i.e. I6400
on QEMU) straight-up: but *should* be able to run on such hardware (this
is not tested yet) if you do the following:

- enable MIPS64r2 emulation by compiling the kernel with
CONFIG_MIPSR2_TO_R6_EMULATOR specifying the `mipsr2emu=1` kernel argument
- specifying the `nofpu=1` kernel argument to use the in-kernel software FPU

Otherwise you'll get the kernel dying with the message runaway loop
modprobe binfmt-464c (ask how I know… thanks to Maciej Rozycki for
guiding me on that). That's another avenue of testing I'll be doing.

As mentioned, if there's interest, I can have a crack at doing some
big-endian ones too for you SGI users out there, although given the
additional memory footprint of n64 over n32 and smaller RAM sizes of
such machines, n32 might be the better target.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

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

On 06/06/17 23:10, Stuart Longland wrote:
> Well, after much compiling with a slow QEMU VM… here's the first batch.
>
> http://www.longlandclan.id.au/~stuartl/gentoo/mips/n64/
>
> I have not yet tried these out, *at all*, this is just the raw output
> from Catalyst. I've simply thrown them up here with GnuPG signatures,
> and will be trying them out sometime this weekend on my Yeeloong, which
> is presently running OpenBSD/loongson.

An update, the stages work. I have my Yeeloong running n64 now, and it
is *more* responsive than the QEMU VM is. n32 is still theoretically
going to be faster, but since not much software handles n32 well (and
x32 on AMD64 has the same problems).

I haven't hit any major issues, although I think sometimes I tickle the
CPU the wrong way and that causes a system hang: possibly a kernel
issue. Presently, I am re-building my desktop environment, I have X
working (fbdev; siliconmotion driver segfaults) and so now it's a case
of building up everything else.

Also, I have packaged up a kernel and disk image using these stages that
may be useful for people to try out Gentoo/MIPS n64.

Might be handy for other devs to try out their packages on MIPS, just
create a new disk image and mount it as `hdb`, partition and format it,
unpack an official stage3, copy /lib/modules and /lib/firmware over,
then shut it down and use the new image in place of `hda`, the VM should
boot that new stage.
--
Stuart Longland (aka Redhatter, VK4MSL)

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