This is a more complicated example that shows that - depending
on project requirements - many other alternatives for chosing a root
file system for your embedded system exist.

The scenario is as follows: on your embedded device you use a
cheap and popular storage medium like CompactFlash, MMC or SD cards
or USB memory sticks
to store both the Linux kernel and your root file system.
You want to distribute software updates over the internet:
your customers can download the file from your web site,
or you sent the images by email.
Your customers may use any flash card or memory stick they happen to find,
so you have no information about brand or size of the storage device.

Unfortunately most of your customers use Windows systems.
And they don't want to be bothered with long instructions
how to create special partitions on the storage device
or how to write binary images or things like that.
A simple "copy file" operation is nearly exhausting their capabilities.

What to do?
Well, if copying a file is all your customers can do we should
not ask for more. Storage devices like CompactFlash cards etc.
typically come with a single partition on it, which holds a FAT or
VFAT file system. This cannot be used as a Linux root file system directly,
so we have to use some trickery.

Here is one possible solution:
Your software distribution consistes of two files:
The first file is the Linux kernel with a minimal ramdisk image attached
(using the multi-file image format for U-Boot);
U-Boot can load and boot such files from a FAT or VFAT file system.
The second file is your root file system.
For convenience and speed we use again an image of an ext2
file system.
When Linux boots, it will initially use the attached ramdisk
as root file system.
The programs in this ramdisk will mount the FAT or VFAT file system -
read-only.
Then we can use a loop device (see losetup(8))
to associate the root file system image with a block device
which can be used as a mount point.
And finally we use pivot_root(8) to change the root file system
to our image on the CF card.

This sounds not so complicated,
and actually it is quite simple once
you understand what needs to be done.
Here is a more detailed description:

The root file system image is easy:
as mantioned before, we will use an ext2 file system image,
and to avoid wearing the flash storage device we will use it
in read-only mode - we did a read-only ext2 root file system image
before, and here we can just re-use the existing image file.

The initial ramdisk image that performs the pivot_root step
must be created from scratch,
but we already know how to create ramdisk images,
so we just have to figure out what to put in it.

The most important tool here is nash,
a script interpreter that was specifically designed for
such purposes (see nash(8)).
We don't need any additional tools,
and if we use static linking,
then the nash binary plus a small script to control it
is all we need for our initial ramdisk.

To be precise, we need a couple of (empty) directories
(bin, dev, etc, lib, loopfs, mnt, proc, and sysroot),
the bin/nash binary,
the linuxrc script
and a symbolic link sbin pointing to bin:

The first line says that it's a script file for the /bin/nash
interpreter.
Note: even if this file looks like a shell script
it is NOT interpreted by a shell,
but by the nash interpreter.
For a complete list of available nash commands and their syntax
please refer to the manual page, nash(8).

The first action is to mount the /proc pseudo file system
which is needed to find out some required information.

Then we create block device entries for all partitions
listed in /proc/partitions (mkdevices command).

In the next step a block device for our new root file system
is created (mkrootdev command).

Then we mount the CF card.
We assume that there is only a single partition on it (/dev/hda1)
which is of type VFAT
(which also will work with FAT file systems).
These assumptions work fine with basicly all memory devices
used under Windows.

We further assume that the file name of the
root file system image on the
CF card is "rootfs.img" - this file now gets mounted
using a loop device (losetup and mount commands).

Our file system image,
is now mounted on the /sysroot directory.
In the last step we use pivot_root to make
this the new root file system.

As a final cleanup we unmount the /proc file system which
is not needed any more.

There is one tiny flaw in this method:
since we mount the CF card on a directory in the ramdisk
to be able to access to root file system image.
This means that we cannot unmount the CF card,
which in turn prevents us from freeing the space for the
inital ramdisk.
The consequence is that you permanently lose
approx. 450 kB of RAM for the ramdisk.
[We could of course re-use this ramdisk space for temporary data,
but such optimization is beyond the scope of this document.]

And how does this work on our target?

First we copy the two images to the CF card; we do this
on the target under Linux:

Kernel with a Flattened Device Tree Blob

When booting an arch/powerpc kernel that requires a flattened device tree blob, the above procedure must be slightly modified. Namely, the multi-image file has to include the blob as the thrid image. Here's an example of the mkimage command to create it: