Mindstab.net

These are notes and utilities and files I've gathered together to make my IPaq hx4700 useful to me, and setting it up decently easy. I know it took forever to type them up and finally publish them, but better late than never.

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 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 recomend GPE over OPIE.
• reflash.ctl: Control file for hte 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 teh 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.

So this morning I was reading Paul Graham's newest essay "Why to Not Not Start a Startup" (Good read as always). Got started but then it was time to leave for school but I wanted to keep reading it. Dilemma! So on a whim I grabbed my cell and plugged it in, copied the article text to gedit and saved it as a text file on my cell. On the bus I checked and my cell's web browser worked as a serviceable text reader. There wasn't glorious screen real estate, but it wasn't appealingly small either, a screen or three per paragraph. So I got to read the article on the way to school. Thanks technology.

This morning's events got me thinking, I want a portable multimedia tool. My GP2X was pretty good at this, except that my first edition (damn being a technology early adopter) had the small problem that the headphone port was mounted mere millimeters too deep so I always had to jam the jack in which promptly caused the port to snap off and fall inside the GP2X. Even after re-soldering it on, it had the same mounting problem, and it's coming loose again. The first indication in both times is that it stops turning off the external speakers even with the headphone jack in. Lame. And not covert. So I don't take my GP2X on the go anymore. But enough of that. I'd probably buy a GP2X now if I didn't already have one.

Why? The GP2X is great. More than people realize. It does music (ogg/mp3), sure, and true, my 1GB iRiver T30 [apparently off the market now] has this fairly covered, but where it shines is its movie playback capability, which I no longer have covered. Portable movie players cost about $300-$500 CDN easy (when I looked last summer). The GP2X comes in more like $200 CDN. And it's better. Why? Because it has mplayer. You don't need to transcode your videos to some weird and small format before you can take them on the go, just drag and drop them into your GP2X, mplayer can handle anything. You of course are free to still transcode them so they waste less space, but that's your choice. If I was in a hurry I could just drop a movie or two shows on a 1GB SD card and watch them on my GP2X. And everyone else wanted me to pay twice as much for a device that is a greater inconvenience (ok, so they do have like 20GB harddrives...).

This got me thinking about the talking I've been hearing about how everything is dying out to the phone, or smart phone. PDAs and music devices (Will The iPhone Kill The iPod?) are falling by the way side being replaced by integrated cell phone solutions. Cell phones with cameras, 4GB of storage, and mp3 and video capability are just coming into mainstream right about now (don't get me started about the new trend of kids huddled around a cell blaring off their music through appallingly bad speakers while in public spaces like the bus). This means that those portable media players are next to get hit before they even really take off.

Ok, so super integrated and featureful smart phones seem to be the future. But will they be any better than the current media players? Well, I was then reminded of Christian Schaller's guest appearance on LUG Radio a few weeks back. He mentioned that his company, Fluendo (a GStreamer company) were in talks with most of the major [European?] cell companies. GStreamer is the new (~2002) defacto Open Source (maybe just Gnome) media framework, but they also have for-money proprietary codecs as well (like mwv). So if the GStreamer framework started showing up on most cell phones I'd be well pleased. Nokia is surely covered in this due to the fact they already ship the Linux and GStreamer powered Internet Tablet N800, which is a pretty cool device all on it's own. Plays video, music, surfs the web.

Hell, I'd have bought one already if it was a phone too. :)

Well, since, I got Debian installed on my GP2X, the first thing I did was run some benchmarks. As per usual, I fell back on my "raw and simple math computation" benchmark suite Primes, a collection of prime number finders written in many languages. For the rest of the article we will thus be evaluating languages purely on math computational speed and nothing else.

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

Well, I took some time and experimented with crossdev for the GP2X and added those notes to my Gentoo GP2X Guide in a new section here (GP2X Crossdev). As I mentioned in the new section, it didn't end up quite working, and as I went along, I saw some potential further complications. So I'm going to pause on this track for the moment and explore another track that may be more promising, Debian on the GP2X.

Why? I haven't really spent much time with Gentoo's crossd evelopment tools yet, or their embedded stuff, but neitehr quite seem a match for this situation. The situation being I have a system, and simply want another computer to compile all new programs so as not to kill my SD card. crossdev feels more like it's meant for building a new system, not incrementally updating an existing one. However, a binary distro like Debian wouldn't give me the problems new software installation on Gentoo presents (compilation killing SD card).

So I'm going to take a look at Debian for the GP2X coming up soon.

Contents

• Why?
• Getting the GP2X fully online
• Preparing the media
• Networked File Systems
• Chrooting the Gentoo environment
• Crossdev
• Conclusion
• References

Why?

Because now that the GP2X can use ethernet over USB and Wifi it's pretty much a small form factor 200MHz ARM computer, and extremely portable at that. I've installed Gentoo on lesser machines. Also, I wanted an ultra portable box I could do programing with in whatever language I want, like Ruby or Lisp. But more generally, there is a vast array of software available to Gentoo that isn't available for the native Linux of the GP2X. If I could get Gentoo on the GP2X (which considering it's basically just a small ARM box, shouldn't be too hard) then I'd be opening up a whole new and vast world of software for the GP2X.

As for why chrootable and not a full install? The GP2X firmware does a good job and is extremely compact (~20MB). Getting Gentoo down to that might be a trick. Plus, with the custom hardware, rolling my own kernel might be a bit of work. And it would also probably preclude me from using any GP2X specific software. A chrootable Gentoo environment gives me the best of both worlds. I can use the GP2X and assorted software as normal, but pop in an SD card, and suddenly I also have a Gentoo environment. The GP2X Linux ends up acting like a bootloader and an abstraction layer between the somewhat custom hardware of the GP2X and the Gentoo environment.

Getting the GP2X fully online

Note: On the computer side of things it is assumed you are running Gentoo, as I am, so some things may have to be changed accordingly

First, we have to get the GP2X properly online. Upgrade to the latest firmware (anything 2.* should do). Once the GP2X is upgraded, turn it on and go into the Settings->System. Turn on advanced options, USB Networking, set the IP to 10.1.0.2, and turn on at least Telnet and FTP.

On the computer end, you need to add some additional support to your kernel. You'll need USB->USB Gadget Device support and from there 'Ethernet Gadget (CDC)' and 'RNDIS' support. Also, you need from USB->Networking: at least 'Host for RNDIS', and support for devices, so I went with 'Simple USB Network Links (CDC)' and 'Netchip 1080'. Finally, you need from 'Networking' enough stuff to get iptables up and running and doing NAT (network address translation). Recompile your kernel. Reboot if needed. Load the appropriate modules if needed (and add them to /etc/modules.autoload).

Now connect the GP2X via USB to your computer. To see if the connection was noticed check dmesg. To try it out

ifconfig usb0 up 10.1.0.1

Then trying pinging the GP2X (10.1.0.2). If that works, you should then also be able to telnet and ftp to the GP2X.

If it fails, you may need to update your g_ether module on the GP2X. Follow this quick guide to update it and try again.

We're almost there. We now have a LAN between your computer and the GP2X, but the GP2X doesn't have net access. We need to setup the computer as a firewall that does NAT for the GP2X. On the computer run

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables save
echo 1 > /proc/sys/net/ipv4/ip_forward
/etc/init.d/iptables start

Now your desktop should do port forwarding for the GP2X. But the GP2X doesn't know about it. So telnet onto the GP2X. We need to set it up for full internet access. Copy the contents of your '/etc/resolv.conf' to the GP2X's '/etc/resolv.conf' (This lets it know what name servers it should use for DNS). Finally, we write a simple script you can leave in /root that sets up the routing.

net.sh

#!/bin/sh

route add default gw 10.1.0.1

Then on the GP2X

chmod a+x net.sh
./net.sh

Now the GP2X knows that all connections to the net should be sent to your computer, which is now set up to forward them to the internet. The info in /etc/resolv.conf tells the GP2X where to look for DNS info (changing names into IPs).

To test, on the GP2X

ping google.com

It should work. (net.sh will have to be run every time the GP2X reboots, you may want to make arrangements for that.)

Now, to make this setup more permanent on the computer side of things, we need to set up a few things. We can automate iptables by

rc-update add iptables default

And we can automate port forwarding by editing '/etc/sysctrl.conf' and changing

#net.ipv4.ip_forward = 0

to

net.ipv4.ip_forward = 1

Finally, we need to set up the usb0 connection.

ln -sf /etc/init.d/net.lo /etc/init.d/net.usb0

Then edit '/etc/conf.d/net' and add

config_usb0=( "10.1.0.1/24" )

Now you can

/etc/init.d/net.usb0 start

When ever you want to activate the connection to your GP2X. You can automate it with rc-update, but the connection may not work if the GP2X isn't plugged in before net.usb0 is started. Your millage may vary. But it's easily restartable :).

Preparing the media

We will be installing onto an SD card because the NAND on the GP2X is just about full, and we don't really want to mess with it anyway. We will use the ext2 file system because it's light, but provides all the features any UNIX like OS needs (unlike FAT which most glaringly doesn't support file permissions or links).

First we format the SD card:

mkfs.ext2 /dev/sda1

/dev/sda1 being the devices for the SD card on my computer. Check first before formating that you aren't formating your sata harddrive or something.

There are a few ARM Gentoo stage 3 tarballs floating around.

• ARM and ARMEB uclibc Stage3 tarballs for 2005.0 and 2005.1
• ARMV4L (and glibc) Stage3 tarballs for 2005.0 and 2005.1
• ARM (and glbc) Starge3 tarballs for 200405

Since the GP2X runs glibc, I figured that we didn't need the ultra embedded images with uclibc. So I opted for the ArmV4L (glibc) images from 2005.1. 'uname -a' on the GP2X reveals it is in indeed an ARMV4L CPU.

I made a 'gentoo' directory on the SD card (because you don't want to mix GP2X things and Gentoo things) and put the stage3 tarball in it. Then I untared it.

Volia. That's sort of it actually. You now have a Gentoo chrootable environment on an SD card. But we're not really done yet. We need to initialize it, and get it ready for use, and there are a few more things to be done to the GP2X to make it ready. So don't unmount that SD card yet.

The GP2X Linux is based around a limited version of busybox that lacks a few essential (IMHO) utilities. Among them is chroot. Thankfully I was able to dig up a copy of chroot for the GP2X. I grabbed it from the 'GPE for GP2X' package. Unfortunately it is statically compiled so it's 2.3MB. Still, it does the trick. I put it online by it self at ftp.mindstab.net/gp2x/chroot.static for use.

Note: I'm trying to get a dynamic version of chroot for the GP2X. I have the GP2X SDK installed and can cross compile for the GP2X. I tried using chroot from coreutils but I can't get it to crosscompile properly. It still seg faults. It'd probably be better if I could track down the source to a stand alone version of chroot. Help would be appreciated.

I made a 'gp2x' directory on the SD card and tossed chroot.static in there (see, aren't you glad you didn't use the whole SD as the Gentoo root?). Now we are just about ready.

Networked File Systems

SD cards don't have the hugest life spans. Lots of writes can reduce those lifespans. So it makes sense that if we can, we should farm out directories with lots of write to computers with real harddrives that can handle them. Also, if we have directories that we don't often need but are huge, we should farm those out to. This is where networked file systems come in. We're going to at least get /usr/portage to be on some other machine and just mount it over the network to our chroot Gentoo environment to save on space.

Samba for the GP2X

Get the Samba package for the GP2X from www.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,8,1478.

Now we install it to the GP2X's root ('firmware'). This will take up about 2.2 MB of space, which the GP2X's NAND (where the firmware/Linux is installed) can spare. The package is a zip and the GP2X doesn't have unzip, which is slightly annoying. They recommend turning the GP2X's samba server on, mounting it, and unziping the packge to the root. This will work fine. I on the other hand unziped the packages to a directory on the SD card ('samba') and then put the SD card in the GP2X. Once in, I telneted onto the GP2X and copied all the files over to the root:

cp -r /mnt/sd/samba/* ./

(But that is slightly getting ahead of ourselves because we haven't put the SD card in the GP2X yet and it doesn't automount ext2 partitions, so if you are using this method you may want to jump ahead and then come back.)

To mount samba partitions the samba module has to be loaded on the GP2X

modprobe smbfs

Then you can mount directories as easy as

smbmount //10.1.0.1/portage /mnt/sd/gentoo/usr/portage

Again, slightly ahead of ourselves, but you get the idea.

Samba server Quickie

Now the GP2X can mount Samba file systems but we need to export some for that to be of any use. Install samba

emerge samba -va

On your computer and also add support for it to your kernel under filesystems->networked filesystems. You'll need server support.

Then edit '/etc/samba/smb.conf' and add something like the following

 hosts allow = 10.1.0.

...

[Portage]
path = /usr/portage
comment = Portage
available = yes
browsable = yes
public = yes
writeable = yes

Then turn the sambe server on with

/etc/init.d/samba start

and automate samba server starting with

rc-update add samba default

If you want to use NFS on your computer to export /usr/portage, you can get the required NFS client package for the GP2X at archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,42,1880.

Chrooting the Gentoo environment

Now we have everything in place to use our Gentoo environment. So, put the SD card into the GP2X. The GP2X doesn't automount ext2 fire systems, only FAT. That's okay. Create a script to do it for you because it's slightly a hassle.

/root/mount.sh

#!/bin/sh

mount /dev/discs/disc0/part1 /mnt/sd

Then run it. Now the SD card is mounted.

Now we have a Gentoo chroot ready for us and we can parallel the Gentoo Handbook for how to get into it.

Copy '/etc/resolv.conf' into the chroot's /etc ('/mnt/sd/gentoo/etc'). You'll only need to do this once. Now the chroot knows where to look for DNS info.

Next we copy '/lib/libiconv_plug.so' into '/mnt/sd/gentoo/lib'. I'm not 100% sure why, but libiconv is some extension for glibc and since the GP2X uses it, if the chroot environment doesn't use it, every command throws a harmless but annoying warning

ERROR: ld.so: object '/lib/libiconv_plug.so' from LD_PRELOAD cannot be preloaded: ignored.

Now the environment is ready to be chrooted. We'll use a small script to automate the few steps we need.

/root/chroot.sh

#!/bin/sh

cd /mnt/sd/gentoo
mount -t proc none proc
mount -o bind /dev dev

/mnt/sd/gp2x/chroot.static /mnt/sd/gentoo /bin/bash

umount dev
umount proc

cd  /root

Finally, before chrooting, we'll want to setup the remote portage directory.

smbmount //10.1.0.1/portage /mnt/sd/gentoo/usr/portage/

Now we can chroot to the environment.

/root/chroot.sh

Once in the environment, it's common practice to

env-update
source /etc/profile

Now the environment is initialized and you can do what ever you want. We don't really have to install anything or make the system bootable, because that's what the GP2X firmware is for. We're just hijacking it to jump start our more powerful environment.

Most likely you'll want to install more software. That's why we picked Gentoo, because it has more software available for it than the GP2X currently. Still, you'll probably want to edit '/etc/make.conf' and remove some flags, especially ones related to X.

/etc/make.conf

...
USE="-alsa -X -gnome -qt -qt3 -gtk -gtk2"
...

Also, before you can emerge anything, you'll need to set up your profile:

ln -snf /usr/portage/profiles/default-linux/arm/ /etc/make.profile

Now you are ready to emerge software.

Note: Software installation is currently not recommended at this point. Compilation takes place at '/vat/tmp/portage' which is on the SD card. This will start to take it's toll on the SD card. I attempted to get /var/tmp/portage to also be a Samba mount and succeeded as far as I could mount it remotely, however, portage complained it could not chmod the directory appropriately and thus failed. Until I can get this working I'm not too eager to emerge much software and would recommend you also take it easy until you can successfully get /var/tmp/portage remotely mounted. Suggestions would be appreciated.

Crossdev

Another way to install software on the GP2X is to cross compile it, which is compiling it on another computer, for ARM, and then package it (yes portage supports binary packages). There are some difficulties which I'll outline, but this method should be possible at least.

You should start by reading www.gentoo.org/proj/en/base/embedded/cross-development.xml. It's a comprehensive run down of crossdev, a Gentoo app to help setup a cross compiling environment. It's what you would use to get the tools you need to cross compile for the GP2X. It also goes over packaging something for another computer for easy deployment. It's required reading.

I've started playing around with this so I have some pointers for anyone else looking to try it. The GP2X funs Linux 2.4.25, but the closest matching kernel in portage is 2.4.26-r1. Use it. The Linux chroot has glibc-2.3.5 but that doesn't work with crossdev, go with 2.3.6-r5 at the least. The chroot also has gcc 3.4.4, but that again doesn't play nice in crossdev, use gcc-3.4.6-r1 instead. My final crossdev command looked like

USE="-*" crossdev -v --libc 2.3.6-r5 --gcc 3.4.6-r1 --kernel 2.4.26-r1 --ex-gdb --target arm-unknown-linux-gnu

When setting up your 'make.conf', the architecture of the GP2X you'll want to use in CFLAGS for -mcpu and other tuning arguments is 'arm920t'.

I was able to get crossdev installed, but using xmerge, I was unable to then compile anything, instead I kept getting 'C compiler cannot create executables.' errors.

Also, the crossdev solution seems slightly more geared towards more embedded devices where you will be creating a whole environment in one go and then doing something like flashing it onto the device. It feels less suitable for package by package software installation (by proxy) for the GP2X. PArtly because you'll have to keep track of all the dependencies installed and package those too and install then on the GP2X. Another problem that then creeps up is that since hte GP2X has a Stage3 install, it already has lots of software, but the crossdev environment has none, so it will compile newer versions of everything for it self. It does seem to start to become a bit of a hassle and mess.

Conclusion

Well, I got a chrootable Gentoo environment setup on the GP2X. That's pretty impressive. The only hitch is that I currently don't feel comfortable installing (emerging) software due to the adverse effects it might have on my SD card. But there are options from here. You could set up a cross compilation system, fairly easily accomplished with crossdev, and cross compile packages for the GP2X on a computer and then just install the precompiled packages. This may end up being more effort than it's worth, see above. Also, research further on how to get portage to play nice with samba mounted /var/tmp/portage.

Also, as an after thought, you might want to take the SDL libs for the GP2X and untar them in the chroot environment and emerge --inject SDL. It's possible you might be able t install some SDL applications then. Or at the least you should be able to write your own.

Finally, I hope this ends up being a useful tutorial/howto for anyone out there interested in any of the topics covered.

Reference

• Gentoo ARM Handbook
• Gentoo Wiki: HOWTO Setup a home server (for iptables and NAT)
• GP2X Wiki
  • Samba for the GP2X
  • USB Net on Linux
• GP2X File Archive
  • Samba for the GP2X
• Gentoo Cross Development Guide
• crossdev

Well, I have some back logged posts that need cleaning up because they are currently info dumps mostly, but the important thing is I've been busy with my GP2X. And I've been compiling some simple utilities for it. Turns out that the devkit I installed is ok, in that it compiles ARM apps, but it isn't specific to the GP2X and in fact has glibc 2.3 where as the GP2X has glibc 2.2, so everything has to be compiled statically, which sucks because the GP2X doesn't have much in the way of harddrive space. So I'm installing the official SDK now. Hopefully that will make things better. Then back to working and then cleaning up the notes I have.

So the ftpd on the GP2X doesn't appear to sync when transferring large files. It just stalls. How do I know? I was trying to transfer a 108 MB stage3-armv4l-2005.1.tar.gz to my 1 GB SD card in my GP2X (located at home) while I was at school. I couldn't very well reboot the GP2X into USB storage device mode so I tried to make use of FTP server, but it kept stalling. After a bit of experimentation I guessed that the FTP wasn't syncing the FAT filesysem on the SD card. I was proved right when in a telnet session I ran

while [ 1 ] ;do sleep 2; sync; done

and the FTP transfer then went to completion.

Well, following instructions at the GP2X wiki, I first got TCP/IP over USB going and was able to telnet and ftp onto the GP2X. I had to add a few modules to my desktop's kernel like USB->USB Gadet Support -> Ethernet Gadget, and USB -> Network Adapters -> Host for RNDIS. Then it was as easy as turning it on on the GP2X and

ifconfig usb0 up 10.1.0.1

on the desktop and we were a go.

Next I setup a development environment and was able to compile a simple hello world program,

/usr/local/devkitPro/devkitGP2X/bin/gcc -o hello hello.c

ftp it to the GP2X, and run it there. It's a start.

References

• GP2X wiki
• IP Over USB
• USBNet on Linux
• Setting up a development Environment (Linux)

I have a first edition GP2X [Korean Manufacturer, UK Site]. It's basically a ~200MHz ARM processor with 64MB Ram and SD Card slot handheld device. It was loosely designed to play games and media (videos and music) and run emulators. It runs Linux for an OS. They now sell a Breakout Board which you can plug into it which has 4 USB ports, RS232, Audio and Video out & Jtag. I plan to order one shortly.

My desire is to turn my GP2X into a robot, that is optionally remote controllable from a computer. Getting it on Wifi via USB shouldn't be a problem for me. What I'd like is some advice on where I should look for getting it hooked up to some kind of movable body and what sensors might be appropriate.

Mobility
Initially I'd like it to be able to drive around my basement, which is mostly flat and carpeted, but has two ~10cm steps up to slightly raised levels. It would be nice if it could manage these steps but I don't really see how to do that practically or cheaply.

Sensors
Simple vision should be accomplished with a USB webcam of some sort. But I'm also interested in having better and more sensors, like range/depth sensors, or scanners. Also, I'm interested in Internal Navigation Systems if anything can be done on the cheap (gyros, speedometers, etc).

Power
The GP2X can run off of 2 AA batteries, but that probably won't be enough for everything plugged into the Breakout Board. The GP2X can also run off of 3.3V DC power at 1A. The breakout board also has a power input. And finally the engine/motor will need power. Also, if at all possible, it would be nice if the power solution were easily chargeable via the robot driving into some kind of power up dock station.

Why?
I'm not nearly as interested in the hardware side of this as I am the higher level programming side. I'm much more interested in starting to program something that can drive the robot. Of course thats why I need a robot in the first place. :)

Budget
I don't have too much to spend on this as I'm just about to come to the end of my employment and I am a student. So cheap solutions are a real winner here. More expensive solutions might mean it simply takes me longer to acquire all the parts.

Thank you for your time and help.

I'm looking to buy an MP3 player to replace my Creative Muvo with 128MB. Or to replace my GP2X, although my GP2X might be more viable if I would open it up and disable the speakers. The GP2X's problem is it's audio jack sucks and keeps telling the speakers to turn on when I still have the head phones in so I'll be on a bus or in a library and suddenly making far too much noise. On the plus side, the GP2X spoils me by having MPlayer on it so I can watch many videos with out converting them.

As for a replacement, I've been looking very much at Cowon's X5. It's gotten very positive review, especially by Linux users, and it looks close to perfect. So close I wish they could just tweak it, but I may yet settle for it.

My requirements in some sort of order for a replacement MP3 player:

1. Linux compatible: This is a must since I only use Linux. The best method for this is things that just plug in via standard USB cables and show up as mass storage devices, like my creative Muvo. The X5 does this but has to have an adapter plug into the bottom of the unit first to give you the USB port. A tiny bit lame and it means you have to lug the adapter around if you want to plug it in anywhere (and to recharge it) so don't loose it. :/
2. OGG Vorbis: A good sized chunk of my music is in OGG Vorbis format and I am not transcoding it to listen to it on the go.
3. Shuffle: I'm sure everything has this now, but it's the feature I wish the most my Muvo had.
4. Fast Fast Forward: I also wish my Muvo had this. If I download a Lugradio podcast, it is 1 hour and 30 minutes. If I listen to half of it on the bus that means that I would like to skip to half way through on the ride home rather quickly, and not say in the ~10 minutes it takes my Muvo going at slow fast forward.

Those are the key features I really need. The X5 and several other players, like iRivers, should cover those. Now we get onto the wish list.

• Battery
  • The jury is somewhat out on whether lithium ion or NiHM (AA or AAA) batteries are battery. I think I am probably a little partial to the MiHM variety because I can carry spares and replace them on the go, but those are mostly only seen in flash players, not hard drive players.
  • Battery life: I'd like the most I can get :)
• Video: The GP2X has spoiled me. And sadly, the X5 is so close here. It can do MPEG4, but only ones transcoded specifically for it in it's Windows only JetAudio. I could probably run it in wine, but drag and drop is so much nicer than drag-transcode-drop. It'd be nice if the player just dropped frames for me ;).
• Space:
  • Lots (harddrive): I'm kind of starting to like the idea of a harddrive player where I could carry all my music and have some videos all at the same time. And as a mass storage device then I could also ferry other data on it at times too. Handy.
  • SD Cards: Some of the flash players out there augment their smaller capacity with an SD card slot (like my GP2X, or San Disk's players). This is pretty cool.
• Size: I'd almost consider a full blown PVP except that it's kind of expensive. I could buy a computer for that price. Also, Just a bit too big. Smaller is better. Pocket sized is good. Or something I can strap on somewhere.

So there you have it. I'm kind of demanding. And I may settle for an X5, or possibly get a cheaper iRiver as a stop gap and hope Cowon improves the iAudio in the coming year.

Thoughts, suggestions, things I over looked?