Gentoo 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. 😉

Well, after a long hiatus that must have seemed like an eternity for some, I’m starting to dust off my old MIPS boxes and getting things back up and running again.

I’ve shifted positions, and now work at West End as a subcontractor for Jacques Electronics, and so instead of my journey starting from The Gap at 4:30AM to arrive at Laidley at 7:30AM, I jump on the bike and pedal 1.5 hours to West End. The work involves some embedded Linux development on Freescale i.MX27… and for some of my work, I’ve been using a cross-compiled Gentoo environment as a NFS-root, and on the device’s NAND flash.

This means I have a lot more time to do things. Amongst other things, this includes getting Gentoo stagebuilds back on track. One blocker to this progress has been issues compiling gcc 4.4. In short, I get an ICE (internal compiler error) whenever I try, and others have reported the same thing on their systems too. I couldn’t get around it using the compiler on the machines I have available, and my desktop computer was down with dead HDDs, so I couldn’t use that to cross-compile anything either. So the project was stuck at that point.

Fast forward to now… I had some money streaming in from the last project at Laidley. As far as I knew at the time, all that was wrong with my desktop was dead HDDs (it had 4 SCSI HDDs on an Adaptec controller). SATA had improved a great deal since I moved the machine to SCSI (at the time I was fed up with IDE drives dying), so I decided time to move to that. I also decided to upgrade my netbook computer, and my laptop. So about $350 got spent on 3 new HDDs (1 3.5″ 1TB SATA, 1 2.5″ 500GB SATA and 1 2.5″ 250GB IDE) and one PCI SATA controller (Silicon Image SiI3114-based).

The Yeeloong has an odd quirk with the new 500GB HDD I put in it, but luckily, easy enough to work around — in short the PROM doesn’t see the HDD, so I boot grub2-yeeloong off a USB flash drive, and that loads the kernel. Once the kernel is loaded, the system runs fine off the internal HDD, so it’s a minor inconvenience… and could be seen like an “ignition” key required to start the computer.

My other laptop, a P4M 2GHz took to its new HDD no problems, expanding the disk from 40GB to 250GB, the biggest I could get. My desktop however, it turned out there was more dramas to be had. The motherboard (an ASUS CUV4X-D) appears to have developed other faults, and now the machine is unworkable. Scratching around, I managed to scrounge an old Duron 900MHz CPU and motherboard, with 512MB DDR RAM… so into the case that went, along with the new PCI SATA controller and the HDD. Had all sorts of fun and games getting Windows 2000 to install onto the HDD, getting the machine to boot from the HDD, and other issues.

The booting issue was solved when I used the RAID utilities (from a Win2k install on an IDE HDD) to update the firmware. I put together a Windows 2000 Pro CD with SP4 and the RAID drivers and since then, the machine has been happily dual-booting Gentoo and Windows 2000. I also had FreeBSD on there too, but I’ve taken that off for now, might put it back later. The only issue I have is with the video card (which was from the now dead desktop), a HIS Radeon 9200SE. It works fine in 2D only, no 3D acceleration on Linux, and no acceleration at all on Win2K… I did have acceleration going there, so not sure what happened… but 2D is enough for what I do anyway.

As I type this I have successfully built a toolchain for mipsel-unknown-linux-gnu. I have a mips-unknown-linux-gnu toolchain being built, and currently I am cross-compiling (canadian-cross) a version of gcc-4.4.4 for mipsel-unknown-linux-gnu which I intend to install on my Yeeloong to get me past this blocker. I’ll do the same for mips-unknown-linux-gnu once that is done.

With new o32 stages on their way, I can then take another look at n32, and possibly n64 in the more distant future. None of the SGI machines boot properly at present, although 3 out of the 4 turn on, so that’s a start. The fourth (my Octane) I’ll have to have a closer look at, but last time I tried turning it on several months ago, it was dead as a door nail.

I don’t see myself getting on IRC anytime soon… I’m not about when most people are available to talk to me, and for non-realtime discussion, email is a more efficient medium, so I might as well stick to that. At least I have some systems back online however, and some development work will resume once I figure out what the present status is. And next financial year, I think a new desktop computer is in order. 😉