module initialization function init_pq2fads_mtd() performs just two simple calls:
• physmap_configure() passes to the MTD subsystem the Flash chip's physical address, size, and bank width, along with any special setup function required to access the Flash.
• physmap_set_partitions() passes the board's unique partition information to the MTD subsystem from the partition table defined in the pq2fads_partitions[] array found at the start of this mapping driver.
Following this simple example, you can derive a mapping driver for your own board.
10.3.4. Flash Chip Drivers
MTD has support for a wide variety of Flash chips and devices. Chances are very good that your chosen chip has also been supported. The most common Flash chips support the Common Flash Interface (CFI) mentioned earlier. Older Flash chips might have JEDEC support, which is an older Flash compatibility standard. Figure 10-4 shows the kernel configuration from a recent Linux kernel snapshot. This version supports many Flash types.
Figure 10-4. Flash device support
If your Flash chip is not supported, you must provide a device file yourself. Using one of the many examples in .../drivers/mtd/chips as a starting point, customize or create your own Flash device driver. Better yet, unless the chip was just introduced with some newfangled interface, chances are good that someone has already produced a driver.
10.3.5. Board-Specific Initialization
Along with a mapping driver, your board-specific (platform) setup must provide the underlying definitions for proper MTD Flash system operation. Listing 10-12 reproduces the relevant portions of .../arch/arm/mach- ixp4xx/coyote-setup.c.
Listing 10-12. Coyote-Specific Board Setup
static struct flash_platform_data coyote_flash_data = {
.map_name = 'cfi_probe',
.width = 2,
};
static struct resource coyote_flash_resource = {
.start = COYOTE_FLASH_BASE,
.end = COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
static struct platform_device coyote_flash = {
.name = 'IXP4XX-Flash',
.id = 0,
.dev = {
.platform_data = &coyote_flash_data,
},
.num_resources = 1,
.resource = &coyote_flash_resource,
};
...
static struct platform_device *coyote_devices[] __initdata = {
&coyote_flash,
&coyote_uart
};
static void __init coyote_init(void) {
...
platform_add_devices(coyote_devices, ARRAY_SIZE(coyote_devices));
}
...
In Listing 10-12, only the relevant portions of the coyote-setup.c platform initialization file are reproduced. Starting from the bottom, the coyote_init() function calls platform_add_devices(), specifying the Coyote-specific devices defined earlier in this file. You'll notice that two devices are defined just above the coyote_init() routine. The one we're interested in for this discussion is coyote_flash. This structure of type struct platform_device contains all the important details needed by the Linux kernel and MTD subsystem.
The .name member of the coyote_flash structure binds our platform-specific Flash resource to a mapping driver with the same name. You can see this in the mapping driver file .../drivers/mtd/maps/ixp4xx.c. The .resource member communicates the base address of the Flash on the board. The .dev member, which contains a .platform_data member, ties our Flash setup to a chip driver. In this case, we have specified that our board will use the CFI probe method, specified in the kernel configuration as CONFIG_MTD_CFI. You can see this configuration selection in Figure 10-4.
Depending on your own architecture and board, you can use a method similar to this to define the Flash support for your own board.
10.4. MTD Utilities
The MTD package contains a number of system utilities useful for setting up and managing your MTD subsystem. The utilities are built separately from the primary MTD subsystem, which should be built from within your Linux kernel source tree. The utilities can be built in a similar manner to any other cross-compiled user space code.
You must use caution when using these utilities because there is no protection from mistakes. A single- digit typo can wipe out the bootloader on your hardware platform, which can definitely ruin your day unless you've backed it up and know how to reprogram it using a JTAG Flash programmer.
In keeping with a common practice throughout this book, we cannot devote sufficient space to cover every MTD utility. We highlight the most common and useful ones, and leave it as an exercise for the reader to explore the rest. A recent MTD snapshot contained more than 20 binary utilities.
The flash_* family of utilities is useful for raw device operations on an MTD partition. These include flashcp, flash_erase, flash_info, flash_lock, flash_unlock, and others. Hopefully their names are descriptive enough to give some idea of their function. After partitions are defined and enumerated as kernel devices, any of these user space utilities can be run on a partition. We repeat the warning we issued earlier: If you execute flash_erase on the partition containing your bootloader, you'll be the proud owner of a silicon paperweight. If you intend to
