Difference between revisions of "Archiving JFFS2 Images"

From wiki.emacinc.com
Jump to: navigation, search
Line 1: Line 1:
{{todo|<strike>Polish this</strike> Reviewed (11.1.13-15:27->KY+)|Mike Dean|project=oe 4,oe 5,md,finaldraft,mw}}
{{todo|<strike>Polish this</strike> Complete(11.05.13-17:33->JG-)|Mike Dean|project=oe 4,oe 5,md,Complete,mw}}
=== Background ===
=== Background ===

Revision as of 18:33, 5 November 2013

TODO: {{#todo:Polish this Complete(11.05.13-17:33->JG-)|Mike Dean|oe 4,oe 5,md,Complete,mw}}


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.


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


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.

  1. Boot the system and log in as the root user.
  2. Create a directory to use for the mount point of the NFS drive. For this example, /tmp/nfs will be used.
  3. root@emac-oe:~# mkdir /tmp/nfs
  4. Mount the NFS filesystem. The commands in this step assume that 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 the nolock option is necessary because no portmap daemon is running on the default EMAC OE system.
  5. root@emac-oe:~# mount -o nolock -t nfs /tmp/nfs
  6. 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 the mount 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 the mtd0 partition is shown as "root."
  7. 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”
  8. Once the remote NFS filesystem has been mounted, a binary copy of the image can be taken by following the steps below.

  9. 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.
    root@emac-oe:~# cd /tmp/nfs
    root@emac-oe:~# dd if=/dev/mtdblock0 of=rootfs_backup.jffs2

    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.
    root@emac-oe:~# cd /tmp/nfs
    root@emac-oe:~# nanddump /dev/mtd0 -o -n -f rootfs_backup.jffs2

  10. Once the image has been successfully copied, unmount the NFS drive.
  11. root@emac-oe:~# cd
    root@emac-oe:~# umount /tmp/nfs


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.