How To Guide How to boot from ROM Using the Memory Technology Device (MTD)

Using the 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 amount of work. For more information on MTD see the project's web page. There is also an MTD FAQ, which is also 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 can be programmed simply by copying a file to the Flash device.

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

MTD Terminology

The MTD layering is a little complex as shown in Figure 10.

Figure 10: MTD layering

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 erasing first. 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) provide a full file system directly within the Flash. This is the most efficient way to use the Flash, as JFFS has been written assuming the hardware has the characteristics of Flash, whereas normal file systems are based on the characteristics of a rotating disk. This allows the semantics of the JFFS file system to be effectively mapped onto the Flash with visibility of the physical Flash layout, enabling it to support Flash specific concepts such as wear levelling. (This ensures that each Flash region is written and erased approximately the same number of times as any other region, thus maximizing the lifetime of the Flash.)

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 user layer drivers should work on all devices.

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

• as a direct implementation, as seen in the M-Systems Disk on Chip (DOC) driver, and also in the test drivers which implement the MTD API using RAM, or

• for Flash devices mapped into the address space of the CPU, an extra layering is possible. This divides the driver into chip mappings, which describe how the Flash devices are mapped into memory and handles banking and partitioning, and the chip driver, which writes to the control registers of the Flash chip.

Configuring the Kernel for MTD

The configuration described here uses several aspects of MTD, so several kernel options must be enabled. As usual these may be built into the kernel or configured as modules, but if the root file system will be on an MTD device they must be configured into the kernel.

These may be set by bringing up the Linux Kernel Configuration screen on the host, for example:

host% cd /home/STLinux/linux-sh4-2.6.11_20050523
host% make ARCH=st200 CROSS_COMPILE=st231-linux- menuconfig

1. First MTD itself needs to be enabled (CONFIG_MTD). This is found in:

Device Drivers ---> Memory Technology Devices (MTD) ---> Memory Technology Device (MTD) support

2. Next select basic MTD partitioning (CONFIG_MTD_PARTITIONS):

Device Drivers ---> Memory Technology Devices (MTD) ---> MTD partitioning support

3. Command line partitioning (CONFIG_MTD_CMDLINE_PARTS) provides an easy and flexible way to partition the Flash:

Device Drivers ---> Memory Technology Devices (MTD) ---> Command line partition table parsing

4. "Direct character" access (CONFIG_MTD_CHAR) must be enabled to allow direct FLASH access (read, write and erase):

Device Drivers ---> Memory Technology Devices (MTD) ---> Direct char device access to MTD devices

(this corresponds to the device files /dev/mtdn (read/write) and /dev/mtdrn (read-only).

5. "Caching block" access (CONFIG_MTD_BLOCK) must be enabled to allow use of JFFS or JFFS2:

Device Drivers ---> Memory Technology Devices (MTD) ---> Caching block device access to MTD devices

(this corresponds to device files /dev/mtdblock<n>).

6. If Flash Translation Layer will be used then support for this needs to be enabled (CONFIG_FTL).

Device Drivers ---> Memory Technology Devices (MTD) ---> FTL (Flash Translation Layer) support

(this corresponds to devices /dev/ftl<n>).

7. Select the RAM/ROM/Flash chip driver:

Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers --->

This is dictated by which devices are present on the target board. There are two aspects to this.

• Choosing how MTD should probe for Flash chips. The two supported options are CONFIG_MTD_CFI, which is used by most modern devices:

  Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Detect flash chips by Common Flash Interface (CFI) probe

  or the older JEDEC method (CONFIG_MTD_JEDECPROBE):

  Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Detect non-CFI AMD/JEDEC-compatible flash chips

  Note that all of the STMicroelectronics boards use CFI except the HARP and the ST40RA Eval boards, which use JEDEC devices.

• Which command set should be used to program the devices once they have been detected. This usually depends on which company manufactured the Flash.
  Select CONFIG_MTD_CFI_INTELEXT (which supports CFI command set 0001):

  Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Support for Intel®/Sharp® flash chips

  CONFIG_MTD_CFI_AMDSTD (which supports CFI command set 0002):

  Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Support for AMD/Fujitsu® flash chips

  or CONFIG_MTD_CFI_STAA (which supports all CFI command sets):

  Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Support for ST (Advanced Architecture) flash chips

  If superfluous chip drivers are selected, MTD will choose the appropriate one based on the partitioning code and the results of the probes. This will leave redundant code, so unnecessary drivers may need to be dropped when the final hardware is selected.

8. If your platform has two or more Flash chips (for example Espresso), enable CONFIG_MTD_CFI_ADV_OPTIONS:

Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Flash chip driver advanced configuration options

and disable CONFIG_MTD_CFI_I1:

Device Drivers ---> Memory Technology Devices (MTD) ---> RAM/ROM/Flash chip drivers ---> Support 1-chip flash interleave

CONFIG_MTD_CFI_I1 must be ON if only one Flash chip is present.

9. The next layer in the MTD hierarchy is the chip mappings, found in:

Device Drivers ---> Memory Technology Devices (MTD) ---> Mapping drivers for chip access --->

All ST provided evaluation boards share a common mapping driver, CONFIG_MTD_STBOARDS:

Device Drivers ---> Memory Technology Devices (MTD) ---> Mapping drivers for chip access ---> CFI Flash device mapped on STMicroelectronics ST40 boards

If this is selected a STEM Module Support option (MTD_STBOARDS_STEM) will appear. Do not select this, as Flash on STEM are no longer supported.

Build the kernel as normal, and on the next boot diagnostics such as 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 modenumber 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