Getting Started Boot from ROM Memory Technology Device (MTD)

The Memory Technology Device (MTD) subsystem for Linux provides access to non-volatile memory storage, typically Flash devices. By using a layered approach, it is possible to support new hardware and devices easily, and have them fully functional with a minimum of work. For more information on MTD see the project's web page. There is also an MTD FAQ, which is provided as part of the MTD source code, or as a daily snapshot.

As MTD is integrated into the Linux kernel, it makes working with Flash devices very simple. For example flash programming simply consists of copying a file to the flash device.

MTD also provides several mechanisms for putting a file system into Flash. These are fully fledged file systems, which can be written to as well as read.

Terminology

The MTD layering is a little complex. Click on the buttons for a HTML (from this site) or graphical (from the MTD site) version of these.

The user layer is the API that user code sees, and is exported through the normal Linux device driver API.

• The character and block devices give direct access to the Flash, so the application code has to be aware of the flash characteristics.
• The two Flash Translation Layer (FTL) modules provide a normal block device, making it appear that the Flash is completely read/write, and hiding the fact that to overwrite data involves first erasing. In effect this makes the Flash appear as a disk, and allows a normal Linux file system to be created in the Flash.
• Finally the Journalling Flash File Systems (JFFS and JFFS2) provides a full file system, directly within the Flash. This is the most efficient way to use the Flash, because JFFS has been written assuming Flash characteristics, whereas a normal filesystem will have been written assuming a rotating disk. This allows the file system semantics to be mapped onto the Flash effectively, and gives it visibility of the physical Flash layout. This allows it to support Flash specific concepts such as wear leveling (ensuring that each Flash region is written and erased roughly the same number of times, thus maximising the Flash's lifetime).

The user layer code never accesses the Flash devices directly. Instead they use an internal MTD API to access the hardware device driver layer. This means that all all user layer drivers should work on all devices.

The implementation of the driver layer can be done in two ways:

1. As a direct implementation, as seen for the M-Systems Disk on Chip (DOC) driver, and also in the `test' drivers which implement the MTD API using RAM.
2. For Flash devices mapped into the CPU's address space an extra layering is possible. This divides the driver into chip mappings which describes how the Flash devices are mapped into memory, and handles banking and partitioning, and the chip driver which writes to the Flash chip's control registers.

Configuring the Kernel

The configuration described here uses several aspects of MTD, so you will need to enable several kernel options. As usual you should choose whether you want these built into the kernel or configured as modules. However remember if you are planning to have your root file system on an MTD device they need to be configured into the kernel.

• First MTD itself needs to be enabled (CONFIG_MTD).
• Next select the style of partitioning which is required. We want basic `MTD partitioning support' (CONFIG_MTD_PARTITIONS) but none of the partition table parsing.
• The user modules which are required will depend on the application, but the `Direct char device' (CONFIG_MTD_CHAR) is usually required (this corresponds to the device files /dev/mtdn (read/write) and /dev/mtdrn (read-only)). This is used to erase and program the Flash directly.
• If JFFS or JFFS2 are going to be used, then the `Caching block device' (CONFIG_MTD_BLOCK) must be enabled. This corresponds to the device files /dev/mtdblockn.
• In addition if you are going to be using `FTL (Flash Translation Layer)' (CONFIG_FTL), this need to be enabled. This corresponds to devices /dev/ftln.
• Next, you need to choose the `RAM/ROM/Flash chip driver' you will be using. This is dictated by which devices are present on the target board. There are two aspects to this:
  1. Choosing how MTD should probe for Flash chips. The two supported options are to use the Common Flash Interface (CFI), which is used by most modern devices (some background information), (CONFIG_MTD_CFI) or the older JEDEC method (CONFIG_MTD_JEDECPROBE). Note that of the ST boards, the HARP and the ST40RA Eval boards use JEDEC devices, the rest are CFI.
  2. Which command set should be used to program the devices once they have been detected. This is largely based on which company manufactured the Flash, so either 'Support for Intel/Sharp flash chips' (CONFIG_MTD_CFI_INTELEXT) (which supports CFI command set 0001) or 'Support for AMD/Fujitsu flash chips' (CONFIG_MTD_CFI_AMDSTD) (which supports CFI command set 0002) needs to be selected.
  It is not a problem if superfluous chip drivers are selected, MTD will choose the appropriate one based on the partitioning code and the results of the probes. However this will bloat the code, so may need to be rationalised when the final hardware is decided upon.
• The next layer in the MTD hierarchy is the chip mappings. All ST provided evaluation boards share a common mapping driver: `CFI Flash device mapped on STMicroelectronics ST40 boards' (CONFIG_MTD_STBOARDS). If this is selected further options will appear to support the ST STEM Flash modules, which you may want to select of you have one or more plugged in. Note that we could have used the generic 'Flash device in physical memory map' (CONFIG_MTD_PHYSMAP) option, and specified the base addresses and size. However this doesn't allow us to partition the Flash, so simple but custom mapping driver is used.

Build the kernel as normal, and when next booted you should see the following diagnostics:

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
CFI: Found no STEM Flash device at location zero