Difference between revisions of "Archiving JFFS2 Images"
(→Procedure) |
(→Summary) |
||
Line 71: | Line 71: | ||
=== Summary === | === Summary === | ||
− | After following the above steps, the JFFS2 filesystem image will be stored on the NFS server. This image can then be edited on the server | + | After following the above steps, the JFFS2 filesystem image will be stored on the NFS server. This image can then be edited on the server or on a desktop computer's copy of the server's image, and can be programmed to other boards. A developer may also choose to version control the images or send them to remote workers to deploy in the field. See our other articles in this series for more information on how to perform these other tasks. |
[[Category:Filesystems]] | [[Category:Filesystems]] |
Revision as of 17:30, 5 November 2013
Contents
Background
During the development process, which usually involves writing software for a board, various modifications are normally made to the filesystem to support the application:
- The application is put onto the filesystem.
- An initialization script is written to start the application on boot.
- The network connectivity is often configured so that the machine will come up on a network in a predictable manner.
- Various server software on the machine may be configured, such as a web server, ftp server, ssh server, etc.
- The machine may be configured to handle the insertion of a USB flash drive, SD card, etc. in a predictable fashion.
- If the machine has a display, it may be configured for a specific brightness, resolution, touchscreen calibration, etc.
- A custom kernel may be built for the machine.
- Additional drivers may be added to the machine.
- Custom drivers may be written for and added to the machine.
After months of effort (if not more than a year), the developer(s) will get to a point where the machine performs its task exactly as desired. At this point, the developers will likely want to be able to capture an exact copy of the filesystem on the machine so that the same image can be programmed onto additional boards. Additionally, developers will often wish to be able to make a backup copy of the filesystem during the course of development. Like version control, making these backup copies can enable a developer to try something out and roll back to a previous version if the experiment didn't pan out as hoped.
This page describes how JFFS2 images can be made from the filesystem on the flash memory on a machine. This enables developers to meet the needs outlined above and others which aren't mentioned here.
Note that this process applies only to boards that use a JFFS2 filesystem for flash storage. A different method is utilized for systems using other filesystems, such as ext3. |
Prerequisite
An NFS server needs to be setup and available on your network before this procedure can be used. A tutorial on setting up an NFS file server can be found here
Procedure
This procedure assumes that a working NFS server is accessible on the local network and that the board will have write access to the server. Once this configuration has been tested, follow the steps below to create the archive.
- Boot the system and log in as the root user.
- Create a directory to use for the mount point of the NFS drive. For this example,
/tmp/nfs
will be used. - Mount the NFS filesystem. The commands in this step assume that 10.0.2.60 is the IP address of the NFS server on the local network and that
/opt/nfs
is the exported directory on the server to which the image should be copied. These parameters will need to be adjusted to match the local network configuration. Also note that thenolock
option is necessary because no portmap daemon is running on the default EMAC OE system. - Next, determine which MTD partition contains the JFFS2 image to be copied. In most cases, this will be the root filesystem but the same procedure can be used to archive any JFFS2 partition. The most helpful information can usually be found in the
/proc/mtd
file. The output of themount
command,/etc/fstab
and other commands may also be used. The listing below shows the contents of/proc/mtd
on a system where/dev/mtd0
contains the root filesytem. The name column tells us this, because the name for themtd0
partition is shown as "root." - Once the remote NFS filesystem has been mounted, a binary copy of the image can be taken by following the steps below.
- NOR Flash
- For NOR flash, the
dd
command should be used. The MTD block device corresponding to the JFFS2 partition must be specified as the image source;/dev/mtdblock0
in this case. - NAND Flash
- For NAND devices, the
nanddump
command is used to allow for correct bad block handling. The MTD device (not the block device) corresponding to the JFFS2 partion must be specified as the image source;/dev/mtd0
in this case. - Once the image has been successfully copied, unmount the NFS drive.
root@emac-oe:~# mkdir /tmp/nfs
root@emac-oe:~# mount -o nolock -t nfs 10.0.2.60:/opt/nfs /tmp/nfs
root@emac-oe:~# cat /proc/mtd dev: size erasesize name mtd0: 02000000 00020000 “root” mtd1: 0e000000 00020000 “aux” mtd2: 00042000 00000210 “df_boot” mtd3: 00210000 00000210 “df_kernel” mtd4: 001ce000 00000210 “df_aux”
The required commands are different for NAND flash and NOR flash. If you are unsure of which type of flash is used on the system that you are archiving, refer to the documentation for your hardware. |
root@emac-oe:~# cd /tmp/nfs root@emac-oe:~# dd if=/dev/mtdblock0 of=rootfs_backup.jffs2
root@emac-oe:~# cd /tmp/nfs root@emac-oe:~# nanddump /dev/mtd0 -o -n -f rootfs_backup.jffs2
root@emac-oe:~# cd root@emac-oe:~# umount /tmp/nfs
Summary
After following the above steps, the JFFS2 filesystem image will be stored on the NFS server. This image can then be edited on the server or on a desktop computer's copy of the server's image, and can be programmed to other boards. A developer may also choose to version control the images or send them to remote workers to deploy in the field. See our other articles in this series for more information on how to perform these other tasks.