Overview of my progress on the Zipit ARM board.

* Links to binaries and sources coming soon!

27 november 2013 (SD iz2s FAT starting point here)

• qemu-user sandbox working
• starting point: 2.6.29 stock and blob kernel with jffs + iz2s FAT

28 november 2013 (SD iz2s FAT here)

• gawk (gnu awk) 4.1.0
• bison 3.0
• perl 5.18.1
• m4 1.4.17
• python 2.7.6
• tcl 8.6
• openmsx 0.9.1 (not optimal and no sound, but plays well)
• gcc 4.2.4 (untested, uninstalled but compiled) 

29 november 2013 (SD iz2s FAT here)

• binutils-2.23
• gmp 5.1.3
• mpfr 3.1.2
• mpc 1.0.1
• uClibc-0.9.30.1 (useless but working)
• openmsx 0.9.1 compiled with 2.4.2, this time compiled with all asm intact (untested but compiled without errors)
• broken GCC installs => 4.3.0, 4.8.2, all same errors

30 november

• GCC 4.3.0 (target=arm-linux-uclibc)

2 december

• For lack of anything else like a decent package manager, I restored my old tool for work similar to this here.

TODO compile:

• Clean up, the image is *huge* now
• Dosbox (some version)
• gcc 4.8.2 gcc.some.earlier.version
• Fix mesa (see 1/12)
• ruby 2.1
• php/nginx
• breaking up the image into a very tiny FAT dir + big ext2
• create a self starting gmenu + wifi etc

It is very annoying compiling stuff for ARM on other OSs, basically because you get mixed up really easily between x86 and ARM binaries. For instance; you need to compile something which embeds TCL as a scripting env; now the ./configure which runs on the x86 part will create a .c file which will be compiled with the ARM compiler after which the ./configure will try to run it on the x86 platform to test it. Which will fail.

Ofcourse there are ways to avoid these issues, but it tends to be messing around with build files, LD_LIBRARY_PATH, C_INCLUDE_PATH and other fun things.

Much easier is using qemu_user.

So following this (continue reading):

http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=5

For Ubuntu:

apt-get install qemu-user
apt-get install qemu-user-static

apt-get install debootstrap

The latter can be fakechroot or whatever you like; didn’t try, but you need a chroot for what I would suggest.

Run;

[ -d /proc/sys/fs/binfmt_misc ] || modprobe binfmt_misc

and then:

[ -f /proc/sys/fs/binfmt_misc/register ] || mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc

Register the arm handler:

echo ‘:arm:M::x7fELFx01x01x01x00x00x00x00x00x00x00x00x00x02x00x28x00:xffxffxffxffxffxffxffx00xffxffxffxffxffxffxffxffxfexffxffxff:/qemu-wrapper:’ > /proc/sys/fs/binfmt_misc/register

Create a chroot (./mychroot for example), mount proc;

mount -t proc mychroot/proc mychroot/proc

chroot mychroot

Run;

[ -f /proc/sys/fs/binfmt_misc/register ] || mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc

again.

Exit the chroot and create the qemu-wrapper binary outside the chroot.

Copy the required qemu binaries into the chroot;

cp /usr/bin/qemu-arm ./mychroot/usr/bin; cp /usr/bin/qemu-arm-static ./mychroot/usr/bin/

Now pack up your entire rootfs (/) from your device (Rasberry Pi etc) to the chroot root, overwriting files in the chroot. Make sure that you don’t have a /usr/bin/qemu-arm-static on your device in the same location.

After you chroot ./mychroot anything you execute in there (mostly ARM files at this point), you will see

strace ./bin/gawk 2>&1|grep qemu

a qemu entry and everything it considers an ARM ELF binary is executed through qemu-arm-static and acts like it would on your device. It is wonderful for compiling things on fast, memory heavy servers and then moving the binary back to your device.