Redhatter’s Web Blog

Well, it’s that time of the year again, and I for one will be going bush like I normally do between Christmas day and the new year.

As far as Gentoo/MIPS is concerned, I’ve still got to get around to rebuilding my Qube2… I’ve tested my MIPS1 builds and everything seems to work, but I’ve been slack on my MIPS4 builds.  That said… the delays in this release seem to be Gentoo-wide, as everyone seems to have been caught on-the-hop.

From this Friday morning (before 10:00AM UTC+10) until Boxing day, I’ll be away from home, sporadically online via PSTN dialup to check for emails.

I’ll have my Qube2 and one of the Lemote boxes with me, so I’ll be able to do some package testing at least, as well as work on a LiveUSB image for the Lemote systems.

After boxing day, I’ll be in Gibraltar Ranges National Park, on the Gwyder Highway, halfway between Glen Innes and Grafton.  No mobile phone reception or phone services of any kind there… so if you need me for something please get in touch before then, or it’ll have to wait until I get back in the new year.  And no, I won’t be bringing any desktop or laptop computers with me.

This year has been very trying on my patience.  The stress levels have been quite high, and I’ve been quite apathetic in regards to Gentoo’s issues as a result.  I’m hoping 2008 will be a better year — for all of us.

I had a bit of a crazy idea today. Some would think I had a little too much spare time on my hands … but maybe there’s a point to this insanity.

Many of us have old computers laying about. Now, “old” is a subjective term. As goes the Weird Al song, “All About the Pentiums”…

You say you’ve had your PC for over a week?
Throw it away man — it’s an antique!

(Well, that’s how I remeber it… I might be paraphrasing a little.)

Not everybody needs a fancy box to do simple tasks. Pentium-class systems, and high-end i486 systems make quite decent X-terminals. As slow as early 486s and 386s are, they still are useful in situations where you just need a router or DHCP server (for example) to service a small home network.

I’m planning to put my 386 into active service. My Qube2 sits in my laundry, which is great. It’s cool, it’s a headless box with no need for direct interaction.

But interacting with the serial console is a pain, I have to get my laptop out, and plug it in. Thus I probably don’t do as much kernel testing as I should.

The 386 should be fast enough for this task — all it needs to run, is sshd and minicom. For a single user. Gentoo using uClibc sounds like an ideal platform. Why?

• Minimum bloat: I merge what I need, and nothing more
• uClibc is targetted at low-memory, low-processing-power computers
• Gentoo gives me fine-grained control regarding what features I enable and disable.

Now the box is rather slow booting Gentoo. If I boot root-over-NFS, it takes about 30-35 minutes. I can reduce this to about 20 minutes when loading from a local HDD (narrow SCSI, as it happens), but I haven’t got far installing it due to problems with flakey disks. The kernel reports a BogoMIPS reading of about 3.9~4.2 when running at full-speed (33MHz), and about 1.6 with the “turbo” feature disabled.

Once I get it going however, it should simply be a matter of re-merging dropbear sshd (the default one in the Gentoo/uClibc stages dies with a SIGILL), merging minicom and a bootloader, and voila.

Any updates can be done via a chroot on a faster box, then the binaries shipped to the 386. Bootup time isn’t an issue, since the box can just sit there running — 386s don’t chew that much power.

This is quite low down in my priorities, at the moment I’m concentrating more on getting Gentoo/MIPS 2007.1 out the door, hopefully with some newer netboot images for Cobalt, and maybe some first ever boot images for Loongson.

But after that, I may look at what the Gentoo/Embedded people have (particularly GNAP) and see if that can be adapted to suit the needs of older computers.

I see no reason why this can’t be done — I’d much rather see the code in Gentoo streamlined to work better on older computers, than to see the specs increased, as this streamlining benefits all — not just those with few CPU cycles to spare.

Hi All…

After much waiting, the MIPS4 stages for little-endian MIPS systems are finally built. These are targeted at Cobalt users, but may also work for users of other MIPS4 and MIPS64 systems. The 2007.1 snapshot has seen a few changes in the time it’s taken me to compile this, so I may upload some updated stages later, but in the meantime, I’d appreciate any feedback on how well these stages work.

I plan to use them to rebuild my Qube2, whose root fs has accumulated many cobwebs over the years.

You’ll find the stages on my devspace for now.

Hi All…

Well, it seems I’m done building the MIPS1 stages for little-endian MIPS well ahead of time. I used one of the Lemote Fulong systems to build these, and had stage 1, 2 and 3 done in about a day and a half — which is a record for me — the Qube2 normally takes about a week, and it’s still chugging away at stage 1.

You’ll find all the generic stages on my devspace for now. I’d greatly appreciate it if some brave users could give them a try and let me know how they go. I’m doing some tests now, and things look promising, apart from guile failing a “make check”, everything seems to be going fine. These will work on any MMU-equipped little-endian MIPS box with sufficient RAM (~128MB… 64MB if you’re absolutely desperate, but you won’t be able to rebuild system packages like gcc and glibc).

The MIPS4 builds will be a little while, since the Lemote boxes only implement up to MIPS3, I can’t use them to directly build the Cobalt stages, thus they’re being done on the Qube2. I’ll let you know as things progress, but I expect it’ll be tomorrow before I have a stage1 tarball available for MIPS4.

Hi All…

I’ve started building the seed stages that will eventually become release 2007.1, once the release engineering release their snapshot. Not sure exactly when that will occur, but I expect some time in the next fortnight or so, the builds will start in earnest.

This is the first release where I’ve used the Loongsons to do much of the compiling work. My Qube2 is in bad need of a rebuild, so it may get one this year. My experimental box, zhenghe has already compiled the stage1 and stage2 pre-release tarballs in the last day — a task that would’ve normally taken me several days on the Qube2.

The MIPS4 builds will still need to be done on the Qube2 (since the Loongsons only implement MIPS3), so I anticipate I’ll have MIPS1 builds available ahead of the MIPS4 builds, but hopefully builds for both CPU types will be available for testing by the end of the month.

At the moment I’m off-line as far as IRC and IM contact is concerned — this is because I really need to concentrate on my studies. I’m repeating one telecommunications subject that I failed last year, and things are looking really bad this year — in short, I cannot afford another 3 mark or fail if I’m to continue at uni. (If I drop out, I shall have to discontinue my work with Gentoo … a bit difficult to power a PC when you don’t have a house to call home.) So my priority is definitely with my exam studies for now.

After my exams are over, I’ll certainly be back into the swing of things… I’ve got some preliminary crude images that could form the basis of a LiveUSB image to boot a Lemote Fulong PC, and I’m starting to piece together a newer µClibc-based environment for newer netboot images on Cobalt systems. Since these require much more direct intervention (I build them by hand presently) they have to wait until then.

But for now, things are plodding along nicely, Gentoo-wise. As always, if you need to get in touch, I can be reached via email for now… and I’ll let you all know as things progress. See the front page of my devspace for a progress summary.

Hi All…

Lately I’ve been having some fun with the Fulongs… The other day, I managed to port Quake II to Gentoo/MIPS, and whilst I’m yet to test it on big-endian MIPS… it works great on the Fulong minicomputers.

Frame rate isn’t spectacular, it can only handle 400×300 when using software mode… but it’s playable. This would have to be one of the first commercial games to be ported to Gentoo/MIPS.

Now comes the fun bit of getting OpenGL going. Thanks to Lemote, I’ve got some patches that almost get things working correctly. I have hardware-accelerated 3D for about 5 seconds, before the following message is emitted by the kernel:

[code]Oct 9 00:21:17 [kernel] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock[/code]

After that, it’s game over… X freezes up, and I have to reboot the computer (via SSH) before I get local control back. But it’s a start. The full details are on the Lemote forums where I’m working on solving the problems… but certainly things are looking up.

Hi All…

Some good news on the Loongson front. I’ve managed to figure out unionfs, and udev enough to construct a kernel and minimal userland that’s capable of mounting a SquashFS volume from a USB HDD, then lay a tmpfs volume over the top of it, making it writable.

The LiveUSB images will likely come in two forms:

• A minimal image, that’ll just provide a basic system capable of performing an installation of Gentoo
• A complete desktop image, with KDE, Firefox, Thunderbird and all the usual conveniences.

The boot procedure will go something like this:

1. Download the LiveUSB kernel and your chosen OS image to a USB HDD, or burn them on a CD (if you have a USB CD-ROM drive) naming the files ‘kernel’ and ‘gentoo-mipsel-root.sqfs’ respectively in the root directory of the disk.
2. Plug the USB HDD or CD-ROM into the Lemote Fulong computer and power it up
3. Hit ESC to break into the PROM, then type (substituting vfat with the appropriate driver… I might have the vfat wrong too):
   PMON> load /dev/fs/vfat@usb0/kernel
PMON> g console=tty

Gentoo will then start automatically booting from the USB HDD. Ultimately I want to construct something equivalent to the Gentoo 2007.0 x86 Installer CDs which have the Gentoo Linux Installer, but I figure even there, it’ll be a similar procedure to boot them — first though, the installer needs some MIPS love.

On my TODO list, is to figure out how the livecd target in catalyst works … at present I’m doing everything by hand. I’d also like to try and fix µClibc so it doesn’t die when the kernel page size is bigger than 4KB (on Loongson, one needs to use a page size of 16KB).  Time will tell here, at the moment I’m a bit busy to go delving into the depths of the µClibc dynamic linker to fix things, so I’m just using the rather bloaty glibc library.

In short though… we’ll soon have the very first install images for Gentoo/MIPS on this platform available.

Hi all… Two issues to raise here:

binutils-config and the missing ldscripts/elf64btsmip.xr reference

It seems this problem seems to be happening to quite a few people. If you follow the Gentoo/MIPS handbook to-the-letter with the present version of binutils-config, you wind up with this:

moosehead linux-2.6.22.6-20070902 # make vmlinux.32 modules CROSS_COMPILE=mips64-unknown-linux-gnu-
CHK include/linux/version.h
CHK include/linux/utsrelease.h
Checking missing-syscalls for N32
CALL scripts/checksyscalls.sh
Checking missing-syscalls for O32
CALL scripts/checksyscalls.sh
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
LD init/mounts.o
mips64-unknown-linux-gnu-ld: cannot open linker script file ldscripts/elf64btsmip.xr: No such file or directory

The fix… update to binutils-config-1.9-r4 or newer, then run binutils-config –mips && . /etc/profile before trying your kernel build again. For further details, see bug #171486. Gentoo 2007.1 (next release) will fix this issue.

Heads Up

As some of you may know, I’m nearing the end of my double degree (Bachelor of IT/Bachelor of Electronic Engineering), and part of that involves getting 60 days industrial experience. I’ve applied to a number of companies — some of these positions will take me to rural locations where I may not have a permanent internet connection (or even reliable dialup).

Thus, during this upcoming summer break (between mid November through to late February), I may wind up going on a temporary hiatus from Gentoo. None of this is definite at this stage, nobody that I’ve contacted has gotten in touch to line up an interview however I figure I may as well post this here now so that the me disappearing doesn’t come out-of-the-blue.

The plan if I do wind up temporarily moving: I’ll try and get 2007.1 pushed out the door before I leave. This will focus on newer stages for MIPS1 and MIPS4 little-endian targets. I’ll set up both Lemote boxes here so that other Gentoo devs can gain access to them whilst I’m away. If I can get any internet service at all, I’ll be around to answer queries, and maybe do some limited work via SSH, but testing X or audio apps are out of the question.

As I say, none of this is definite, and I may wind up getting my experience somewhere here in Brisbane (ideal case). That said… given my stress levels lately, they say a change is as good as a holiday… maybe a few months living in a country town is just what I need.

Well… if you looked at the number of commits I’ve done lately, you’d be forgiven for thinking I’ve been resting on my laurels for the past month. In some ways, this is true… but I’ll soon be doing a bumper crop of updates.

KDE 3.5.7 Keywording

I’ve been using this release of KDE for a good few months now. I’ve given it a run on my Octane, everything seems to work alright there… and I’ve been using it on a daily basis on both Loongson machines — and thus can be fairly confident it won’t break anything.

Avahi to earn ~mips badge

Again, I’ve been using this package on MIPS for a very long time, since mid-last year. Everything seems to work. Along with this, will be dbus-1.0 and nss-mdns.

Re-keywording of Gnome

This hasn’t been discussed yet, and as such no decision has been made, but I have been working towards getting Gnome installed on my O2. Some packages failed tests, some failed to compile completely … but nonetheless, there’s now the beginnings of a useful Gnome desktop. (Well, as useful as Gnome is likely to be… I’m a long-time KDE user myself, having switched to it during my SuSE 5.3 days. Prior to this, I used FVWM.) I’d like feedback from present MIPS users, about whether there’s any demand for this desktop.

Other packages presently in testing

I’ve started looking into other packages for ~mips candidates. Namely, I’m concentrating my efforts on packages that turn an otherwise useless MIPS box into a useful workstation. That is, desktop type applications such as KOffice, mplayer, xine, Amarok, Gimp, Inkscape … etc. Some of these, I’ve been using for a while… others I’m only just starting to build now. (e.g. I’m building Amarok, since I prefer it to Audacious, and in my experience, it handles Sun Audio better than mplayer or Audacious presently does)

On this matter, I’d love feedback on what people actually use their MIPS boxes for, and how Gentoo/MIPS can be better tailored for their needs. If you’re using Gentoo/MIPS for something productive, either as a hobby project or for something more serious, I’d also be interested to hear about it… since this will help in planning what needs to happen with respect to this port.

Lemote Loongson Support

Still, no word from trustees… but I figure any legal hurdles are well and truly gone now. I’m starting to look into how to produce media for these systems.

The biggest hurdle thus far, has been µClibc — or namely, it’s dynamic library loader (ld.so). The Lemote systems use a page size of 16KB — this was the default when I first started using the boxes, and as far as I can tell, they do not like using 4KB page sizes, the kernel dies a rather horrible death. Unfortunately, µCLibc, in it’s infinite wisdom, assumes a page size of 4KB. Thus when it tries to dynamically load libraries, one gets hit by a “can’t map <foo.so>” message.

So where does this leave me? By the sounds of things, the netboot images will probably wind up being either a hybrid statically-linked µClibc busybox with dynamically-linked glibc filesystem tools, or will be a completely dynamically linked glibc affair, depending on which winds up being smaller.

Thankfully I can kinda get away with using more space — I don’t have the size restrictions on the platforms I support. CoLo on Cobalt will load kernels of almost any size, as will PMON2000 on Loongson, but still, I cringe at the idea.

Apart from netboot images… there are a few other steps to be done here:

• Keywording of the ATI Radeon driver — this can probably happen straight away. It won’t break the SGI boxes, since they don’t use the Radeon driver, and I know it works out-of-the-box on Loongson.
• Patch X.org — There’s some patches needed to the core components of X.org for it to work on Loongson. These need to be tested on SGI systems to ensure they don’t break things. It’s quite likely they’ll wind up in X.org CVS in the next few months, but it’d be worthwhile locating and fixing any bugs that occur ahead of time.
• Inclusion of patches into mips-sources — At the moment, I’m waiting around for a 2.6.21 or 2.6.22 ebuild to show up so I can try out the patchset I have here, the holdups being IP28 and IP30 support. Once I can get the Lemote patchset into a form that cleanly applies to mips-sources, we’ll then look at formally including them in the ebuild.
• Handbook updates — to be done once formal approval has been granted and the other steps are complete.

So, lots of work to do… and all of this whilst getting into my studies (e.g. there’s one piece of Allen Bradley ladder-logic code that’s just screaming for me to pick through it for a uni subject) and looking for industrial experience. Hopefully university studies won’t burn me out like they have for the last 12 months.

As always… you know where to find me if you wish to get in touch.

Well, those who recall my earlier post… I’ve managed to get a VM going.
qemu-mipsel ~ # emerge --info
Portage 2.1.2-r9 (default-linux/mips/2007.0/cobalt/o32, gcc-4.1.1, glibc-2.3.6-r4, 2.6.18-4-qemu mips)
=================================================================
System uname: 2.6.18-4-qemu mips MIPS 4Kc V0.0 FPU V1.0
Gentoo Base System release 1.12.6
Timestamp of tree: Sun, 12 Aug 2007 13:50:01 +0000
dev-lang/python: 2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox: 1.2.17
sys-devel/autoconf: 2.61
sys-devel/automake: 1.6.3, 1.9.6-r2, 1.10
sys-devel/binutils: 2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.14.4
ACCEPT_KEYWORDS="mips"
AUTOCLEAN="yes"
CBUILD="mipsel-unknown-linux-gnu"
CFLAGS="-mips1 -O2 -pipe"
CHOST="mipsel-unknown-linux-gnu"
[...]

The assessment? Well, firstly, it’s slow, very slow. I realise the BogoMIPS is a somewhat dubious benchmark… but:

QEMU:
system type : Qemu
processor : 0
cpu model : MIPS 4Kc V0.0 FPU V1.0
BogoMIPS : 246.27

versus… my Qube2 (250MHz):
system type : Cobalt Qube2
processor : 0
cpu model : Nevada V10.0 FPU V10.0
BogoMIPS : 248.83

one of the Lemote Fulong miniPCs (660MHz):
system type : lemote-fulong
processor : 0
cpu model : ICT Loongson-2 V0.2 FPU V0.1
BogoMIPS : 444.41

or my IP28 (195MHz):
system type : SGI Indigo2
processor : 0
cpu model : R10000 V2.5 FPU V0.0
BogoMIPS : 193.53

Is it usable?  Well, if that benchmark is anything to go by, it isn’t that much slower than my Qube2.  But the CPU that QEMU emulates, doesn’t implement any cacheops… so in that respect, it’s even slower than the Qube2 (which at least has some primary cache) .  I’ll know as I install more stuff, but my first impresions are that it’ll be too slow for most tasks running Gentoo, unless your host PC is a beast (mine isn’t).  Unless you’re doing development, you’d be better off just running everything on the host PC bypassing the emulation layer.

I might consider putting together a kernel that will allow installation of Gentoo/MIPS, since it’ll be a good way for me to test the userland components of any netboot images I produce.  I’m yet to try a kernel build, at the moment I’m using Debian’s kernel.

It is doubtful that this machine will ever be officially supported, but I’ll consider it if there’s sufficient demand.