RootFileSystemInAReadOnlyFileWithoutRamdisk < DULG

%SECTION0{name=RootFileSystemInAReadOnlyFileWithoutRamdisk}% 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:
     <verbatim>
      root=/dev/mtdblock0 lofile=rev1/rootfs.img
     </verbatim>


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:

   * these file systems in a file system look inefficient (read slow startup), but who cares, you're already relying on compression. Please note that once loaded in pagecache, the system runs at full speed.
   * root file system is read-only

Advantages are:

   * cramfs/squashfs are at advantage here over initrd, because only needed files make it into the pagecache.
   * allow more flash space efficiency than static partitioning



     <verbatim>
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 ...
     </verbatim>

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