All of the above methods relied on using a serial connection and U-boot in order to reflash your root file system and linux kernel. It is also possible to reflash your root file system from within linux using the mdt-utils package.

The main advatage to this approach is its flexibility. You can use any type of login connection -- ssh, bluetooth, LCD/USB keyboard, and yes even serial!

The downside is that if you make a mistake, the only way to recover is using one of the previously described serial/U-boot methods.

This process is a bit like changing the wings on an airplane while it is in flight. We will be erasing the root file system and kernel and flashing replacements while linux is actively running.

Storing the image files and utilities outside the root fs

Since our first step will be to erase the root file system, we'll need to find a safe place to store the new rootfs and kernel images. We will also need to store copies of the mdt-utils programs in this location.

There are two obvious places: the ram based file system under /tmp or on a CF, MMC, or microSD card. For this example we will describe the process assuming you will be using the ram disk. If you use a MCC or microSD card just substitute /media/card for each occurance of /tmp in the instructions below. If you use a CF card, substitute /media/cf for each occurance of /tmp.

First, copy your new rootfs and kernel image files to /tmp using your preferred method (scp, ftp, memory card, usb thumb drive, . . .) The instructions below assume that you have named them rootfs and uimage.

Second, copy the three mtd utilities that we need to /tmp:

$ cp /usr/bin/flash_eraseall /tmp
$ cp /usr/bin/flashcp /tmp
$ cp /usr/bin/flash_unlock /tmp

At this point /tmp should contain rootfs, uimage, flash_eraseall, flashcp, and flash_unlock.

Now we'll change our working directory to /tmp and then make sure that linux doesn't try to write to the root files sytem while we are attempting the brain transplant:

$ cd /tmp
$ mount -o remount,ro /

Now we get to the meat of the process. There are 3 mtd devices of interest in this process:

• /dev/mtd0 - holds U-boot
• /dev/mtd1 - holds the root file system
• /dev/mtd2 - holds the linux kernel

You can verify this on your machine:

$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "Bootloader"
mtd1: 00ec0000 00020000 "RootFS"
mtd2: 00100000 00020000 "Kernel"

Reflashing the root file system

We're going to start with the rootfs. We first erase it and format it for jffs2 using the flash_eraseall utility

$ ./flash_eraseall -j /dev/mtd1

When that process completes, we use flashcp to copy over our new rootfs image:

$ ./flashcp -v rootfs /dev/mtd1

Reflashing the linux kernel

Now we'll reprogram the partition containing the linux kernel. This is a one step process. Please note that the command specifies /dev/mtd2, which is the linux kernel partition:

$ ./flashcp -v uimage /dev/mtd2

When this command completes, you have successfully reflashed your root file system and linux kernel. There is no simple way to reboot from the command line - just cycle power. Because the root file system is mounted read only you can't hurt anything.

Reflashing U-boot

It is normally not necessary to reflash the U-boot partition. Proceed only if you are absolutely certain that you must replace your current U-boot.

Note: If you make an error in performing this step, it is possible to "brick" your motherboard. Correcting this will require sending the motherboard back to Gumstix for a reflash service.

These instructions assume that you have a copy of the new U-boot image in /tmp and that it is named uboot.bin.

Please note that we are using /dev/mtd0 for the following two commands:

$ ./flash_unlock /dev/mtd0
$ ./flashcp -v uboot.bin /dev/mtd0

When the flashcp command completes successfully you can cycle power on your motherboard to reboot.

If the flashcp command does not complete successfully, do not power down your motherboard. Carefully check to see if you made a typing error. It is possible to re-enter the command correctly at this point. If you power down, you will have bricked your motherboard.

If the source of the problem is not evident, please cut and paste your terminal session into an email to the gumstix mailing list. Again, do not power down your motherboard, perhaps someone on the mailing list can help you resolve your issue.