linux

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.

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. 🙂