Well, Gnome 2.24 is still unstable. A bit disappointing, but there was a gentoo wiki page detailing all the packages I needed to put in /etc/portage/packages.keyword to get Gnome 2.24. So then I was looking at Xorg. xorg-server 1.3 is still the only stable release under Gentoo. It's like 2 years old now! Really? That is the best Gentoo can do? So then I started looking at other stuff. GCC 4.1 is still the latest stable release (4.3.* has been out for a year and 4.1's latest release is 2 years old). At which point I realized that if I wanted a current modern Linux system I either would HAVE to run a unstable Gentoo system, or change distros.

Looking at the fact that if I wanted to stay with Gentoo, I'd have a day or two of compiling a head of me, and then who knows what integration head aches as programs and config files change just to get a vaguely working vanilla Gnome system on an "unstable" Gentoo system, I balked. It just didn't seem worth it. Also, Gentoo is a system that really depends on the compiler, so having the only stable compiler be a two year old version really surprised me and kind of was the nail in the coffin.

So I'm downloading Ubuntu 8.10 and I'll have it installed probably before even 'emerge --system' would be done. And it will be modern, and cutting edge, and all the desktop software will work and be integrated together in all the ways that Gentoo never really does with out lots of extra work.

And so I'm forced to ask: is Gentoo dying? It used to be easy to at least have a cutting edge system with Gentoo. That was one of it's big appeals, that software hit portage before anywhere else. But now, lots of "new" stuff is off in an overlay, and stable in the main portage tree is shockingly (at least to me) old and conservative. It seems way to much hassle to get a cutting edge desktop out of Gentoo now, especially with Ubuntu doing a decent job of it so trivially.

I still have Gentoo on my server, but again, I just had to install a new overlay, just to get the "new" Ruby 1.9 line which has been out for a year, and everyone, even Debian stable is carrying (do you know how weird that is to me?). And what is the point of having a "stable" if it's so old as to be half unusable and older than even Debian stable? This is not the Gentoo I remember, and I'm even a little surprised with how easy I decided to abandon it on my desktop, but when it came down to it, it really didn't offer me much of a compelling or even difficult choice. :(

Mission

To turn basic Familiar 0.8.4 on the IPaq hx4700 into something useful. More specifically, to make IR and Bluetooth work, to make my Belkin IR Keyboard (F8U1500-E) work, and then to install a Debian chroot on an SD card (via the cross install technique) where we can then install, for example, every programming language and text editor we could want for portable programming purposes.

Getting Started

So, first things first, you need an IPaq hx4700. Or at least an IPaq, and hopefully one supported by Familiar Linux. As you can see from the list the hx4700 is supposed to have A+ support. It turns out that's kind of a lie. But we can do surprisingly well with some work. First off, throw away the Familiar Installation guide, it doesn't apply to the hx4700. They put together a different one on the wiki at handhelds.org/moin/moin.cgi/HpIpaqHx4700HowtoInstallLinux. Read it.

Files and Filesystems

So now's as good a time as any to mention that I've collected all the files you'll need and put them on my FTP at ftp.mindstab.net/ipaq-hx4700.

First off you need a SD card and you need to write the bootloader all over it so whip out DD and does as the instructions say. Then when that's done toss an ext2 file system on your SD card, we'll need it later.

Now for some work with the CF card. Since we're flashing from it I'd suggest using the FAT filesystem. We'll stash all our system stuff on it here's a quick list of what you should grab from the FTP and put on it.

• zImage-2.6.15-hh2-ipaq-pxa270: kernel
• zImage-2.6.17-hh3: exciting new and more useful kernel, but we can't install it until the system is up and we copy it's modules over to the ipaq.
• bootgpe-v0.8.4-ipaq-pxa270.jffs2: Root filesystem with GPE installed. I'd recommend GPE over OPIE.
• reflash.ctl: Control file for the bootloader to know what it can flash. This one is updated with an option for the new kernel.
• RADIO0d.BIN: Firmware driver
• radio11.bin: Firmware driver
• wlangen.bin: Firmware driver
• 2.6.17-hh3.tar.gz: Kernel modules for a newer kernel. Untar it in place.
• install-firmware.sh: Shell script to install the firmware. The names are case sensitive so depending on how your FAT filesystem performs this might not work :/.
• install-modules.sh: Install the kernel modules for the 2.6.17 kernel. Assumes it's running with the untarred file 2.6.17-hh3.tar.gz. Copies the modules to /lib/modules on the ipaq.

And now is a good time to mention that I got an IR keyboard with my IPaq, specifically a Belkin F8U1500-E, which didn't work with the IPaq for a number of reasons at first. I solved them all. If you have this key board you'll also want the following files. If you have any IR keyboard you still might want at least the init.d file from the list.

• install-kbdd.sh: Shell script to install the files
• init.d.kbdd: Adds lines to the start function to remove extra IR kernel modules that prevent simply IR keyboards from working. Also kill irattach.
• kbdd.conf: Config file that just says use a belkinir keyboard on /dev/tts/2.
• kbdd: My patched kbdd program with proper support for my keyboard.

I also put up kbd.c which is the file I modified from the kbdd source for anyone who wanted to see what I'd done (also, I suppose, to comply with the GPL ;)). I know it's a hideous mess and hack, but using a case statement was easier initially in order for me to figure out how to get the keyboard working. I fully intended to turn it into an array latter, but once it worked I got lazy and left it. Meh.

Getting Familiar up and Running

Ok, you now have the CF card with all the files you need. Toss it in the IPaq and follow the flashing instructions on the wiki. Flash the 2.6.15 kernel, and then the GPE root filesystem. Then you can let GPE boot. It might take a bit.

Also, the boot loader and possibly the IPaq itself are kind of finicky. If it just won't turn on, don't worry, you probably haven't bricked it, its just in a funk. Let it sit for like 5 minutes. Also try pulling its battery for a bit, putting it back in and then putting it on AC power. Eventually it'll decide that the time is right to try booting again.

So, once GPE is up, there are a few change that we need to make to make life easier and better. First, go to "Setup->Login Setup" and set "Automatic Login" to yes. This will automatically log you on as root, instead of asking you for user name and password of some non root user. Really much beter in the long run for this device. Then log out and you should automatically be logged back in as root.

Now we can proceed.

We'll need to do some typing to get the necessary files installed, so you'll need to bring up the on screen keyboard. It kind of sucks, but I've seen worse. It is usable. Also, I've tried to write scripts to automate a bunch of stuff to keep the typing to a minimum until a real key board can be used.

So, bring up a root console from "Others->Root Console". "cd" onto the CF card, "/media/cf".

First we'll install the firmware, so run "sh install-firmware". Ideally this will work but you should double check and fix if it doesn't. What should happen is the 3 ".bin" files are copied into "/lib/firmware" and their names are all uppercase except the "d" in RADIO0d.BIN.

Next run "sh install-modules" which should copy the 2.6.17 kernel module directory (you untared the .tar.gz right :)) into /lib/modules. Now when we flash our new kernel it'll find it's kernel modules installed and actually work, as opposed to choking in boot, or booting but being generally useless.

If you have a Belkin IR Keyboard (F8U1500-E) then you'll also want my kbdd, and if you have any IR keyboard you might want my init.d.kbdd file.

So run "sh instal-kbdd". It should copy kbdd to /usr/sbin/kbdd (saving the old one as /usr/sbin/kbdd.old), copy kbdd.conf to /etc and copy init.d.kbdd to /etc/init.d/kbdd.

Now you should have your base system much closer to ready. Now that the firmware is installed if you were to reboot your Bluetooth should work. However the kernel that shipped with Familiar 0.8.4 had broken IR support, so we need to upgrade to the 2.6.17 kernel I compiled for the IPaq. If you have a different piece of hardware there are instructions in the handhelds.org wiki for getting and compiling kernel source. Ignore the part about them making their own configs, it didn't work for me, instead just copy /proc/config.gz to your sd/cf card and use that.

So to flash the new kernel after the modules are installed, reboot the IPaq holding the two upper keys (as the instructions said) as well to bring up the boot flasher and this time pick the 2.6.17 kernel.

Now it should boot up and Bluetooth and IR should work and your Belkin IR keyboard should work. Like magic. I still haven't gotten wireless to work but I'll update this if/when I do.

Wired USB internet

Next? We need connectivity. I still haven't gotten the wireless to work, but you can easily do ethernet-over-usb and use a desktop as a router. My instructions are Linux specific but I'm sure other OS specific instructions can easily be found by Google.

I already wrote instruction on how to get a mobile Linux device online with Linux so check out the instructions at www.mindstab.net/wordpress/archives/174#gp2x_networking.

The net.sh script for the IPaq has an extra line and looks like

#!/bin/sh

ifconfig usb0 up 10.1.0.2
route add default gw 10.1.0.1

and you can get it at ftp.mindstab.net/ipaq-hx4700/net.sh.

Native Video

So the IPaq can play video. It's a smidgen of a hack for GPE because the version with familiar doesn't actually have a mplayer compiled for it so I nicked the one for OPIE and flubbed one of the dependancies: instead of using the SDL 1.2.7 compiled for OPIE and depending on OPIE on used the 1.2.4 version compiled for GPE. This might be why the video is currently choppy until I can find a better solution because there might be a much faster rendering path on OPIE for SDL than there is under GPE. Still, this will work if you don't mind choppy video (but at least the audio is 100% solid). What I think I really need to do is find a way to make XV work on GPE and get mplayer to use it.

As for getting this working, all you need are some packages I've collected. Just grab the following from my iipkg collection at ftp.mindstab.net/ipaq-hx4700/ipkg:

• libmad.ipk
• libpostproc.ipk
• libsdl.ipk
• mplayer.ipk

I think that's all you need. Either way, if it asks for other dependancies they are in the folder, so just grab everything. I think you have to force one of them to install ignoring it's dependancies with the '-nodeps' flag. Anyway, once you get mplayer installed, it uses the SDL video output plugin. In order to make video and audio sync and not play laggy or slow I recomend the following flags:

mplayer -framedrop -nocache $MOVIE

As I said, it's currently laggy, but it works, and I'm looking for a better solution.

Making an ARM Debian Chroot

Note: For anyone who has been waiting for almost a year for my promised guide on how to make a Debian chroot for the GP2X, this is it. The instructions are the same. I originally did this on my GP2X until I got netwokring working on the IPaq, and shared the chroot SD card between them.

Now the IPaq only has limited space and only a limited number of programs compiled for it. If you want access to absolutely all software, then we need another source. The answer is a Debian chroot. Debian has great arm support so about 99% (Not Java) of stuff in the Debian repository will be accessible to you. All you need is space. So grab a decently sized SD card and put a reasonable filesystem on it, like ext2. Now, in order to install Debian we need Debootstrap, their utility for installing Debian from anywhere. You could try and install it on the IPaq but it'd be a hassle. I found the best solution was to download the ARM install disks (or minimal CD) and just copy off the entire filesystem. It's only a few MB. You can get my copy at ftp.mindstab.net/ipaq-hx4700/deboot.tar.gz Untar it on the SD card.

For this to work you'll need a network connection on the IPaq so make sure that's setup and working.

(For GP2X users, for each chroot (the debootstrap one, and the final one) you'll also want to run 'cp /lib/libiconv_plug.so lib' where lib is what will be the root lib directory in the chroot.)

Then on the IPaq execute the following to set up the environment to chroot into the Debian install environment.

cd deboot
cp /etc/resolve.conf etc
mount -t proc none proc
mount -o bind /dev dev
chroot .

Now you're in the actual minimal Debian install environment that is really only capable of doing one thing: running Debootstrap. So go for it. Install it in the chroot for now, you can always move it out once done.

debootstrap --verbose --arch arm etch /mnt/etch http://gulus.usherbrooke.ca/debian

Keeping in mind to change the Debian release name to what you want and to change the mirror to something appropriate to you. For a full list of Debian mirrors look at www.debian.org/mirror/list.

When it's done, you'll have your very own Debian chroot in /mnt/etch under the chroot or /media/card/deboot/mnt/etch in the IPaq filesystem.

You'll probably want to move the chroot to either the root of the SD card or just a subdirectory, so exit the chroot and then

mv /media/card/deboot/mnt/etch /media/card/etch

Now you have your very own Debian chroot. A few last things need to be set up before using it. Again, it will need internet too if you want to be able to install software, so run

cp /etc/resolve.conf /media/card/etch/etc

Next you need to add a few things so the environment will be have as Debian expects, and not inherit the slightly different IPaq environment, so grab profile and profile.ipaq and put them in the /etc directory of your chroot. Mostly it just sets your home directory to /root instead of /home/root and a few other minor things but important things.

Finally, get the chrootme.sh script and put it in the root of your chroot.

Now all you should need to do to use your chroot is

cd /media/card/etch
./chrootme.sh
source /etc/profile

Now you are in your live Debian chroot! Congrats! So why did we go to all this effort to just get another Linux environment when IPaq already has one? Well, this one can now install any software that Debian supports, which is pretty much all software :). But first, at least in my case, we have to do a few things for apt so it will be happy. Run

touch /root/.gnupg/trustedkeys.gpg

gpg  --keyserver subkeys.pgp.net --no-default-keyring --primary-keyring /etc/apt/trusted.gpg --recv 359AAB34 

wget http://ftp-master.debian.org/ziyi_key_2006.asc
gpg --no-default-keyring --primary-keyring /etc/apt/trusted.gpg --import ziyi_key_2006.asc

This install the required gpg trust info so that you can securely talk to the Debian package server.
You can also select a mirror by editing '/etc/apt/sources.list'. Now just

apt-get update

and then you can 'apt-get install ' any piece of software you want. I'd recommend starting off with a text editor like vim and/or emacs, and the some programming languages like Python, Ruby, Lisp, or C. Now you have a mobile coding environment that fits in your pocket!

Conclusion

Well, now you have an ultra portable computer that can run any piece of Linux software. I turned mine into a portable development machine. I've been using it at University in my CS classes, but you can do what ever you want with yours.

As for the future, the only real things this tutorial still need are ways to get the WiFi working and usable, and a way to squeeze better framerate out of MPlayer. If anyone has any ideas, please get in touch and let me know :)

I hope this set of notes/tutorial/howto is useful to anyone.

I had already gathered data from some of my computers from when I bought Bast, my G3, so I just ran the benchmarks on the GP2X and added them in for comparison.

Machines

Results

Time in seconds to find all prime numbers between 1 and one million

	Inferno	Nika    Kvasir  Bast    GP2X
C	1.19	0.79	0.45	2.83	35.1
ObjC	1.19	0.8		2.83	43.4
C++	1.93	1.06	1.1	4.76	50.1
Java	3.59	1.63	2.14	40.3
C#	3.69	1.87		10.5	140
Awk	32.1	27.1	30	199	2065
Perl	38.2	21	23.3	145	1280
PHP	15.1	8.89	13.4	64.9	758
Python	54	38	43.8	211	1526
Lisp	10.4	5.19		36.3	2674

As you can see, of course, the 200MHz ARM GP2X was destroyed by everyone else. This really doesn't tell us anything at all actually.

Clearly scaling needed to be introduced so that we could see how the languages faired on the different architectures. All being equal I assumed that GCC would give the best optimization per platform and that the C results would be the least skewed, so I choose to represent all the results as multiples of the C time results, or divide all the times by the time that the C prime number finder took on that computer. It yielded the following results:

Time in multiples of C time to find all prime numbers between 1 and one million

	Inferno	Nika    Kvasir  Bast    GP2X
C	1.00	1.00	1.00	1.00	1.00
ObjC	1.00	1.01		1.00	1.24
C++	1.62	1.34	2.44	1.68	1.43
Java	3.02	2.06	4.76	14.24
C#	3.10	2.37		3.71	3.99
Awk	26.97	34.30	66.67	70.32	58.83
Perl	32.10	26.58	51.78	51.24	36.47
PHP	12.69	11.25	29.78	22.93	21.60
Python	45.38	48.10	97.33	74.56	43.48
Lisp	8.74	6.57		12.83	76.18

Analysis

x86 machines

You would think we could use these 3 machines to establish a baseline but we find a fairly large variance in results here. First of all, inexplicably, Inferno is the only machine to have a worse result for Perl than Awk. Also, we can see that when it comes to the interpreted languages, Kvasir is near the worst in all cases. I would attribute this to Hardened Gentoo adding very viable overhead to the interpreters. It seems to show there is a definite cost for added security in terms of efficiency.

PPC

The most notable result here is the Java result which is clearly markedly bad. Java for the PPC could use some optimization. C# care of mono on the other hand is competitive. The rest of the interpreted languages also lag behind on the PPC, although Lisp (SBCL) comes pretty close the the x86 scaled results.

ARM

And now what you've been waiting for, the ARM results for the GP2X. Well, Sadly, I just couldn't really get Java for the GP2X. Sun Java appeared to be unavailable. I could have used something like Kaffe or Jikes, but it probably wouldn't have been to fair, and also, on Debian, they insisted in pulling in some parts of Xorg as dependencies, and I didn't have a lot of space to play around with on the GP2X. Kind of lame, oh well. Again, as with the PPC, C# care of mono is very respectable. Other than that, the Lisp result was way off by a staggering amount, but that can be explained by SBCL not being available for ARM. I had to resort to the clearly slower CLisp compiler/'interpreter.'

Languages

As much hype as there is around Python these days, it appears to be fairly slow across the board compared to other interpreted languages. PHP on fact is the fastest of PERL, PHP, and Python on all tested architectures, so if you need speed and yet still the flexibility of an interpreted language, you might seriously want to use the CLI version of PHP. It seems the interpreter is very optimized across the board.

If you happened to be on an architectures supported by a good Lisp compiler like SBCL it is also a very attractive and viable option, but unfortunately for ARM, it looks like CLisp isn't, speed wise anyway.

As for Java, hopefully the GPLing of it will allow it to a) be further optimized for alternate architectures like PPC, and b) for it to be fully ported to 'new' architectures like ARM. If you're looking for speed but the middle ground flexibility of a VM language than in the mean time C# in the form of Mono is a fantastic looking choice.

Note: Ruby has again been omitted because until 2.0 is released, which includes a real VM, it is sadly not even remotely competitive in this area (math computation). It is about an order of magnitude slower than any of the other interpreted languages. Ruby 1.9 CVS last I checked (half a year ago) was competitive with Python :)

And that's it from me on the Primes front (at east until I acquire a Sparc box :P ...)