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.
Richard Sevenich is a Professor of Computer Science at Eastern Washington University in Cheney, WA.
Ben Anderson is an upper division Computer Science major at Eastern Washington University. His current interests are hardware and embedded systems, particularly those which use Linux.