Linux Development

Hi all…

After a long wait, Gentoo/MIPS is on the comeback trail. Okay, I’ll stick my hand up and admit I did a bit of carnage by pulling keywords on vim-7.0 (which might’ve worked with older releases but did not work on this latest release) however we’ll soon have that cleaned up. We’re still in discussions whether to drop the stable keywords on the packages that depended on vim (probably a wise move considering the vim keywords I pulled were stable ones), or whether to promote vim to stable early (probably also fairly safe given the circumstances).

In the meantime, my builds have plodded on. Gentoo/MIPS O32 for MIPS-I little-endian is now complete, with the stage 3 due to finish uploading in 5 hours time… after which, the stage 2 for the MIPS-III little-endian port will begin its upload. Progress can be watched here if people so desire… the upload is throttled at 8KB/sec so that I have some bandwidth left-over for other tasks (it’s a 128Kbps uplink).

MIPS-IV little-endian builds are going slowly… with a snag hit when the Qube2 couldn’t download an amended patchset for binutils (basically patchset 1.1 + patches from bug #338405) because muggins forgot to copy across the envscript specifying my local GENTOO_MIRRORS.

The O2 is also happily compiling a seed stage, for what will be a round of stage builds for big-endian systems… no issues so far and stage builds will commence there in earnest shortly.

It is hoped that we will soon be offering N32 stages to compliment this release very soon. N32 will likely be the future direction for the Gentoo/MIPS port, with O32 being provided for legacy installations and for hardware unable to run 64-bit kernels reliably (or at all).

From here, the next step will be uClibc stages and installation media for the various platforms we support. This should include the newer Lemote systems which have previously enjoyed semi-official support in the past.

Hi all…

Just to let you know, there will be new stages to replace the ones I uploaded recently. Having found a solution for the issues with building on the Lemote computers, I now have MIPS-I and MIPS-III builds going simultaneously on the two Fulong systems. MIPS-IV is being handled by my much slower Qube2. One of the hold-ups was a parallel-build with gcc-4.4.4 (and I note that distcc doesn’t seem to work under Catalyst anyway).

I hope to get big-endian ports bootstrapped soon, with my O2 up and running.

Hi all…

A little note regarding the usage of the latest MIPS-I stages on Fuloong 2E… I found I had a hard-lock compiling some applications which can be possibly traced back to an issue regarding the NOP instruction on the Loongson CPU.  I understood it to only affect 2F-series systems, and also assumed latest binutils had the patch, it seems I was wrong on both those fronts.

A workaround is described on Lemote’s site… compile the fix-nop.c then use it to patch up ld and as… then builds should go smoothly. Now that I know about this issue, I can use the faster Loongson2E machines to build the stages, which means I’ll address the other issues I’ve found and roll out a new set of stages, rather than waiting for the slow Qube2 to chug its way through the build queue.

Hi all,

Well, after a long plod the stage 3 for MIPS-I little-endian systems is uploaded. I’m working on MIPS-III and MIPS-IV stages, as well as equivalents for big-endian systems.

Two things with this stage 3 tarball. First and foremost, /dev seems to be empty. I think this is most definitely a bug, and I’ll try to rectify it, but in the meantime, just merge sys-apps/makedev. That should clear everything up.

The second is that somehow dev-vcs/git got pulled in. I guess this is a happy accident since many will probably want it for fetching kernel sources. I’m undecided whether to leave it there or not… I probably should see why it got in there and fix it as that’s probably related to makedev‘s absence. I don’t see it in the profile, so it’s a mystery why it wound up in the system. I’ll do some further checks, but for the most part, it’s harmless.

I’m just rebuilding one of the Fulong2E’s with it to check it out… and as always, feedback is appreciated.

Observant viewers may notice that I’ve begun uploading some of the stage tarballs. The first of the stages built is the stage 1 tarball for MIPS-I little-endian. Stage 2 is building as I type this, hopefully by this weekend it’ll be uploaded and stage 3 will be on its way.

I’ll let you know when all the MIPS-I little-endian builds are done, that way you won’t wind up downloading a partially uploaded file. That said, should you jump the gun, you should be able to resume the download to fetch the remainder. I’ve started with MIPS-I since that’s the lowest-common-denominator … MIPS-III will be next, followed by MIPS-IV.

I plan to get onto the big-endian port shortly. SGI owners have not been forgotten, just I’ve been busy. 🙂

Well, after a long hiatus and a few battles more recently, I now have the Qube2 building O32 stages for the little-endian port of Gentoo.

N32 will probably come soon with Matt Turner throwing some Broadcom BCM91250 heavyweights at the task. I intend to keep O32 going as there’s a lot of hardware out there that cannot use N32 that people use Gentoo on, and there are also a lot of systems which still run Gentoo O32. To provide a continued operating system for these systems, I’ll continue to maintain an O32 port.

At this point… I have produced a seed stage 3 based on modern sources, and have the Qube2 busily working through the final stage 1 for MIPS1 now (at package 55 of 60). I have the occasional hiccup such as baselayout trying to install a .keep file in a mounted /proc and dying… I’ve also had the man ebuild try to call groupadd before shadow was installed.

Other than that, things are moving forward, and I hope to have new stages to you shortly.

Hi all…

I’ll put this in the handbook when I get around to updating that… but in short, those who need to be able to netboot SGI systems from a Windows host, might wish to give tftpd32 a try.  I’ve been tinkering with this TFTP server in order to load some ARM-based devices (Ka-Ro TX27s using RedBoot).  I find this server daemon is inconsistent with its loading speed when transferring files to a TX27 (sometimes speed is good; around 1MB/sec, other times it crawls at 3KB/sec), however experimenting with it in a VirtualBox VM running Windows 2000, it works flawlessly for netbooting the SGI O2 I have here.

Below is a screenshot of the settings used.  A Linux or Unix-based TFTP server would be better if that can be organised, but for those who have no option, this may be a viable alternative.

TFTPD32 Configuration, tested with an SGI O2

qube ~ # catalyst -f /home/catalyst/configs/stage1.spec 
Catalyst, version 2.0.6.906
Copyright 2003-2008 Gentoo Foundation
Copyright 2008-2009 various authors
Distributed under the GNU General Public License version 2.1

Using default Catalyst configuration file, /etc/catalyst/catalyst.conf
Setting sharedir to config file value "/usr/lib/catalyst"
Setting snapshot_cache to config file value "/home/catalyst/snapshot_cache"
Setting hash_function to config file value "crc32"
Setting storedir to config file value "/home/catalyst"
Setting portdir to config file value "/usr/portage"
Setting distdir to config file value "/hd/0/gentoo/distfiles"
Setting options to config file value "autoresume kerncache metadata_overlay pkgcache seedcache snapcache"
Autoresuming support enabled.
Kernel cache support enabled.
Package cache support enabled.
Seed cache support enabled.
Snapshot cache support enabled.
Use of metadata_overlay module for portage enabled.
Envscript support enabled.

        WARNING: No value set for key cxxflags...deleting

        WARNING: No value set for key distcc_hosts...deleting

        WARNING: No value set for key pkgcache_path...deleting

        WARNING: No value set for key portage_overlay...deleting

        WARNING: No value set for key ldflags...deleting

        WARNING: No value set for key portage_confdir...deleting
Using target: stage1
Building natively for mips
stage1 root path is /tmp/stage1root
Source path set to /home/catalyst/builds/seeds/seed-20100806.tar.bz2
Caching snapshot to /home/catalyst/snapshot_cache/20100806/
The autoresume path is /home/catalyst/tmp/default/.autoresume-stage1-mipsel1-20100806/
stage1 stage path is /home/catalyst/tmp/default/stage1-mipsel1-20100806/tmp/stage1root
Resume point detected, skipping target path setup operation...
Location of the package cache is /home/catalyst/packages/default/stage1-mipsel1-20100806/
Location of the kerncache is /home/catalyst/kerncache/default/stage1-mipsel1-20100806/
Checking for processes running in chroot and killing them.
--- Running action sequence: unpack
Referenced SEEDCACHE does not appear to be a directory, trying to untar...
No Valid Resume point detected, cleaning up...
Removing AutoResume Points: ...
Emptying directory /home/catalyst/tmp/default/.autoresume-stage1-mipsel1-20100806/
Emptying directory /home/catalyst/tmp/default/stage1-mipsel1-20100806/

Starting tar extract from /home/catalyst/builds/seeds/seed-20100806.tar.bz2
to /home/catalyst/tmp/default/stage1-mipsel1-20100806/ (This may take some time) ...

And with that… a new round of stagebuilds begins… I’ll do the initial stage builds on the Qube2 for now, so things will take some time, but I want to iron out all the issues I’ve been having and get something together that builds smoothly. I may even run it through Catalyst a second time just to make sure everything is clean. These should also include the newer tools, such as baselayout-2 and eselect.

This seed stage was mostly cross-compiled on my now dead Duron. I now have a 6-core AMD Phenom II which I also plan to set up QEMU on, for stage-building purposes… and soon will get distcc going on a few of the hosts here… so hopefully I’ll have stagebuilds going much more regularly.

It has been a long time between drinks for Gentoo/MIPS… but at last, I’ve managed to get something rolling, and hopefully I should have some stages out by the end of the year.

What took me so long? A number of packages didn’t want to compile… particularly python-2.6 and gcc-4.4. The former exhibited various compiler errors… I think I’ve got that sussed now. The latter would compile xgcc, then that binary would promptly die with an Internal Compiler Error.

I couldn’t resolve the latter due to not having anything other than MIPS hardware at home for development. So when I managed to cobble together a Duron 900MHz, I was able to use that to cross-compile a minimal environment with a C-only gcc (it wouldn’t build without USE=nocxx) and supply a version of Python from my Yeeloong.

I now have the Qube2 busy running the bootstrap script, it has self-compiled its own python-2.6 now and is working through the other base-system packages. I found the Lemote boxes seemed to exhibit an odd lock-up at specific points of the build, but the Qube2 just keeps plodding along. Ahh well, they do say “slow and steady wins the race”.

Speaking of slow and steady, the Duron 900MHz decided to keel over this morning… so I’m not sure if I’ll be able to put together a similar environment to bootstrap the big-endian port, but we’ll see. There’s money in the budget for a new 6-core AMD Phenom II system in the near future though, so by the time I get Gentoo/MIPS little-endian up and running, I should have new hardware to tackle the big-endian port with.

On other news… it seems the next Linux.conf.au is going to be here in Brisbane… shock horror I might be able to attend this one. 😉