* [gentoo-mips] n64 stages for mipsel… any interest? @ 2017-05-14 3:54 Stuart Longland 2017-05-14 4:23 ` Joshua Kinard 2017-06-06 13:10 ` Stuart Longland 0 siblings, 2 replies; 6+ messages in thread From: Stuart Longland @ 2017-05-14 3:54 UTC (permalink / raw To: gentoo-mips 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. 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 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. 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.) Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-mips] n64 stages for mipsel… any interest? 2017-05-14 3:54 [gentoo-mips] n64 stages for mipsel… any interest? Stuart Longland @ 2017-05-14 4:23 ` Joshua Kinard 2017-05-14 5:56 ` Stuart Longland 2017-06-06 13:10 ` Stuart Longland 1 sibling, 1 reply; 6+ messages in thread From: Joshua Kinard @ 2017-05-14 4:23 UTC (permalink / raw To: gentoo-mips 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-mips] n64 stages for mipsel… any interest? 2017-05-14 4:23 ` Joshua Kinard @ 2017-05-14 5:56 ` Stuart Longland 2017-05-26 7:28 ` Stuart Longland 0 siblings, 1 reply; 6+ messages in thread From: Stuart Longland @ 2017-05-14 5:56 UTC (permalink / raw To: gentoo-mips [-- Attachment #1.1: Type: text/plain, Size: 8231 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-mips] n64 stages for mipsel… any interest? 2017-05-14 5:56 ` Stuart Longland @ 2017-05-26 7:28 ` Stuart Longland 0 siblings, 0 replies; 6+ messages in thread From: Stuart Longland @ 2017-05-26 7:28 UTC (permalink / raw To: gentoo-mips [-- Attachment #1.1: Type: text/plain, Size: 2936 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 321 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-mips] n64 stages for mipsel… any interest? 2017-05-14 3:54 [gentoo-mips] n64 stages for mipsel… any interest? Stuart Longland 2017-05-14 4:23 ` Joshua Kinard @ 2017-06-06 13:10 ` Stuart Longland 2017-06-09 7:15 ` Stuart Longland 1 sibling, 1 reply; 6+ messages in thread From: Stuart Longland @ 2017-06-06 13:10 UTC (permalink / raw To: gentoo-mips 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-mips] n64 stages for mipsel… any interest? 2017-06-06 13:10 ` Stuart Longland @ 2017-06-09 7:15 ` Stuart Longland 0 siblings, 0 replies; 6+ messages in thread From: Stuart Longland @ 2017-06-09 7:15 UTC (permalink / raw To: gentoo-mips [-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --] 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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-09 7:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-14 3:54 [gentoo-mips] n64 stages for mipsel… any interest? Stuart Longland 2017-05-14 4:23 ` Joshua Kinard 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox