|
|
 |
How To Guide
How to boot from ROM
Booting from ROM worked example (Flash)
|
|
Booting from ROM worked example (Flash)
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 code 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 BusyBox in the Support Guide).
-
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/sh 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 /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/sh 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# 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 /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.
|