From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6EF1D139694 for ; Sun, 14 May 2017 05:56:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C455DE0D24; Sun, 14 May 2017 05:56:53 +0000 (UTC) Received: from atomos.longlandclan.id.au (atomos.longlandclan.id.au [IPv6:2001:44b8:21ac:7000::1]) by pigeon.gentoo.org (Postfix) with ESMTP id 00D81E0D24 for ; Sun, 14 May 2017 05:56:52 +0000 (UTC) Received: from [IPv6:2001:44b8:21ac:7053:65::f3] (unknown [IPv6:2001:44b8:21ac:7053:65::f3]) by atomos.longlandclan.id.au (Postfix) with ESMTPSA id 8C70B208B238 for ; Sun, 14 May 2017 15:56:50 +1000 (EST) Subject: =?UTF-8?Q?Re:_[gentoo-mips]_n64_stages_for_mipsel=e2=80=a6_any_inte?= =?UTF-8?Q?rest=3f?= To: gentoo-mips@lists.gentoo.org References: <48972734-ee5f-c966-b03a-48f134bbcab2@longlandclan.id.au> <3796e43c-ae9a-64eb-7208-76f4a324f05c@gentoo.org> From: Stuart Longland Openpgp: id=BCA11879F4F93BE3DB0DEE72F954BBBB7948D546; url=https://stuartl.longlandclan.id.au/key.asc Message-ID: Date: Sun, 14 May 2017 15:56:38 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <3796e43c-ae9a-64eb-7208-76f4a324f05c@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ChepoMjcbHcjV6m8sKricfQejN6egHEie" X-Archives-Salt: da167239-63cf-488f-ac29-4e805d010438 X-Archives-Hash: 2e6b4bd9c332d0cf4317aebcbd141636 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ChepoMjcbHcjV6m8sKricfQejN6egHEie Content-Type: multipart/mixed; boundary="7A31IbwGtbTXQfbxp4MNtJrpHptt2BC8l"; protected-headers="v1" From: Stuart Longland To: gentoo-mips@lists.gentoo.org Message-ID: Subject: =?UTF-8?Q?Re:_[gentoo-mips]_n64_stages_for_mipsel=e2=80=a6_any_inte?= =?UTF-8?Q?rest=3f?= References: <48972734-ee5f-c966-b03a-48f134bbcab2@longlandclan.id.au> <3796e43c-ae9a-64eb-7208-76f4a324f05c@gentoo.org> In-Reply-To: <3796e43c-ae9a-64eb-7208-76f4a324f05c@gentoo.org> --7A31IbwGtbTXQfbxp4MNtJrpHptt2BC8l Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (usin= g >> 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, i= ts >> performance is a little, lack-lustre. >=20 > I'm actually surprised FF even compiles on mips these days. How long d= id 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 mo= re than > a few grains of salt Not sure, last time I tried it was on n32=E2=80=A6 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=E2=80=A6 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 o= 32 >> has. I did take OpenBSD for a spin on this machine (they use n64), an= d >> it seemed snappy enough, so we'll try Linux again. >=20 > I've not tried n64 in a *long* time. I do have multilib stages availab= le for > big-endian that could theoretically be picked apart to act as a seed st= age for > pure n64, but my Octane takes ~2+ weeks to build the current batch of s= tages > that I've tried to run to completion. About to try and kickstart anoth= er > 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=E2=80=A6 and the end result was slower than the Qube II and h= ad 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=E2=80=A6 it supposedly is supported by QEMU, I suspec= t 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 t= he >> stages with. Catalyst is building the first stage1 as I type this. >> >> I suspect this will take a fortnight or so=E2=80=A6 I have contemplati= ng >> resurrecting the old Qube II for this, but it can't compete on RAM, an= d >> I haven't yet built the binaries with the NOP fix flag for them to run= >> on Loongson. >=20 > 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+ hou= rs 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 re= sponsive > they are. I have contemplated musl=E2=80=A6 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 bui= ld. 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. (Al= so >> have a IP28 and IP30, but neither are operational AFAIK. They do make= >> *great* door-stops however.) >=20 > 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 ev= ery > three months, and usually get ~90% complete and it's the final stage se= t 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 platform= s (I > literally just got a 4.11 kernel cobbled together a few minutes ago, af= ter Ralf > updated lmo git earlier tonight): >=20 > # 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 >=20 > Still has many of the old bugs, such as the DMA issues w/ >2GB memory a= nd all, > but I've got some understanding of the underlying issue, just no time t= o 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"=E2=80=A6 175MHz r10k, and it had a power supply part n= umber 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 tonigh= t, seems > to boot fine and isn't hung up (literally) by the NUMA bug like the Ony= x2 is. >=20 > 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 pro= bably > 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 tha= t > platform. uclibc-ng code executes much faster. I wish I had my musl c= hroot > still, as that libc is even quicker than uclibc-ng. >=20 > 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 w= asn'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. --=20 Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. --7A31IbwGtbTXQfbxp4MNtJrpHptt2BC8l-- --ChepoMjcbHcjV6m8sKricfQejN6egHEie Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvKEYefT5O+PbDe5y+VS7u3lI1UYFAlkX8ZsACgkQ+VS7u3lI 1Ubs4Q/+OMUGGI+OK134Grc8aDG5qEpd/NfYk+9hnHnZnAVYbOr1sLK332rFn9NA oXHgmWlA+xaT3MykNzki1UlT01Z9gYBVI2RM0QTN2Y1eiiUVDMb6syqupaZfp+vu D4v2pZWW3t9T8xowiVtNY3TkdhdfU4sCZTe8mwH8FeTqmRZn+f71ZPoMgSiMqwYi 5Barint+6MrAhGjqKIv4krgbOnhYJyCyncOEQ9ImS8iYT7vOdf/O3NcPEDBpY+tU 2MvWVgVZtnvo6otjgC+1DKyuI463FQi4xP/D6jQfMb7JIcXbgLBhxQ1G4xAKVo5p 9ONRrzsuLBC/q+qPn2yJoObkwZRiaZQO63sQD+7sICr8a7IarxIJ8b/PH7w4Ga0X uvIwFCVId8xUJ2CWKa1yGULApTXDaXXb5NPkZpsU0fBctDiX15w9tA1di/eu1Tfq sXs4PjcDU1YVQBhIg3jaEAiatNoQe3GBVKav3lgeQ97hN/Lo+OfRG1Co/GEtBAEz YG1hPqXQchj4GhmJAvSeYHkhbBqmyT6ahqERpYOibq7nWU8mzXw6zKJ3WE5k6BsW rkjC7sn+FDLy0kjq33Z6odQAjTrxMBQ8pJFb7U8tbwzIFOZa+L3TGSxVAoXd3SBC XzfPAL7TIaT1vYGMndAU4cVk1VrDdsuffnxrR1tmfwV3O4AdoDY= =xRdj -----END PGP SIGNATURE----- --ChepoMjcbHcjV6m8sKricfQejN6egHEie--