Redhatter’s Web Blog

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.

I’m in the process of installing Debian/MIPS on QEMU. Why might you ask? Well… the situation only came up just recently.

It seems there is some interest in running Gentoo on the QEMU virtual machine. The catch: QEMU emulates a MIPS Malta board with a 4Kc processor — which implements the MIPS32 ISA (a superset of MIPS2).

Until recently, this was impossible, as we did not produce stages for anything less than MIPS3 on big-endian MIPS, or MIPS4 on little-endian. MIPS32 is officially defined as the 32-bit subset of MIPS64, thus implements all the 32-bit instructions present in MIPS64, MIPS4, MIPS3 and completely implements MIPS1 and MIPS2.  It doesn’t however, implement any of the 64-bit instructions in these ISAs, which is where users come unstuck.  I produced some MIPS1 stages for little-endian MIPS, so in theory, the port is possible.

There’s also the question of performance — the guide I’m following suggests I can expect the performance of an R4400 200MHz Indy when ran on a 3GHz AMD64 host. Unfortunately for me, my host is a 1.4GHz Pentium 4. So I’m expecting things to be quite slow.

If things test okay, I might look into how one compiles a kernel for QEMU, and see if it’s worthwhile, since QEMU is much easier to get hold of then most supported MIPS platforms. It’s not known if mips-sources will be suitable, theoretically it should be, but this has never been tested. Support will be quite minimal, since most second hand SGI machines I suspect will outperform QEMU many times over. At the moment, my VM is “installing core packages” (yes, debian-installer is quite stingy on information), after which, I should be able to set up Gentoo on a second virtual HDD.

Support will likely take the form of a minimalist HDD image and kernel that can be booted on the VM.

Hi All…

Figured I better let you know what’s happening from where I’m sitting, since it’s been a while.

Mozilla Package Support on MIPS…

For the past month or so, I’ve been faced with a few problems. Firefox 2.0.0.4 has decided to not compile, despite 2.0.0.3 working fine … It would appear I need to re-jig this MIPS patch so that it works with the updated codebase. The patch I specifically refer to is the 006_mips-asm.patch file that you’ll notice included in all the patchsets distributed with Firefox and Thunderbird. Without it, Mozilla uses assembly code specially crafted for the Sony Playstation II — an incompatible machine to just about every other MIPS machine in existence.

Thunderbird has its own problems too. People may have noticed -mips KEYWORDS on the 2.0 series and my refusal to mark >1.5.0.8 stable? Seems there’s a bizzare bug that only happens to me on big-endian MIPS (mips-unknown-linux-gnu) when talking to my local IMAP server (running B-Inc IMAPd 1.2.12). On little-endian MIPS (mipsel-unknown-linux-gnu), everything works flawlessly. Indeed, I’ve been using Thunderbird 2.0 on mipsel for the past few months without issues… if mipsel was our only architecture, it’d be keyworded in a heartbeat, but it’s not. The problem manifests itself in two ways: one is the apparent non-existant mail folders, the other is hanging in an infinite loop apparently switching folders. I’ve tried strace and other tools to no avail… but my biggest problems revolve around my (big-endian) boxes being quite slow and my limited time. Needless to say… I’d appreciate others’ comments on this issue if they’ve experienced these problems with Thunderbird, or if indeed, it works on their SGI box.

Adventurous users can try it for themselves by editing the relevant ebuild directly and running ebuild foo.ebuild digest before attempting a merge.

Gnome packages…

I’ve began trying a test-compile of Gnome 2.18.0 on MIPS lately… largely to see just how much of it is actually broken. Unsurprisingly, much of it failed in N32… mono being one spectacular failure: it got stuck in an infinite loop and filled up the disk printing debugging output, which of course portage logged in the package’s build.log. My O2 is busy doing many of the package builds here, progress being quite slow. Needless to say, there’ll be updates on the situation as I get each part built. I strongly doubt this will lead to a re-keywording of Gnome on MIPS however, because frankly, it’s a pain in the arse to maintain.

Possible support for Loongson on the horizon…

This is the first time I’ve discussed this on Gentoo Planet… Others may recall seeing my Gentoo Universe post talking about my usage of a Lemote Fulong minicomputer… No official decision has been made at this time, but behind the scenes work is already underway to allow support for this architecture under the Gentoo/MIPS banner. This is the box that I’ve been doing much of my little-endian testing on, since a 660MHz Loongson 2E will outperform a 250MHz RM5231 any day. Ultimately, I’d like to see this machine become officially supported, as I suspect it’ll be machines like this that will keep the MIPS port alive. The SGI boxes currently supported will eventually fail, and as the pool of parts dries up, so will our users.

At present, these boxes can be made to run Gentoo no problem. You need a small patch for xorg-server to prevent a nasty segfault when starting X, and of course, the kernel needs some patches that are not yet in mips-sources (or upstream). Work is being done in an overlay hosted by Lemote for now, but as soon as I get the official go-ahead, I’ll start moving things into the main Gentoo tree.

glibc upgrade issues…

Some users have reported issues when upgrading to glibc-2.5, essentially the build seems to cause hard-locks on some IP28 and IP30 users (me included). Work is still ongoing to track down why this occurs — as always though, feedback would be appreciated.

Cobalt IDE-related issues…

On later mips-sources kernels, some users have reported kernels failing to detect their IDE HDDs. I haven’t been able to test since 64-bit kernels are broken (I run a 64-bit kernel on my Qube2 for N32 testing) in other Apparently the issue is related to hotplug support — yes, despite the machine having no hot-pluggable interfaces, you still need hotplug in your kernel. People may want to look into moving across to the newer VIA PATA driver too, since I suspect the upstream kernels will start moving this way anyway — the newer driver is quite stable on Cobalt. More info in this forum thread.

If I think of anything… I shall post more later.