DENX . DULG . RootFileSystemInAReadOnlyFileWithoutRamdisk

Topic RootFileSystemInAReadOnlyFileWithoutRamdisk not in WebOrder Root File System in a Read-Only File in a JFFS2 File System

This example is less complicated than RootFileSystemInAReadOnlyFile because ramdisk is not required.

The scenario is as follows: on your embedded device, you use only one partition for the kernel, root file system, application, saved data, etc. Why only one partition? Because static partitions suck, they are either too big (space wasted), either too small during the life of the device. Besides, you would pay only once the JFFS2-tax, that is 6 sectors per file system for internal use.

All the files that were sitting on their own partition are now becoming ordinary files in the jffs2 space. The kernel image can be accessed read-only from U-Boot using the fsload command. The root file system (libc, busybox, startup scripts, ..) and application firmwares become cramfs image files stored in the jffs2 space, and accessed through loop devices. The root file system image file would be mounted as root file system in 2 steps, through a loop device, thanks to a small patch against linux/init/do_mounts.c. This patched is named Initial loopback (initlo) support, made available by StephaneFillod?.

Choosing the root file system image file is done through kernel command line. For example, let's say /dev/mtdblock0 is the jffs2 storage, and the real root file system is a cramfs image file rev1/rootfs.img (from base of mounted mtdblock0).

The command line would be:

      root=/dev/mtdblock0 lofile=rev1/rootfs.img

During the first step, Linux mounts the jffs2 file systems (mtdblock0), and during the second step, the patched do_mounts.c setups a loop device, mount the lofile, and pivot the root. After complete boot up, the rootfs.img is the root file system /, and the mtdblock0 space is pivoted to /initlo, hence still accessible.

It's easy to have whatever number of rootfs versions, switching from one another, and updating the kernel command line only when install succeeded (i.e. no power fail, ..). Changing the bootargs variable of U-Boot from Linux environment proves really helpful in that regard.

During normal operation, the jffs2 storage is kept read-only for safety. Only during install it is remounted read-write.

Application software can be packaged the same way (image file), and mounted on their own directory. In a way, this is a kind of archive format. The firmware image files are read-only, hence unbreakable, which is very appropriate for a product. jffs2 will be happy to store also configuration files/data and at least 2 kernel versions (for safe update).

Disadvantages are:

Advantages are:

Kernel command line: root=31:0 ro rootfstype=jffs2 lofile=rev1/rootfs.img
Creating 2 MTD partitions on "Flash banks":
0x00000000-0x03fa0000 : "Filesystem space"
0x03fa0000-0x04000000 : "U-Boot"
Mounting storage filesystem ...
VFS: Mounted root (jffs2 filesystem) readonly.
Binding loopback device ...
Mounting loopback device ...
VFS: Mounted root (cramfs filesystem) readonly.
Trying to move old root to /initlo ... okay
Freeing unused kernel memory: 84k init

BusyBox v1.1.2 (2008.04.03-14:45+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# ### Application running ...

Rem: you may substitute cramfs with squashfs, and jffs2 with yaffs/FAT or anything else. For development purpose, substituting jffs2 with NFS works fine.

----- Revision r1.1 - 05 Aug 2008 - 15:15 - StephaneFillod
Copyright © 2002-2018 by DENX Software Engineering