Redhatter’s Web Blog

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.

Hi,

As promised, some stages compiled for MIPS-I have been released.  These stages should be appropriate for almost all little-endian MIPS hardware equipped with a decent amount of memory (128MB or more).  This should make things a little easier for those wishing to install Gentoo on MIPS32 hardware such as AMD Alchemy development boards.

Note, anything kernel or bootloader related, we can’t help with.  It’s assumed you know what you’re doing as far as actually preparing a bootable kernel and configuring your firmware to boot Gentoo.

Next on the list, is to look into µClibc stages for Cobalt — which will hopefully be used to produce updated netboot images for Cobalt.  So yeah, I’ve been absent for the last week or so, de-stressing and getting uni sorted out.  In short, it’s all system’s go now.

Hi All…

At the moment, stresses are running high.  Exactly why, I’m not sure, but it seems everyone is on edge.  And I don’t just mean the Gentoo Development community — I mean elsewhere too.  Everyone seems to be edgy for reasons I cannot fathom.

I’m not going to speculate about what could be causing this stress… I know in my case, the tense atmosphere has had an impact.  I’m nowhere near the point of doing anything irrational like suicide (I know this will create more problems than it will solve), but I am noticing that I’m not in my usual “stable” mental state.  I think in my case, there are a few factors in play…

• At university, I’m doing a subject entitled “Core Project Initiation”, which heavily depends on groupwork.  We have to form groups of 5 people or so, choose a project, find a project supervisor (typically other lecturers at QUT), then work towards implementing a prototype.  The first assessment item, is due this Friday, and more or less requires the group to be formed.  After having two attempts at forming a group fail, I’ve been in contact with the lecturers and am in urgent need to get into a group.  Basically, if by Wednesday, I’m not in a group — I’ll pull out of the subject, it’s just not going to be viable for me to continue.
• Last semester was rather stressful, having had two major stuffups by the university (in one case, a lost exam paper; in a second, a breech of examination procedure), and winding up failing a telecommunications subject for seemingly unknown reasons.  A total lack of feedback was a big factor — there was nothing to suggest I was offtrack, yet, I got a 2 (7-point scale) as my grade for the subject in question.
• I’m still looking around for work.  I’m quite conscious that I’m basically living out of my father’s back pocket — have been for some time now.  This has been playing on my mind a lot lately.  I know that without any work, I can forget passing my degree, I can forget moving out of home at some point.  And luxuries like attending LCA2008 are definitely out of the question.  I’ve applied to several positions over the last few months without success.
• The weather has been rather hot and humid lately, enough to shorten the fuses of most people.  Add to that the fact that Brisbane (like much of Australia) is in drought, and that the dam levels are dropping to alarmingly low levels.
• Then there’s the censorship debate that’s been raging on for the past fortnight on both gentoo-dev and gentoo-core.

Some of these problems are aggrivated by communications issues stemming from my Asperger’s Syndrome.  Stress is not something I handle well, with depression being quite common in such circumstances.  I’m in the happy position that I haven’t needed any medication to keep things under control however — I intend to keep things that way if I can.  Right now, I’ve just detected abnormalities in my behaviour, and thus know something is up.
At this point, I’m certainly not planning on resigning from Gentoo.  My builds for MIPS1 (little endian) are progressing, having just started Stage 2 this evening.  There’s no major issues to deal with at this time, and I hope to have these out soon.  I’ve also picked a fight with µClibc trying to bash out updated stages — managed to mess something up rather badly there, but I’ll hopefully get that straightened out and have some netboot images for you.

Presently, I’ve got stuff in my personal life that needs my attention first.  Thus, I’ll be “away” for the next fortnight whilst things settle down locally.  I’ll be contactable by email, and may be on IRC sporadically — but I don’t expect to be doing a hell of a lot.  I need some time to reduce some of the external pressure, get myself mentally ontrack again.  Hopefully when I return, not only will things have calmed down around here, but people within Gentoo, and perhaps others globally, might have settled down too.

In short, I’ll be around, just laying low for a while.

Hi All,

I’ve just uploaded the stage 3 tarball for Cobalt users. This build is compiled for MIPS4… hopefully in a few days ~ a week, a MIPS1 build will join it. I’d greatly appreciate it if users could test these builds out and report back any findings.

Also, in case you missed… there’s a new CoLo release. I’ve tested it both booting from disk, as well as netbooting, and so far, everything seems to work as it should… but I’d again appreciate feedback before I bump it to stable. I aim to do this very soon, as the presently stable version does not compile under gcc-4.1.

Hopefully, I should have all this on mirrors by the end of the month once testing has been completed.

Hi All…

Some of you may recall a proposed patch to block the use of proprietary kernel modules in the Linux kernel.  This seemed like a good idea, and it’s one I’d support — however, I do realise there are some shortcomings in the plan.  Looking at the thread tonight, I happened to see a post by David Schwartz which suggested a trademark that could be used by the manufacturer if decent specifications were made available.

I did some thinking about this… and the idea of a small (perhaps non-profit) organisation, could be appointed, to devise Linux-compatibility standards, which companies must meet before they can claim their device is “Linux-Friendly”.  If this organisation agreed that, indeed, the device met the specs, the manufacturer would be given a license to use an appropriate logo when advertising their device to consumers, and they’d be allowed to call their device “Linux-Friendly”.  Otherwise, they’d be told how they can rectify the situation.

I’m thinking something like a 3-level system, which indicates the level of support provided by a device for Linux: (The following is obviously a rough draft)
Bronze-Level Compatibility:

1. Complete Hardware specifications must be made available to those implementing open-source device drivers
2. Technical people responsible must be willing to answer questions relating to the implementation of such drivers
3. Drivers and utilities for the device must be released under the GNU General Public License (may be dual-licensed) and should allow a user to utilise all the device’s features.

Silver-Level Compatibility:

In addition to the requirements of Bronze level, a manufacturer must offer technical support (at minimum, by email) for users running Linux.  Such support should apply to the mainstream Linux distributions (Red Hat/Fedora/CentOS, SuSE, Debian, Gentoo, Ubuntu), but may include other distributions too.
Gold-Level Compatibility:

In addition to the requirements for Silver level, a manufacturer must be actively involved in the development of the open-source driver.  Examples would include the Intel PRO/Wireless devices, WACOM tablets, HP printers…etc — all of these companies run open-source projects that develop drivers for their products.

The above is obviously a work-in-progress, and should not be considered official.  I use the Gold/Silver/Bronze system here, because many people are familiar with how it works.  If you’re new to Linux, obviously Silver or Gold level is best, but things may JustWork with Bronze-rated hardware… if you have contact with Linux-savvy people, or are Linux-savvy yourself, then Bronze will suffice.  If you don’t see any rating at all, it’s a matter of buyer-beware.
What would the logo look like?  Well… I’ve got an idea for that too:

The penguin was hand-traced from a photograph of a King Penguin uploaded to the WikiMedia Commons.  The thought is, perhaps the blue ring there could be coloured to indicate the level of support.  I have a SVG version of that image here.  Note: I ask people, to not use this logo for commercial use until proper guidelines are worked out.
Anyways… what are people’s thoughts?  I personally think it’ll make life easier for the typical Linux user, in determining what hardware to buy.  If there’s support for the concept, then it encourages through peer pressure, companies to participate, hopefully leading to better quality drivers.

Hi All…

Well, my stagebuilds are in full swing… at this rate, I hope to have stage1 up in a day or two, and I’ll be starting on stage2, etc very soon.
New Profiles:

The structure is much the same as the 2006.1 release, just replace “2006.1″ with “2007.0″ in your profile path. Portage will tell you what to do when we officially mark the profiles deprecated.  Or, you can switch ahead of time… e.g. on Cobalt:

# rm /etc/make.profile
# ln -sv /usr/portage/profiles/default-linux/mips/2007.0/cobalt/o32 /etc/make.profile

This will set your machine up with the new profile (using LinuxThreads… see below for NPTL).

MIPS1 Stages for Cobalt:

There has been some demand for such stage files for some time now, mainly for enthusiasts that wish to run Gentoo on mipsel machines that don’t implement the full MIPS4 ISA. In this release (after I get the MIPS4 stuff pushed out safely), I’ll build MIPS1 stages for those who wish to experiment. Please Note: We can’t help you with queries involving unsupported systems. For some userland-related issues, we may be able to provide some assistance, but anything involving hardware or kernel, you’re on your own.

The MIPS1 stages are primarily being used in a few unofficial ports of Gentoo to various architectures. I won’t say much more than that, as there are some legal issues which need to be addressed first… however, it is hoped these ports can go ahead. Naturally, I’ll let you know when this happens.

Heads Up - 2007.1 release:

In 2007.1, we plan to switch over to running NPTL across all MIPS platforms. At present, I’m doing some testing on mipsel using NPTL to confirm stability. Other MIPS developers have been running NPTL on SGI boxes for some months now with great success, so the code is considered reasonably stable now, even though it’s not keyworded as such. To use NPTL, switch to the nptl/ profile for your system, unmask glibc-2.4-r4, then upgrade glibc:

e.g. on Cobalt:

# rm /etc/make.profile
# ln -sv /usr/portage/profiles/default-linux/mips/2007.0/cobalt/o32/nptl /etc/make.profile
# echo '=sys-libs/glibc-2.4-r4 ~mips' >> /etc/portage/package.keywords
# emerge -a glibc

It would be greatly appreciated, if a few brave users could give this a try, and report back their findings.

Hi All…

Well, it’s that time of the year again… the lead up to release time for 2007.0. The official snapshot date is apparently next week sometime, which means I need to produce some pre-2007.0 stages in preparation.

Recently, I started the beginnings of an n32 port to Cobalt, with these stages being available from my devspace (contact me and I’ll provide the URL). In this release, I hope to provide stage1/2 tarballs (perhaps stage3 too) compiled for MIPS1, potentially allowing all standard (note; the PS2 and PSP are not standard) LE MIPS systems to run Gentoo. Users porting Gentoo to new platforms will still be largely on their own as far as support goes… but at least they’ll have a reasonable base system to work from.

Also on my TODO list, is to update the docs. Things aren’t too shabby, however there are some bootloader-related updates, now that arcboot has been punted from the tree, and arcload 0.5 is stable. CoLo will eventually need to be updated too… I’ve held off doing this, since I use my Qube2 as a file server, and thus value its availability. Also, since my PDA has decided to go on the blink, I’ve been without a convenient VT100 terminal to plug in… thus I’ll need to build a new null-modem cable to hook my laptop up.

Hopefully by next week, I’ll have some prerelease stages for 2007.0 (32-bit only for now)… and can start building the official stages once the snapshots are released by the Release Engineering team.