An Introduction to Embedded Linux Development, Part 3

Of course, we can modify the JFFS2 filesystem while the LBox is running--after all, it acts as our hard drive. If we want to make a dramatic overhaul, however, we could reorganize and reflash the whole thing. Doing exactly that is the subject of this section. We again would use netflash to flash the whole /dev/mtd3 partition with a JFFS2 image. Doing so leaves the JFFS2 flash partition metadata out of sync with filesystem information--for example, inode data--that the kernel brought into memory earlier. Therefore, rebooting after the netflash operation seems okay is recommended.

A few considerations must be made when getting the user filesystem ready to netflash to the LBox. First, we need to construct a directory on the workstation that contains what ultimately will be the contents of the JFFS2 directory on the LBox. This directory already exists on the CD provided by the vendor, and we copied it over to the workstation earlier. Its name is etc_config/. We suggest that it be left as is for the trial run that follows.

Next, we use the following command to create an output file, calling it config.jffs2:

mkfs.jffs2 -b --pad=0x002f0000 --root=etc_config/ --output=config.jffs2

The --root option specifies that the etc_config/ directory is used to provide the intended contents for the JFFS2 filesystem. The --output option identifies the name, config.jffs2, for the file that will be created containing the desired JFFS2 filesystem. The --pad option pads the result out to the same size as the /dev/mtd3 partition on the flash memory. The -b option is needed to create the filesystem as big-endian, appropriate for the embedded Motorola architecture.

After the filesystem is ready, we move it into the /tftpboot directory on the host computer. We then run the following command from the LBox, by way of minicom, to flash the filesystem:

netflash -knrb /dev/mtd3  tftp_server  /tftpboot/config.jffs2

where tftp_server is replaced by the IP address of your workstation.

Notice that the device is /dev/mtd3 and that this corresponds to the memory location for the JFFS2 filesystem. After rebooting the LBox you should see the new filesystem residing at /etc/config on the LBox.

The bootloader is the software component least likely to require an update. However, there are times when you may need to do this. Perhaps you need to compile in new features, or maybe a newer version of the bootloader is needed. As with the kernel/root filesystem update, updating the bootloader also can be risky. Now, with the new bootloader binary in the tftp directory, we can update the LBox by executing the following command from the LBox.

netflash -bknr /dev/mtd0  tftp_server /tftpboot/colilo.bin

where tftp_server again is replaced by the IP address of your workstation.

In this case, we put the binary file into the bootloader partition, which is /dev/mtd0. We again used the -b option to give us one more chance to recover should we suddenly realize that the colilo.bin file has a problem. That is, we still could repeat the above steps with the correct file. If everything goes well, we can reboot the LBox and ultimately be presented with the command prompt.

Several of the netflash/reboot iterations discussed in the current article can leave the LBox in a non-functional state if the transferred files are not correct. In particular, if the Linux image is bad, netflash will not be available to access the workstation's tftp server; if the colilo binary is bad, we can't even start the boot process. To recover, we can use a Background Debug Mode (BDM) Coldfire cable to access the BDM of the Motorola Coldfire microcontroller. The next and final installment of this series will explain how to conduct such a recovery operation.

"An Introduction to Embedded Linux Development, Part 2"

"An Introduction to Embedded Linux Development, Part 1"

"Power Trio: Three Diverse Embedded Linux SBCs"

"Flash Filesystems for Embedded Linux Systems"