Home › HOWTO Guides › Booting From Flash

Booting from Flash (worked example)

This example shows how to set up a very simple boot from ROM system, with a root file system in Flash. It relies on some of the components which are supplied pre-built as part of the distribution. See Using the Memory Technology Device (MTD) for more details.

The Flash partitions

We will configure the Flash for three purposes:

  • for the boot program
  • for the kernel image
  • for the root file system (which will be JFFS2)

These correspond to the three partitions set up by the chip mapping driver for all STMicroelectronics' boards with Flash. If the board has a Flash STEM present this appears as an additional fourth partition. When the kernel boots diagnostics like these should appear:

Generic ST boards onboard flash device: 0x00400000 at 0x00000000
Found: ST M29W160DB
Onboard Flash: Found 2 x16 devices at 0x0 in 32-bit mode
number of JEDEC chips: 1
Creating 3 MTD partitions on "Onboard Flash":
0x00000000-0x00040000 : "Boot firmware"
0x00040000-0x00140000 : "Kernel"
0x00140000-0x00400000 : "Root FS"
Generic ST boards STEM flash device: 0x02000000 at 0x01000000
Vendor 00000020 id 000000bb
Detected STM M28W320CB, applying CFI fixups
STEM Flash: Found 2 x16 devices at 0x0 in 32-bit mode
STEM Flash: Found 2 x16 devices at 0x1000000 in 32-bit mode

To adjust the number of partitions, the areas or the memory which will be probed for Flash devices, or the probe types, edit the file drivers/mtd/maps/stboards.c. This describes how each block of Flash devices should be partitioned. Remember that partitions need to start and end on Flash erase block boundaries. Each MTD partition can be given a descriptive name. This will be displayed at boot time, and is also used in /proc/mtd: 

target# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "Boot firmware"
mtd1: 00100000 00020000 "Kernel"
mtd2: 002c0000 00020000 "Root FS"
mtd3: 01000000 00020000 "STEM Flash"

The boot program

To set up the U-Boot boot loader to boot from ROM see How to use the U-Boot boot loader.

The boot from ROM kernel

The next stage in getting the boot from ROM system up and running is to build a suitable kernel, and program it into the Flash. Linux is normally run from RAM, rather than directly from Flash, because this is usually much faster. So as part of the boot process the kernel tt needs to be copied from Flash into RAM. This is done by U-Boot, and so the same kernel which is downloaded by the ST Micro Connect can be used. See How to use the U-Boot boot loader for instructions on storing the kernel into Flash.

The root file system

The final part of setting up boot from ROM is the root file system. The options available when choosing a root file system have been explained above. This section shows how to set up a number of the common root file systems.

Missing files
A program may stop working when run from the new file system. This is usually because it cannot locate a file or files it needs. Here are some techniques which can help track down what is missing:
If a program cannot be run because a shared library is missing try using ldd. This displays which libraries are needed, and where they are currently being loaded from.
The more general problem of a program simply not working, and not adequately reporting the reason, can frequently be tracked down using strace. This prints all the system calls a program makes. Any open calls which return "File Not Found" will often identify the problem.

The easiest system to use is JFFS2 as this is the closest to a normal disk. The command used to create a JFFS2 file system is mkfs.jffs2. This takes as an input the name of the directory containing the files to initially populate the file system, and writes out an image of the resulting file system.

The first step is to construct the directory to use as the root file system of the target. The following files must be provided as a minimum:

  • /bin/init
    This is the first user level program which Linux runs. For a truly embedded system this may be the only program on the system. In this demo we will be using BusyBox, a small utility program, which, depending on the name used to invoke it, can function as many of the standard Linux utilities (for more information see Using BusyBox).

  • busybox
    The version to be used is dynamically linked with the system libraries, so these must be provided. See Missing files for more details about shared libraries.

  • Character and device special files
    A minimal number of character and device special files are needed. For example, when the kernel starts it opens /dev/console, expecting it to be the console device. As these files take up very little space in the target file system they will all be copied over. Note the use of cp -a; without this option cp would try and open the device, and copy the contents, whereas in this case we want just the special file copied.

  • /etc/init.d/rcS
    When /sbin/init is invoked, the first thing it does is run the /etc/init.d/rcS script. In this example, this file prints a welcome message and does some housekeeping.

All of this is done in the following script: 

#!/bin/bash
rm -rf /tmp/fs
mkdir -p /tmp/fs/{bin,dev,etc/init.d,lib,tmp,proc,sbin}
cp /lib/libc.so.6 /tmp/fs/lib
cp /lib/ld-linux.so.2 /tmp/fs/lib
cp /lib/libcrypt.so.1 /tmp/fs/lib
cp /lib/libm.so.6 /tmp/fs/lib
cp /bin/busybox /tmp/fs/bin
for a in sh ls echo mount ; do
  ln -s /bin/busybox /tmp/fs/bin/$a
done
ln -s /bin/busybox /tmp/fs/sbin/init
cp -a /dev/* /tmp/fs/dev
cat > /tmp/fs/etc/init.d/rcS << EOF
 #!/bin/bash
 echo "Welcome to a JFFS file system"
 mount -t proc proc /proc
 mount -o remount,noatime /dev/root /
 EOF
chmod a+x /tmp/fs/etc/init.d/rcS
cp /etc/{passwd,group,hosts} /tmp/fs/etc

This is then converted into a file system image and written to Flash using the following commands: 

target# flash_eraseall /dev/mtd2
target# mkfs.jffs2 --eraseblock=0x20000 --root=/tmp/fs --output=/tmp/fs.img
target# dd if=/tmp/fs.img of=/dev/mtd2

To get the best performance, mkfs.jffs2 must be explicitly told the size of eraseblocks for the Flash device the file system will be on. This can be determined using: 

target# mtd_debug info /dev/mtd2

The file system can be checked by mounting it: 

target# mount -t jffs2 /dev/mtdblock2 /mnt

The final step is to update the kernel command line, so that the root file system is mounted from the Flash device. The command line needs to specify the root device, and the filesystem type, for example: 

root=/dev/mtdblock2 rootfstype=jffs2

Note that unlike most filesystems, for jffs2 the filesystem type must be specified. This is because the jffs2 filesystem does not require the block device to exist (which is why it is listed as "nodev" in /proc/filesystems). This is to allow alternative naming forms such as /dev/mtdn and /dev/mtd:partition_name to be used, which will not exist as block devices in /dev. These names cannot be used when using jffs2 as the root file system, the /dev/mtdblockn form must be used.

See How to use the U-Boot boot loader for details of how to store the command line in Flash.