After successfully configuring Open Embedded, the build environment for OpenMoko, we want to try our custom built kernel and rootfs. Although, we will be using Micro SD card to run our custom builds rather than the flash still we will backup the factory default images because you never know when you brick it in stupidity or frustration.

Flash memories are fast but there are two things that need to be kept in mind 1) Flash has a limited age with respect to the number of flashes (maybe a 100,000) 2) And we only flash those images onto the flashes, which are satisfactory for usage and are not experimental. Micro SD has one limitation that it is slower in performance compared to Flash memory. So if you live near an OpenMoko store it’ll be better to use the Flash off and on but if you live in Peshawar than you should prefer to use the Micro SD card.

Backing up the Original Images

(This has been adopted from to suit newbies like us)

There are two ways to backup:

  1. DFU-Util (The official and buggy way of doing it)
  2. Common Sense


(Adopted from

DF stands for Device Firmware and U stands for utility. DFU-Util is a host implementation of Universal Serial Bus Device Firmware Upgrade protocol. The device side is implemented in the uBoot of OpenMoko.

  1. transfer and flash partitions in NAND.
  2. transfer anything into RAM
    • this can be used for fast development cycles of low-level code such as kernels without flashing them (Haven’t tried it yet)
  3. Read out the current internal NAND
    • this is an easy and efficient way of doing full backups of your phone

If you are not sure what NAND and NOR are the read

Installing DFU-Util
sudo apt-get install libusb-dev autogen pkg-config autotools-dev autoconf automake

Fedora Core
yum install libusb-devel libusb-static

Or download a binary for Linux from

Or if you have built Open Embedded using the mokoMakefile then you should have the binary in <$MOKODIR>/build/tmp/staging/i686-linux/usr/bin

Using DFU-Util

Now that we are ready ensure that you are using the USB Data Cable (stay away from USB HUBs) and you are logged as root on your host PC. Power off the phone. Now hold the AUX (top left of phone) button and then hold the power button until the NOR boot menu appears.

./dfu-util -a kernel -R -U original-kernel.bin
./dfu-util -a rootfs -R -U original-rootfs.jffs2
./dfu-util -a splash -R -U original-splash.bin
./dfu-util -a u-boot -R -U original-u-boot.bin
./dfu-util -a u-boot_env -R -U original-u-boot_env.bin

If you are successful then you are very lucky :) We were not as lucky as you were and we had to do it over and over again and still we had a corrupt kernel in our backups.

Using Common Sense


Recluze: I only remember the rootfs part so can you plz complete this….

Flashing kernel and rootfs onto Micro SD Card

(Adopted from

Preparing the SD card

We got our SD card plugged in to our laptop via USB interface and used the fdisk utility to partition it. On your system it might look like:

[user@system]$ fdisk /dev/sdb0
Command (m for help): d
  Selected partition 1
  Command (m for help): n
  Command action
     e   extended
     p   primary partition (1-4)
  Partition number (1-4): 1
  First cylinder (1-983, default 1):
  Using default value 1
  Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
  Command (m for help): n
  Command action
     e   extended
     p   primary partition (1-4)
  Partition number (1-4): 2
  First cylinder (18-983, default 18):
  Using default value 18
  Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
  Using default value 983
  Command (m for help): w
  The partition table has been altered!
  Calling ioctl() to re-read partition table.
  Syncing disks.

When we got over this the /dev/sdb was partitioned into /dev/sdb0p1 and /dev/sdb0p2. Now we needed to firmat it accordingly. The partition which will hold the kernel needs to be in vfat due to some limitations that can be figured out from the wiki by the curious and the partiotion holding the rootfs needs to be in ext2/ext3.

mkfs.vfat /dev/sdb0p1
mkfs.ext3 /dev/sdb0p2

Now to copy the relevant stuff onto these we need to mount them and perform the copying or writes.

mount /dev/sdb0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf gta02-custom.rootfs.tar.gz OR copy contents of rootfs to the partition.

mount /dev/sdb0p2 /mnt/mokoKernel
cp uImage-gta02-custom.bin /mnt/mokoKernel/uImage.bin

umount /mnt/moko
umount /mnt/mokokernel

UBoot Menu Entries

We need to boot a kernel and provide a root filesystem to it at boot time. UBoot functions as a boot-loader similar to GRUB. It loads the kernel into memory and then passes a list of parameters known as kernel command string to the kernel. Path to root filesystem is a common command string. If you have experienced boot entries in GRUB then we have similar (almost) entries in uboot.

Uboot menu entries are defined by environment variables named menu_X, where X is a number. The value of this variable is a string, <label>:<commands>, where label is the text shown on the screen and commands is a sequence of u-boot commands (delimited by ‘;’ characters) to be executed when the menu item is selected.

Note: When entering a string of commands, the ‘;’ and ‘$’ characters must be backslash-escaped (“\;” and “\$”).

Add a uboot entry

By default both NOR and NAND uboots have an entry for kernel on vfat and rootfs on ext2. If you have this combination then you don’t need to read the following mess. Otherwise here is what you need to do.

To get to the boot promt hold the AUX and power button. Select “Set console to USB” to enter into the boot prompt. The other way to get to the boot prompt is through serial console via Debug Board but we are afraid that we have not yet experimented with that due to pushing deadlines :o )

Now that we are inside the uboot and have the prompt the first thing to do is to set the timeout environment variable because no matter what you are doing the uboot will continue booting after default of 60 seconds.

setenv boot_menu_timeout 99999

This should be enough for us, I guess :o )

To see what the boot environment has


We had vfat for kernel and ext3 for rootfs so this is what our entry looked like

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

Enter “printenv” to verify and then “saveenv” to save your changes.

Forgot the restart or power off command! Then next time you get to your NAND uboot select the entry that you made earlier and thank us for this tutorial because it takes ours for a newbie to get relevant stuff from the wiki.

3 Responses to " Backing up OpenMoko FR before bricking it and getting your custom kernel and rootfs onto it … "
September 14th, 2008

Contents under DFU-UTIL sub heading needs to be verified because am not sure if I am taking it correctly.

I hope I did not miss anything in uboot menu setup.

Computing Tips
June 23rd, 2009

I found your blog on google and read a few of your other posts. I just added you to my Google News Reader. Keep up the good work. Look forward to reading more from you in the future.

October 6th, 2009

hi i m hassan working in NEXGIN at fast
kiss ke pass packup file hain kernal,bootloader,rootfs plz mail me at
plz guys help me

Leave a Reply