Category: zipit

Zipit exposed (er x-rayed)

Click to enlarge

If you are too chicken to follow my Zipit disassembly instructions but still want to see what it looks like inside the Zipit Z2, here’s your chance.  The metal shield inside the battery compartment makes the motherboard area a bit darker than it would normally be but you can still make it out.

Take a look at how fine the wires in that LCD cable are…  Now you realize why you have to be so careful with it when you open up your Zipit.  The antenna also looks super thin in the x-ray but it’s not really that fine when you see it.

The speaker looks like an all-seeing evil eyeball to me.

At first, U-boot may seem like just a way to load a root file system on your Zipit Z2 but it is capable of so much more.  If you type “help” at your U-boot prompt, you will get a HUGE list of commands.  Some are self explanatory but others are coupled with vague descriptions.  To delve deeper into some of these commands, I did a bit of poking around online.  Before you proceed, please realize that attempting to fuzz memory locations like this could potential result in a brick or hardware damage. That being said, here is a short list of commands I’ve put together that I’ve found useful for exploring the Zipit at the bit level:

MD (Memory Display) – You can use this command with a couple of suffixes.  For example md.b, md.w & md.l all change the way that the output is displayed.  Experiment with those and see which one works best for your purpose.

md 0x40E00000

By default, md will show you several lines of memory starting at the address you type in.  To see the exact contents 4 bytes of memory, you would type in something like:

md 0x40E00000 1

The “1” is an offset value that tells the command to display one 4-byte block.  You can change that to see however many locations you would like.  After you use a value here, it will persist until you use a different value.  In other words, next time you type “md 0x40E00000”  without the “1”, it will show you 4-bytes until you run the command again with a different offset.

MTEST (Memory Test) – Memory test will perform test passes on a specified range of memory using a specified pattern.  For instance, if you want to see some interesting bits get flipped, type in:

mtest 40E0000C 40E0000D FFFFFFFF

This will fuzz the range of memory from 40E0000C-40E0000D with the specified test pattern.  I believe the LCD or power saving features may live in this range because this command makes the screen flicker.  I’m not entirely sure how the pattern value (“FFFFFFFF”) works but a bit of experimentation and you should be able to figure it out.

NM (Memory Modify) – This command allows you to selectively flip bits of any byte in memory.  For instance, if you run:

nm 40E0000C

You will see something similar to:

40E0000C: 0000032a ?

That is a prompt that is showing you the existing contents of the 4-bytes.  If you type in “FFFFFFFF”, that will set ALL of the 32-bits(4-bytes) to the “on” position.  In this case, it makes the screen dimmer.  The line will increment and ask you again what you would like to change to.  This time, if you type “00000000”, it will turn ALL 32-bits off and the screen will go to full brightness.  If it’s not already obvious, ALL of those bits and bytes don’t control the screen brightness.  You can start to narrow it down by flipping the nibbles(half-bytes).  Starting with “F0000000”, “0F000000”, “00F00000” and so on will narrow down which byte the brightness lives in.

It appears to be in the “00000F00” nibble.  So now it’s time to start flipping the bits.  The individual bits are at 1, 2, 4 & 8.  So something like “00000100”, “00000200”, “00000400” etc will track down the specific bit.  Turns out that it’s the most significant bit of that specific nibble.  So in binary, it looks like “1000”.  That translates to 8 in hex.  To sum it up, changing between “00000800” and “00000000” with toggle the LCD backlight between bright and dim.

If any of this is confusing, you should read my post on binary to hex number conversion.  Many people seem to think that computers somehow don’t operate on binary logic anymore but an exercise such as this proves quite the opposite to be true.

On the Zipit Z2, you probably don’t NEED to probe around like this since you can download a manual for the CPU and find most of the memory locations in there but if you just want to experiment or if you have another similar undocumented device that you want to reverse engineer, then this is a good way to go.

So you have U-Booted your Zipit Z2?  Great!  Now you are ready to exploit one of the biggest advantages of moving from blob to U-boot…  Building your own kernel.

First off, you need to have built a cross-compiler of some sort to build the kernel.  I have posted directions for my version here in my post about building U-Boot for the Z2.  After that, you will need to make sure u-boot-tools is installed on your system.  On Gentoo you can use portage to install it but you will need to unmask the package.  To unmask that package on Gentoo, add ACCEPT_KEYWORDS=”~x86″ to your /etc/make.conf.  Then type “emerge u-boot-tools”.

Next, download the latest version of the Zipit kernel from here:;a=shortlog;h=refs/heads/zipitz2

To start off, I’m going to use Mozzwald’s suggested .config file.  You will need to rename it .config and put it in the base directory of your kernel.  Next, replace the <base_kernel_dir>/arch/arm/mach-pxa/z2.c with a bleeding edge one if desired.  Mozzwald and Sweetlilmre both have been diligently hacking away at that file so you could ask in the #zipit-dev channel to obtain the latest version or use this z2.c for now.

Now for the fun stuff.  You can use a make menuconfig command as follows to add your own customizations to the kernel:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig

Now it’s time to build the new kernel:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j9 uImage

Now, if you built a modular kernel, you will need to build the modules and stick them somewhere:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/where/to/drop/modules modules_install

After this is done, your new kernel should be sitting there for you ready to go in the arch/arm/boot directory and your modules are wherever you put them.  Just copy the uImage and modules to the appropriate locations on your Zipit’s SD card and you will be good to go.

The latest version of U-Boot(as of 8/19/2010) adds the ability to use the screen and keypad on your Zipit Z2 to display a console(albiet sideways).  U-boot also allows a splash screen on the LCD during boot up if a sideways console is not useful to you.  Personal I like the console on my serial port anyways so a nifty splash screen would be a nice touch.  Since I have a serial mod, I will provide instructions to add the splash screen via ymodem.  First thing is first, you will need a bitmap file that is 320×240 and rotated 90 degrees counter-clock-wise.  It also has to be 8 bit color depth.  In order to save a BMP as an 8-bit file in Photoshop, you will need to change the mode to “indexed color”.

From your serial console, type in the following command:

loady 0x5c000000

Next, you will need to write that file to memory.  Use the flinfo command to make sure your memory matches mine.  The last two sectors are where we will store your file.  Make sure your file won’t take up more than two sectors(it shouldn’t).  The bmp file I’m using is only 79k or so which uses only one and a third of a sector or so.  After you’ve checked your memory, use the following command to move your bitmap to a permanent location:

protect off all; erase 0x7e0000 +20000; cp.b 0x5c000000 0x7e0000 0x13034

The last number 0x13034 is your file size in hex.  If you look up the screen a bit, your loady command should have outputted a file size in hex and decimal.  Use YOUR file size instead of mine unless you are using my file of course.  Now you can test your image:

bmp display 0x7e0000

Cool, eh?  Now it’s time to make it load automagically on bootup:

setenv splashimage 0x7e0000


Now when you reset, you should see your splash screen.

Since there is no central repository for fresh U-Boot binaries for the Zipit Z2, I decided to build my own u-boot.bin from source.  Before I could do this, I needed to build a cross compiler for the arm processor.  This is something I’ve always had trouble with on Debian systems but this time I used Gentoo and everything worked flawlessly.  Luckily Marex left me with some very helpful hints on how to get the job done.  First, you’ll need to set up a cross compiler if you have not already:

emerge crossdev

You’ll need to add the following lines to your /etc/make.conf:


Don’t forget to make the following directory since that is where your new tool chain is going to live:

mkdir /usr/local/portage

Now it’s time to build your tool chain.  This will take quite a bit of time.

time crossdev -S -t arm-linux-gnueabi

After all of that, you should be ready to build your u-boot.bin.  First you need to grab the latest snapshot from;a=shortlog;h=refs/heads/devel.  Go ahead and unpack the file in your home directory:

tar -xvf u-boot-pxa-*

cd u-boot-pxa

Next you need to run the following command.  Double check and make certain that you have a space between the “…gnueabi-” and the “zipitz2…” parts.

make CROSS_COMPILE=arm-linux-gnueabi- zipitz2_config

Lastly, you can build the u-boot.bin firmware file with this command:

make CROSS_COMPILE=arm-linux-gnueabi-

You should now have a working u-boot.bin file in the ./u-boot-pxa directory.  With that file, you can follow these instructions to upgrade U-boot on your Zipit Z2.  As usual, thanks to Marex for giving me the proper hints to make this happen.

Building OpenEmbedded for the Zipit z2

OpenEmbedded was the original starting point for unlocking Linux on the Zipit Z2.  Nowadays there are plenty of userlands floating around out there but if you want to take things even further on your Zipit, you’ll probably need to build OE.

OpenEmbedded will allow you to compile packages and actually build your own custom rootfs from the ground up. You’ll be able to use your fastest desktop system to cross compile packages for your zipit and even build a custom kernel for your zipit as long as you are using U-boot.

To get started I’m simply going to expand on Sweetlilmre’s directions.

  1. Make sure you have like 80 gigs free on your hard drive.  I would suggest using Debian or Ubuntu as your base OS for these directions.
  2. At command prompt, go to your home directory and type “svn co”
  3. CD to the OE directory
  4. type in “make” and wait…

At this point, you may be getting a list of dependencies that are broken so you might need to fire up apt-get and get some packages.  After you are able to successfully “make”, then you should be ready to get started.  (That’s right, that was just the beginning)

  1. Run “./”  This script sets up the environment to start building.  It should change your bash prompt to a green one.  That alerts you that you can start bitbaking.
  2. Now you need to build the base-image so run “bitbake base-image” and wait…

Many hours later, your base-image should be built and ready to go.  Just make sure you have no errors waiting for you on the screen.  If everything went well, you should have a rootfs and kernel waiting for you in “~oe/zipitz2-tmp/deploy/glibc/images/zipitz2”.  There should be file called base-image-zipitz2.tar.  You will need to untar that file to a blank sd card formatted ext3.  Use the “-pxvf” switch with tar so that the permissions are preserved.

After that is done, you should be ready to boot your new minimalist userland.  If you are using U-boot, you will need one additional step.  Copy this uboot.script file to the /boot directory on your SD card and make sure your U-boot environment variables are set up similar to how I have outlined it in this post.

Apparently this distribution has both serial console and local support built in out of the box.  When you boot up over the serial port, you will be presented with a screen that looks like this:

There is no root password.  Just type in root and hit enter.  You’ll be logged right in.  Now that you’ve gotten this far, you should be ready to follow Hunter’s directions to build dosbox or maybe something even more exciting.  Post in the comments and let me know.

If you are interested in buying your own Zipit to hack and you like the information on my site, please buy your Zipit using this link and support my site. You won’t find them anywhere cheaper than that anyways.

Side-track running on a U-booted Zipit

Irongeek’s side-track Linux was built around a semi-stock Zipit Z2.  In order to run side-track, you have to re flash the Zipit with a hacked 2.6.29 kernel but you keep the original blob bootloader.  The problem with keeping blob is that it doesn’t allow you to use any other kernels and things have come a LONG way since 2.6.29.  U-boot is the future of the Zipit as a hacking platform but right now it’s still a short bit away from being a seamless process.  One of the problems is that some userlands such as side-track will no longer act as expected.  There are a few things that will be tweaked in order for it to run at all.

For starters, you’ll want a uImage and uboot.script that will be good enough to boot with.  You will put these files in your /boot directory on your sidetrack sd card.  As stated in one of my other posts about U-boot, you will need to make sure this line is set as an environment variable in U-boot:

bootcmd=if mmcinfo && ext2load mmc 0 0xa0000000 boot/uboot.script ; then source 0xa0000000 ; elif mmcinfo && fatload mmc 0 0xa0000000 uboot.script ; then source 0xa0000000; else bootm 0×60000; fi;

These things will probably make your system bootable at least.  When you boot however, you will not be able to do anything because the keymouse driver is broken under the new kernel.  Mozzwald and some others are looking for some solutions to this problem but for now, we should just disable X so we can try out the system a bit and see what else is broken.  To disable X in side-track, edit /root/.bash_profile.  Comment out the following line:

startx &>/dev/null —

If you want to clean up all the garbage messages on the console, also comment out the 3 line before startx and 6 lines after it since none of them are needed now either.

If you have a serial port, you will also want to enable the console access so you can log in from your desktop and type away.  To do so, you will need to fix this line in /etc/inittab to look like my screenshot below:

This gets you in a minimally running state where you aren’t locked out of the console anymore.  Then you can move onto other tasks such as making the font readable since the kernel sets the font size down to extreme eyes training levels.  I’ll leave that discussion for a different day.

If you are interested in buying your own Zipit to hack and you like the information on my site, please buy your Zipit using this link and support my site. You won’t find them anywhere cheaper than that anyways.

When U-boot was presented to me, the default behavior is to attempt to read your SD card and look for uboot.script on the first partition of the card which is expected to be vfat.  I found this to be a pain because so far all the user lands that I have don’t have a vfat partition as a primary.  Usually the first partition is your main user land partition and it’s generally ext3.  I wanted to tweak U-boot to be able to boot from a kernel and uboot.script that is placed in the /boot directory in whatever userland I’m using.  Marex suggested that it would be easy enough to use logic to accommodate both setups.  With a bit of his assistance, I was able to come up with a new environment variable that worked. The old bootcmd variable looked like this:

bootcmd=if mmcinfo && fatload mmc 0 0xa0000000 uboot.script ; then source 0xa0000000; else bootm 0x60000; fi;

If you break this down, you’ll see it looks for the uboot.script on the root directory of the first fat partition on mmc 0.  If it finds the uboot.script there, it loads it and executes the commands contained within it.  If not, it continues and boots whatever is sitting at the 0x60000 location in flash memory and uses the environment variables currently loaded in u-boot itself.  If there is nothing there, it fails.  My new bootcmd variable looks like this:

bootcmd=if mmcinfo && ext2load mmc 0 0xa0000000 boot/uboot.script ; then source 0xa0000000 ; elif mmcinfo && fatload mmc 0 0xa0000000 uboot.script ; then source 0xa0000000; else bootm 0x60000; fi;

This one will first look for the uboot.script file under the /boot directory on the first ext2/3 partition for the uboot.image on the first ext2/3 partition.  If it is not there or the partition is not ext2/3, it tries to look for the file on the first vfat partition.  If it can’t find that it will try to load a kernel that is in your flash memory if it exists.

Of course the old uboot.script does not work with the ext2/3 configuration described above.  I went ahead and tweaked the uboot.script.base file as follows:

if ext2load mmc 0 0xa0000000 boot/uImage; then
setenv bootargs console=tty0 console=ttyS2,115200 fbcon=rotate:3 root=/dev/mmcblk0p1 rootdelay=3
bootm 0xa0000000;

I saved it and then ran ./ to make the uboot.script which is actually a binary file and then copied the uboot.script that was created to /boot on the proper SDcard.

To build a new uboot.script file, you need to:

apt-get install uboot-mkimage

the uboot.script.base and can be found in this file: z2-uboot-06262010.tar.gz

Note: this file is outdated but does contain the script to rebuild uboot.script.

Earlier today, Mozzwald helped me flash a default static-linked kernel into the flash ram.  This allowed me to boot side-track under U-boot for the first time since upgrading to U-boot without ANY changes to side-track.  Unfortunately, the mouse driver is broken under this later linux kernel and will probably need to be recompiled.

I could go through the process of flashing that static kernel into memory but I don’t feel comfortable doing so because it’s not very streamlined at this point.  If you are interested in the instructions, just speak up on the #zipit channel on freenode and someone will probably be able to help you through it.

using ymodem to transfer the new firmware

Warning: This can brick your Zipit Z2 if you don’t follow the instructions precisely.  Even if you do follow the instructions precisely, you might brick your Zipit.  This proceedure only works if you already flashed U-boot onto your Zipit

Read all of the instructions completely before attempting this procedure.

With that out of the way, I’m going to upgrade to a newer version of U-boot that Marex provided me by following his instructions. This newer version will boot from an SDHC card.

First, you need a serial mod to use this method.  This is the safest method of upgrading U-boot since you are actually testing the firmware before you flash it.  There is also a method to update U-boot from Linux that I will post later.  Download the newer version of U-boot from:

The md5sum is e82ce84f11c1fa50106f5c005bf912f7.  Do yourself a favor and actually check the md5 hash.  It’s very important that this file didn’t get corrupted in transit.

Here are the instructions:

1) enter serial prompt on the Z2 in U-boot (best is to use minicom — for ymodem)

2) Type the following command and then send the new U-boot bin file via YMODEM

loady 0x5c000000

3) Run the new firmware with the following command and the Zipit will reboot.  Hit a key to cancel auto boot.


go 0x5c000000

4) after you run “go 0x5c000000”, the new bootloader is now started and you need to cancel auto-boot … you’ll get a new prompt (of the new bootloader) … DO NOT TYPE ANYTHING BUT THE FOLLOWING COMMANDS.  If you power cycle the unit before typing the following commands or do any other actions, you will likely brick the unit.

protect off all ; erase 0x0 +60000 ; cp.b 0x5c000000 0x0 0x00020620

5) Type “reset” and pray

Make sure the two numbers match BEFORE pressing enter

Caveats: DO NOT TYPE ANYTHING between step 3 and 4 if you want to reflash. If you just want to test the new firmware out without reflashing, stop at step 3. You can type boot at the prompt and that should show the new functionality and if it works. When you power cycle, the firmware will revert if you don’t complete step 4.  Do NOT run step 4 unless that last number matches as indicated in the picture by the two red arrows.

U-boot seems to recognize my 8gb SD card

Here are a couple of U-boot commands to play with:

If you want to get rid of the “*** Warning – bad CRC, using default environment” message upon bootup, just type “saveenv” at the prompt.

printenv will show you the current environment variables for U-boot

mmcinfo will print information about whatever card is in the SD slot

help should be obvious

reset should be obvious

boot should also be obvious

U-boot booting up my existing 2gb card

Thanks again to Marex for providing me the instructions, firmware and answering my questions.  Follow this link for further information on this version of U-boot.  Follow this link for more general information on U-boot on a Zipit.

If you are interested in buying your own Zipit to hack and you like the information on my site, please buy your Zipit using this link and support my site. You won’t find them anywhere cheaper than that anyways.

Your Zipit looks like this when booting U-boot. No lights, blank screen, no sign of life!

A few words of warning first: The following instructions have been tested by me once and only once.  You stand a chance of bricking your Zipit.  I can’t be held responsible if you brick your Zipit either following these instructions or failing to follow the instructions.  If you brick it, you will either need to build or obtain a JTAG interface to fix it.  You probably should consider doing the serial mod first before you reflash with U-boot anyways just so you can see any error messages on the console if you get stuck.  MY instructions are NOT for reflashing from a stock kernel but there are instructions in the README.  If you haven’t already reflashed to the Open Zipit boot loaders then you will need to follow a different procedure to upgrade to U-boot.  Lastly, you will not be able to use SDHC cards after you upgrade so 2gb will be the limit although I understand there is already a new version of  U-boot which adds the SDHC drivers.  Make sure your Zipit is plugged in and fully charged.  This is cutting edge stuff for the Zipit.  You probably don’t need to go to the trouble and the risk of this procedure to enjoy using your Zipit as a pocket-sized Linux device.  Read this whole post and the README before you attempt flashing U-boot.

With that out of the way, let’s get started.  I’m using Mozzwald’s z2buntu to do the actual flashing of U-boot.  This distribution works well because it doesn’t have X11 on it by default to muck things up.  You’ll need to log in as root or use sudo.  Don’t get too attached to this install because you will be throwing it out the window soon enough.

First you’ll need to wget z2-uboot-06262010.tar.gz on your Zipit.  The md5 hash is c917bfd057e5bfd7e0a50e44e4192d25.  Untar the file, changed to the uboot-rel directory and run:

sudo ./

You’ll see a few weird messages that freaked me out.  They say stuff like /dev/mtdblock0 no space left on device.  Don’t worry about these.  The script writes 0xFF to the flash memory before it done flashes until it runs out of room.   After all this is done, pull out the battery, and remove the AC to clear the ram entirely.  Then plug it all back in.

Here is more weirdness, if you boot up your system right now, there is NO way to tell anything is happening.  It will look dead dead dead.  No lights, no nothing.  The only sign of life you can get is if you push the reset button.  That will cause the keyboard light to briefly flash.  If you have done the serial mod, this would be a good time to fire up a terminal and see if everything went well.  If you hit the reset pin while plugged into the Zipit, you should see this in your terminal:

From here, you can see that U-boot is not finding the kernel partition that it needs to on the flash card.  Also, Mozzwald’s script was supposed to load a static linked kernel into flash that would be bootable by U-boot but something is a little screwy with the flasher script at the moment.  No worries since we can fix that later.  I don’t know much about U-boot but I do know it’s far more powerful than the blob loader I was using.  The difference is that U-boot allows you to boot any properly build kernel that you stick in the primary fat32 partition.  One command I know that you can do is “printenv”.  This will show you current loaded environment variables:

After you’ve tried that out, I’m sure you are ready to make your Zipit actually boot up again.  If you’ve gotten as far as the U-boot shell, at least you aren’t bricked.  If you haven’t done the serial mod, you are probably pissing yourself at this point thinking you probably bricked your Zipit.  Relax, take a deep breath and hit the reset button.  If the keyboard light flashes quickly, you are probably not bricked.  No guarantees though.

You will now need to download Mozzwald’s U-boot ready tarball.  While you are waiting for that, you need to partition a SD card as follows:

  • partition 1: vfat(fat32) 32-64MB (this partition holds the uImage and uboot.script files)
  • partition 2: ext3 for the remainder of the space (this is where your root fs goes)

I used gparted under Ubuntu to complete the partitioning operation since it’s free and easy to use.  Make sure your SD card is plugged in and recognized but unmount it if it’s not already.

After the new partition scheme on the  SD card is created, mount the card and change directories to the mountpoint (/media/z2buntu on my system), untar the filesystem into place with:

sudo tar -pxvf /path/to/z2buntu-uboot-rootfs.tar.bz2

There is another tar file inside of the main z2-uboot tarfile that you downloaded first(z2-uboot-06262010.tar.gz).  The file is called z2-2.6.35-rc3.tar.gz.  Untar that file and then:

cd lib/modules/2.6.35-rc3+/kernel/

You need to copy the uImage file from that directory to the vfat partition on your SD card.  You’ll also need the uboot.script file that lives in the root directory of the z2-uboot-06262010.tar.gz tarfile.  You should now be ready to put your SD card back in the Zipit and boot it up.  If you did everything correctly, it should look like this after a few seconds of being completely blank with no lights on:

More caveats.  To quote Mozzwald, “things won’t work the same anymore”.  You will want to disable your power management scripts for now.  Closing the lid could cause you to get stuck in a blank screen loop.  In most root file systems it just involves commenting out some lines in your rc.local and perhaps making a few other changes.  I would suggest jumping in the /etc/rc.local file as soon as you get booted so that you can tweak the Zipit-specific settings.  The files that I’m linking to above are NOT the newest and latest versions and there are things in them that I know are broken but none of it is unfixable.  I’m providing this set of instructions so people can see that U-boot is still in a very experimental stage.  I wouldn’t not suggest U-boot for 99.9% of the Zipit hackers out there but if you are dying to build your own custom kernel for the Zipit, U-boot is really your only option.

Why would I go to all this trouble to seemingly downgrade my Zipit you might ask?  This brings me one step closer to Zipit nirvana with the Zipit USB mod.  A custom kernel is required to have the USB host drivers in it so this is a necessary evil.  Many thanks to Marex for U-boot, gpsfan for pioneering the USB mod and being one of the early testers/tweakers of U-boot, rkdavis for bricking one of his Zipits trying to upgrade to U-boot, and especially to Mozzwald for putting up with at least 5 pages of questions that I asked him regarding this mod and for providing all of the files I’ve linked to above.  None of this is my work and the credit belongs to them and a few others for pioneering this hack.

If you are interested in buying your own Zipit to hack and you like the information on my site, please buy your Zipit using this link and support my site.  You won’t find them anywhere cheaper than that anyways.

Powered by WordPress. Theme: Motion by 85ideas.