|
|
|
7.1 MTD-Supported DevicesAs we saw earlier in Section 3.4.1, the MTD subsystem is rich and elaborate. To use it on your target, you will need a properly configured kernel and the MTD tools available from the project's web site. We will discuss both of the issues below. As with other kernel subsystems, the development of the MTD subsystem and the MTD tools is independent of the mainline kernel. Hence, the latest kernel often does not include the latest code in the MTD CVS repository. You can, nevertheless, retrieve the latest code and use it instead of the MTD code already included in the kernel you have selected. Because the MTD code in the kernel releases is not in sync with the MTD development, however, you can sometimes encounter problems. I was unable, for instance, to get vanilla Linux 2.4.18 to boot from a DiskOnChip (DOC) 2000, because there is a bug in the default MTD code in that kernel. To fix the problem, I had to manually modify the MTD code according to instructions found in the MTD mailing list archive. For this reason, you will find the MTD mailing list and its archive helpful. In the following sections, we will start by discussing the usage basics of the MTD subsystem. This will cover issues such as configuring the kernel, installing the required utilities, and creating appropriate entries in /dev. The discussion will then focus on the use of the MTD subsystem with the two solid state storage devices most commonly used in embedded Linux systems: native CFI-compliant flash and DOC devices. 7.1.1 MTD Usage BasicsHaving already covered the detailed architecture of the MTD subsystem, we can now concentrate on the actual practical use of its components. First, we will discuss the /dev entries required for MTD abstractions. Second, we will discuss the basic MTD kernel configuration options. Third, we will discuss the tools available to manipulate MTD storage devices in Linux. Finally, we will describe how to install these tools both on the host and on the target. 7.1.1.1 MTD /dev entriesThere are five types of MTD /dev entries and seven corresponding MTD user modules.[1] In practice, many MTD user modules share the same /dev entries and each /dev entry can serve as an interface to many MTD user modules. Table 7-1 describes each type of MTD /dev entry and the corresponding MTD user modules, and Table 7-2 provides the minor number ranges and describes the naming scheme used for each device type.
The use of each type of MTD /dev entry is as follows:
As we'll see later, you don't need to create all these entries manually on your host. You will, however, need to create some of these entries manually on your target's root filesystem to use the corresponding MTD user module. Also, note that the naming scheme described above differs slightly from the one described in the devices.txt file mentioned earlier. The naming scheme presented here is the one used in practice. 7.1.1.2 Configuring the kernelAs I mentioned in Chapter 5, the configuration of the MTD subsystem is part of the main menu of the kernel configuration options. Whether you are configuring the kernel using the curses-based terminal configuration menu or through the Tk-based X Window configuration menu, you will need to enter the "Memory Technology Devices (MTD)" submenu to configure the MTD subsystem for your kernel. The MTD submenu contains a list of configuration options that you can choose to build as part of the kernel, build as separate modules, or disable completely. Here are the main options you can configure in the MTD submenu:
The preceding list is primarily made up of the user modules I described earlier. The remaining MTD user modules, JFFS and JFFS2, are not configured as part of the MTD subsystem configuration. Rather, they are configured within the "File systems" submenu. Nevertheless, you will need to enable MTD support to enable support for either JFFS or JFFS2. The MTD submenu also contains four submenus to configure support for the actual MTD hardware device drivers. Here are the submenus found in the MTD submenu and their descriptions:
Before configuring your kernel's MTD subsystem, make sure you have read the MTD subsystem discussion in Chapter 3, since many of the options described here were amply covered in my earlier discussion. When configuring the kernel for your host, you will find it useful to configure all the MTD subsystem options as modules, since you will be able to test different device setup combinations. For your target, however, you will need to compile all the options required to support your solid state storage device as part of your kernel rather than as modules. Otherwise, your target will not be able to mount its root filesystem from its solid state storage device. If you forget to configure your target's kernel so that it can mount its root filesystem from the MTD device, your kernel will panic during startup and complain about its inability to mount its root filesystem with a message similar to the following: Kernel panic: VFS: unable to mount root fs on ... 7.1.1.3 The MTD utilitiesBecause the MTD subsystem's functionality is different from that of other kernel subsystems, a special set of utilities is required to interact with it. We will see in the next sections how to obtain and install these utilities. For now, let's take a look at the available tools and their purposes.
Within the MTD tool set, there are different categories of tools, each serving a different MTD subsystem component. Here are the different tool categories and the tools they contain:
Most of these tools are used on /dev/mtdN devices, which are the char device interfaces to the various MTD devices. I will describe the typical uses of the most important MTD tools over the next few chapters, covering the actual MTD hardware in this chapter, preparation of the root filesystem in Chapter 8, and the boot setup in Chapter 9. 7.1.1.4 Installing the MTD utilities for the hostThe MTD utilities are maintained as part of the MTD development CVS. You can retrieve the latest tool versions using CVS. You can also download a CVS snapshot from ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/. For my DAQ module, I am using the snapshot dated 2002-07-31. Download the snapshot of your choice to your ${PRJROOT}/build-tools directory and extract it. You can then move to this directory and prepare to compile the tools: $ cd ${PRJROOT}/build-tools/mtd/util
$ automake --foreign; autoconf
$ ./configure --with-kernel=/usr/src/linux
When issuing the configure command, you must provide the path to the kernel that will be used to compile the tools. Since you are building the tools for your host, you need to provide the path to your host's kernel sources. By default, these should be located at /usr/src/linux. As in other build scenarios, configure builds the Makefile required to compile the tools. You can now compile the tools: $ make clean $ make Make sure you issue the make clean command, as there are files in the utilities source code that need to be deleted to allow symbolic links with the same names to be created to files in the kernel sources. If the build process fails while compiling compr.c because of an undefined KERN_WARNING symbol, you will need to edit the Makefile.am file and replace the following lines: compr.o: compr.c
$(COMPILE) $(CFLAGS) $(INCLUDES) -Dprintk=printf \
-DKERN_NOTICE= -c -o $@ $<
with: compr.o: compr.c
$(COMPILE) $(CFLAGS) $(INCLUDES) -Dprintk=printf \
-DKERN_WARNING= -DKERN_NOTICE= -c -o $@ $<
Once you have completed the modification, you will need to restart the build from the start, as already described, after having issued a make distclean command. With the utilities built, you can now install them in your tools directory: $ make prefix=${PREFIX} install
This will install the utilities in ${PREFIX}/sbin. You will need to add this directory to your path, if it's not already part of it. See my earlier explanation in Chapter 4 about installing uClibc's utilities for a complete description on how to add a new directory to your development path. Now that the utilities have been installed, you need to create the MTD device entries in your host's /dev directory. The MAKEDEV script found in the util directory takes care of the device creation. Have a look inside this file if you are interested in the devices being created. MAKEDEV mainly creates the /dev entries I covered earlier in Section 7.1.1.1. Because MAKEDEV uses the mknod command, you will need to run it as root: # ./MAKEDEV Although you may later want to update your MTD tool set, you should not need to use MAKEDEV again. If your MTD devices are accessible on the host because you are using the removable storage setup or the standalone setup we discussed in Chapter 2, you are ready to manipulate your MTD devices immediately. If you are using the linked setup or want to use the MTD utilities on your target in a removable storage setup, read the next section for instructions on how to build the MTD utilities for your target. 7.1.1.5 Installing the MTD utilities for the targetTo install the MTD utilities for your target, you need to first download and install zlib. Earlier, when you installed the MTD utilities on your host, you didn't need to install zlib, because zlib is part of most mainstream distributions. Zlib is available at http://www.gzip.org/zlib/. For my DAQ module, I used zlib 1.1.4. Download zlib and extract it in your ${PRJROOT}/build-tools directory. You can then move to the library's directory to prepare its compilation: $ cd ${PRJROOT}/build-tools/zlib-1.1.4
$ CC=i386-linux-gcc LDSHARED="i386-linux-ld -shared" \
> ./configure --shared
By default, the zlib build process generates a static library. To build zlib as a shared library, you must set the LDSHARED variable and provide the - -shared option when invoking configure. With the Makefile created, you can compile and install the library: $ make
$ make prefix=${TARGET_PREFIX} install
As with the other target libraries we installed earlier, we install zlib in ${TARGET_PREFIX}/lib. Once the library is installed, you can install it on your target's root filesystem: $ cd ${TARGET_PREFIX}/lib
$ cp -d libz.so* ${PRJROOT}/rootfs/lib
You are now ready to build the MTD utilities. Download the MTD snapshot into your ${PRJROOT}/sysapps and extract it. Now move into the utilities directory and build the tools: $ cd ${PRJROOT}/sysapps/mtd/util
$ automake --foreign; autoconf
$ CC=i386-linux-gcc ./configure \
> --with-kernel=${PRJROOT}/kernel/linux-2.4.18
$ make clean
$ make
In this case, the kernel path points to your target's kernel. As in the previous section, if the build process fails while compiling compr.c because of an undefined KERN_WARNING symbol, you will need to edit the Makefile.am file, make the appropriate changes, and restart the build from the beginning after issuing make distclean. With the utilities built, you can now install them in your target's root filesystem: $ make prefix=${PRJROOT}/rootfs install
This will install the utilities in ${PRJROOT}/rootfs/sbin. We will not run the MAKEDEV script here, because it is not well adapted to creating device entries other than on the root filesystem of the system on which it runs. If you want to use the script as is, you would have to copy it to your target's root filesystem and then run it once you have the target running. This, however, would waste filesystem resources on the target, since the script creates entries for all the MTD devices you can possibly have in a system. We will see in the following sections how to create just the devices needed on the target's root filesystem.
7.1.2 Native CFI FlashMost recent small-to-medium-sized non-x86 embedded Linux systems are equipped with some form of CFI flash. Setting up CFI flash to be used with Linux is relatively easy. In this section, we will discuss the set up and manipulation of CFI devices in Linux. We will not discuss the use of filesystems on such devices, however, since these will be covered in the next chapter. The order to the subsections below tries to follow the actual steps involved in using CFI flash devices with Linux as much as possible. You can, nevertheless, use these instructions selectively according to your current manipulation. 7.1.2.1 Kernel configurationYou will need to enable kernel support for the following options to use your CFI flash device:
You may also choose to enable other options, but these are the bare minimum. Also, remember to set the options to "y" instead of "m" if you intend to have the kernel mount its root filesystem from the CFI device. 7.1.2.2 PartitioningUnlike disk or DOC devices, CFI flash cannot generally be partitioned using tools such as fdisk or pdisk, because partition information is not usually stored on CFI flash devices. Instead, the device's partitions are hardcoded in the mapping driver and are registered with the MTD subsystem during the driver's initialization. The actual device does not contain any partition information whatsoever. You will, therefore, have to edit the mapping driver's C source code to modify the partitions. Take TQM8xxL PPC boards, for instance, which are good candidates for my control module. Such boards can contain up to two 4 MB flash banks. Each 32 bit-wide memory addressable flash bank is made of two 16 bit-wide flash chips. To define the partitions on these boards, the boards' mapping driver contains the following structure initializations: static struct mtd_partition tqm8xxl_partitions[ ] = {
{
name: "ppcboot", /* PPCBoot Firmware */
offset: 0x00000000,
size: 0x00040000, /* 256 KB */
},
{
name: "kernel", /* default kernel image */
offset: 0x00040000,
size: 0x000C0000,
},
{
name: "user",
offset: 0x00100000,
size: 0x00100000,
},
{
name: "initrd",
offset: 0x00200000,
size: 0x00200000,
}
};
static struct mtd_partition tqm8xxl_fs_partitions[ ] = {
{
name: "cramfs",
offset: 0x00000000,
size: 0x00200000,
},
{
name: "jffs2",
offset: 0x00200000,
size: 0x00200000,
}
};
In this case, tqm8xxl_partitions defines four partitions for the first 4 MB flash bank, and tqm8xxl_fs_partitions defines two partitions for the second 4 MB flash bank. Three attributes are defined for each partition: name, offset, and size. A partition's name is an arbitrary string meant only to facilitate human usability. This name is not used by either the MTD subsystem or the MTD utilities to enforce any sort of structure on said partition. The offset is used to provide the MTD subsystem with the start address of the partition, while the size is self-explanatory. Notice that each partition on a device starts where the previous one ended; no padding is necessary. Table 7-3 presents the actual physical memory address ranges for these partitions on a TQM860L board where the two 4 MB banks are mapped consecutively starting at address 0x40000000.
During the registration of this device's mapping, the kernel displays the following message: TQM flash bank 0: Using static image partition definition Creating 4 MTD partitions on "TQM8xxL Bank 0": 0x00000000-0x00040000 : "ppcboot" 0x00040000-0x00100000 : "kernel" 0x00100000-0x00200000 : "user" 0x00200000-0x00400000 : "initrd" TQM flash bank 1: Using static file system partition definition Creating 2 MTD partitions on "TQM8xxL Bank 1": 0x00000000-0x00200000 : "cramfs" 0x00200000-0x00400000 : "jffs2" You can also see the partitions by looking at /proc/mtd. Here is its content for my control module: # cat /proc/mtd dev: size erasesize name mtd0: 00040000 00020000 "ppcboot" mtd1: 000c0000 00020000 "kernel" mtd2: 00100000 00020000 "user" mtd3: 00200000 00020000 "initrd" mtd4: 00200000 00020000 "cramfs" mtd5: 00200000 00020000 "jffs2" Notice that the partitions are on erase size boundaries. Because flash chips are erased by block, not by byte, the size of the erase blocks must be taken in account when creating partitions. In this case, erase blocks are 128 KB in size, and all partitions are aligned on 128 KB (0x20000) boundaries.
7.1.2.3 Required /dev entriesYou need to create /dev entries for the char device and block device MTD user modules to access your CFI flash device. Create as many entries for each type of user module as you have partitions on your device. For example, the following commands create root filesystem entries for the six partitions of my TQM860L board: $ cd ${PRJROOT}/rootfs/dev
$ su -m
Password:
# for i in $(seq 0 5)
> do
> mknod mtd$i c 90 $(expr $i + $i)
> mknod mtdblock$i b 31 $i
> done
# exit
Here are the resulting entries: $ ls -al mtd* crw-rw-r-- 1 root root 90, 0 Aug 23 17:19 mtd0 crw-rw-r-- 1 root root 90, 2 Aug 23 17:20 mtd1 crw-rw-r-- 1 root root 90, 4 Aug 23 17:20 mtd2 crw-rw-r-- 1 root root 90, 6 Aug 23 17:20 mtd3 crw-rw-r-- 1 root root 90, 8 Aug 23 17:20 mtd4 crw-rw-r-- 1 root root 90, 10 Aug 23 17:20 mtd5 brw-rw-r-- 1 root root 31, 0 Aug 23 17:17 mtdblock0 brw-rw-r-- 1 root root 31, 1 Aug 23 17:17 mtdblock1 brw-rw-r-- 1 root root 31, 2 Aug 23 17:17 mtdblock2 brw-rw-r-- 1 root root 31, 3 Aug 23 17:17 mtdblock3 brw-rw-r-- 1 root root 31, 4 Aug 23 17:17 mtdblock4 brw-rw-r-- 1 root root 31, 5 Aug 23 17:17 mtdblock5 7.1.2.4 ErasingBefore you can write to a CFI flash device, you need to erase its content. This can be done using one of the two erase commands available as part of the MTD utilities, erase and eraseall. Before updating the initial RAM disk on my control module, for example, I need to erase the "initrd" partition: # eraseall /dev/mtd3 Erased 2048 Kibyte @ 0 -- 100% complete. 7.1.2.5 Writing and readingWhereas flash filesystems such as JFFS2 take advantage of the capability of continuing to set bits to 0 in an erase block to allow transparent read and write access, you cannot usually use user-level tools to write to an MTD device more than once. If you want to update the content of an MTD device or partition using its raw char /dev entry, for example, you must usually erase this device or partition before you can write new data to it. Writing to a raw flash device can be done using traditional filesystem commands such as cat and dd. After erasing the "initrd" partition on my control module, for example, I use the following command to write a new initial RAM disk image to the designated partition: # cat /tmp/initrd.bin > /dev/mtd3 In this case, my target's root filesystem is mounted via NFS, and I am running the MTD commands on my target. I could have also used the dd command instead of cat. Nevertheless, the end result is the same in this case. Reading from a CFI MTD partition is no different from reading from any other device. The following command on my control module, for instance, will copy the binary image of the bootloader partition to a file: # dd if=/dev/mtd0 of=/tmp/ppcboot.img Since the bootloader image itself may not fill the entire partition, the ppcboot.img file may contain some extra unrelated data in addition to the bootloader image. 7.1.3 DiskOnChipDOC devices are quite popular in x86-based embedded Linux systems, and the MTD subsystem goes a long way in providing support for them. I use it, for example, in my DAQ module. It remains that the DOC is a peculiar beast that requires an attentive master. The reasons for such a statement will become evident shortly. 7.1.3.1 Preliminary manipulationsUnlike most other devices found in embedded Linux systems, you will need to equip yourself with, at the very least, a bootable DOS diskette loaded with M-Systems' DOS DOC tools to make proper use of any DOC device. There are two basic reasons for this:
In addition, there are two ways to install a bootloader on the DOC and format it for NFTL. The first, which is most recommended by the MTD maintainer, is to use M-Systems' dformat DOS utility. The second, which gives you the greatest degree of control over your DOC device from within Linux, is to use the doc_loadbios and nftl_format MTD utilities. We will discuss both methods in the following sections. M-Systems' DOS DOC tools and related documentation are available from the company's web site at http://www.m-sys.com/. If you plan to use the Linux method to install a bootloader on the DOC and format it, you need both Version 4.2 and Version 5.0 or later of M-Systems' tools. If you plan to use the DOS method, you only need Version 5.0 or later of the M-Systems tools. At the time of this writing, the latest version is 5.1.2. The example below is based on a 32 MB DOC 2000 device. The output of the various tools will depend on the actual device you are using, but should closely resemble the output presented here. Start by preparing a DOS diskette with the latest tools. Once you have prepared the DOS diskette, boot the system containing your DOC device with that diskette. Now, use the tools as follows:[4]
You are now ready to use your DOC device with Linux. 7.1.3.2 Kernel configurationAt the time of this writing, if you are using the DOS method to install a bootloader and format the DOC, you need to patch your kernel with the latest MTD code from the MTD CVS repository to proceed. See the MTD project's web site (http://www.linux-mtd.infradead.org/) for information on how to retrieve the code from the CVS repository. You will need to enable kernel support for the following options to use your DOC device:
As with CFI flash, you may choose to select other options. If you compile the options just listed as modules, the DOC support will be separated in three files, docecc.o, doc2000.o, and docprobe.o. Issuing a modprobe docprobe command should load all three modules automatically. Whether it is part of the kernel or loaded as a module, the DOC probe driver will analyze potential memory addresses for DOC devices. For each memory address it analyzes, the probe driver outputs a message regarding its findings. Here is an example of output from the probe driver on my DAQ module: Possible DiskOnChip with unknown ChipID FF found at 0xc8000 ... Possible DiskOnChip with unknown ChipID FF found at 0xce000 DiskOnChip 2000 found at address 0xD0000 Flash chip found: Manufacturer ID: 98, Chip ID: 73 (Toshiba TH58V128DC) 2 flash chips found. Total DiskOnChip size: 32 MiB Possible DiskOnChip with unknown ChipID FF found at 0xd2000 Possible DiskOnChip with unknown ChipID FF found at 0xd4000 ...
7.1.3.3 Required /dev entriesYou need to create /dev entries for the char device and the NFTL MTD user modules in order to access your DOC device. Create as many char device entries and sets of NFTL entries as you have DOC devices in your system. For each NFTL set, create as many entries as you will create partitions on your device. For my DAQ module, for instance, I have one DOC device with only one main partition. I use the following commands to create the relevant entries: $ cd ${PRJROOT}/rootfs/dev
$ su -m
Password:
# mknod mtd0 c 90 0
# mknod nftla b 93 0
# mknod nftla1 b 93 1
# exit
Here are the resulting entries: $ ls -al mtd* nftl* crw-rw-r-- 1 root root 90, 0 Aug 29 12:48 mtd0 brw-rw-r-- 1 root root 93, 0 Aug 29 12:48 nftla brw-rw-r-- 1 root root 93, 1 Aug 29 12:48 nftla1 7.1.3.4 ErasingErasing a DOC device is done in very much the same way as other MTD devices, using the erase and eraseall commands. Before using any such command on a DOC device, make sure you have a copy of the BBT, because an erase of the device will wipe out the BBT it contains. To erase the entire DOC device in my DAQ modules, for instance, I use the following command on my DAQ module: # eraseall /dev/mtd0 Erased 32768 Kibyte @ 0 -- 100% complete. Typically, you will need to erase a DOC device only if you want to erase the bootloader and the current format on the device. If you installed a Linux bootloader, for example, and would like to revert back to M-Systems' SPL, you will need to use the eraseall command before you can install M-Systems' SPL with M-Systems' tools. Whenever you erase the entire device, however, you need to use M-Systems' tools to restore the BBT. 7.1.3.5 Installing bootloader imageIf your target does not boot from its DOC device, you can skip this step. Otherwise, you need to build the bootloader, as I describe in Chapter 9, before going any further. First, nonetheless, let's see how a system boots from the DOC. During system startup on x86 systems, the BIOS scans the memory for BIOS extensions. When such an extension is found, it is executed by the BIOS. DOC devices contain a ROM program called the Initial Program Loader (IPL) that takes advantage of this characteristic to install another program called the Secondary Program Loader (SPL) that acts as a bootloader during system startup. By default, the SPL is provided by M-Systems' own firmware. To boot Linux from a DOC device, however, the SPL must be replaced with a bootloader able to recognize the format used by Linux on a DOC. We will discuss the various DOC-capable Linux bootloaders in Chapter 9. For now, let us take a look at how we can install our own SPL on a DOC. Here is the command I use to install the GRUB bootloader image, grub_firmware, on the DOC in Linux: # doc_loadbios /dev/mtd0 grub_firmware Performing Flash Erase of length 16384 at offset 0 Performing Flash Erase of length 16384 at offset 16384 Performing Flash Erase of length 16384 at offset 32768 Performing Flash Erase of length 16384 at offset 49152 Performing Flash Erase of length 16384 at offset 65536 Performing Flash Erase of length 16384 at offset 81920 Writing the firmware of length 92752 at 0... Done. Here is the command I use to install the GRUB bootloader image on the DOC in DOS: A:\>dformat /win:d000 /bdkf0:grub_firmware DFORMAT Version 5.1.0.25 for DOS Copyright (C) M-Systems, 1992-2002 WARNING: All data on DiskOnChip will be destroyed. Continue ? (Y/N)y DiskOnChip 2000 found in 0xd0000. 32M media, 16K unit Formatting 2042 Writing file to BDK 0 92752 OK Please reboot to let DiskOnChip install itself. As with updating the firmware version earlier, you need to power-cycle your system after using doc_loadbios or dformat for the firmware to be installed properly. That said, do not use doc_loadbios or dformat before reading the explanations pertaining to its use with a bootloader in Chapter 9. 7.1.3.6 NFTL formattingCurrently, the only way to use DOC devices in Linux is to format them for NFTL. Once we format a DOC device for NFTL, we can use conventional block device tools and filesystems in conjunction with the device. If you would like to boot from the DOC, read the sections in Chapter 9 regarding x86 bootloaders before carrying out any further operations on your DOC. If you used the dformat utility earlier to install GRUB on the DOC, your DOC is already formatted for NFTL. If you used doc_loadbios in Linux, you must use the nftl_format command to format the device for NFTL. The following MTD command formats the entire DOC device for NFTL: # nftl_format /dev/mtd0
$Id: ch07.xml,v 1.3 2003/05/01 21:52:06 madd Exp madd $
Phase 1. Checking and erasing Erase Zones from 0x00000000 to 0x02000000
Checking Zone #2047 @ 0x1ffc000
Phase 2.a Writing NFTL Media Header and Bad Unit Table
Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table
Phase 3. Writing Unit Control Information to each Erase Unit
This command takes some time to go through the various zones on the DOC. Should nftl_format encounter bad blocks on the DOC, it outputs the following message: Skipping bad zone (factory marked) #BLOCK_NUM @ 0xADDRESS The BLOCK_NUM and ADDR values output by nftl_format should match the values found in the docbbt.txt file generated earlier.
If you have installed a Linux bootloader on the DOC using doc_loadbios, you need to skip the region where the bootloader was written and start formatting at its end. To do so, you need to provide an offset to nftl_format. Here is the command I use to format my DOC for NFTL in the case where I had already installed GRUB as the SPL: # nftl_format /dev/mtd0 98304
$Id: ch07.xml,v 1.3 2003/05/01 21:52:06 madd Exp madd $
Phase 1. Checking and erasing Erase Zones from 0x00018000 to 0x02000000
Checking Zone #2047 @ 0x1ffc000
Phase 2.a Writing NFTL Media Header and Bad Unit Table
Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table
Phase 3. Writing Unit Control Information to each Erase Unit
The 98304 offset is determined by the output of the doc_loadbios command shown earlier. The last erase message output by the command reported erasing 16384 bytes at offset 81920. 98304 is therefore the first address following the last region erased for the bootloader. With the DOC device formatted for NFTL, reboot the system as a precautionary step. When the NFTL driver is activated, either at kernel startup or when loading the nftl.o module, it should output a message similar to the following: NFTL driver: nftlcore.c $Revision: 1.3 $, nftlmount.c $Revision:... Cannot calculate an NFTL geometry to match size of 0xfea0. Using C:1018 H:16 S:4 (= = 0xfe80 sects) If the NFTL driver can see a DOC device but is unable to recognize its format, it will output this message instead: Could not find valid boot record Could not mount NFTL device Although this message is normal if you have not yet used nftl_format on the DOC device, it is a sign that an error occurred if you already used nftl_format on the DOC. The error message may be followed by a message similar to: Sorry, we don't support UnitSizeFactor 0x06 or: Sorry, we don't support UnitSizeFactor of != 1 yet. There are many reasons why you may encounter these messages. None of them are your fault if you have followed the instructions above, as well as those in Chapter 9. As a first resort, you can try using different MTD and GRUB versions. For example, I had such messages when I tried using a November 2002 CVS version of GRUB with the DOC on my DAQ module. For some reason, the firmware image generated by that version of GRUB confused the NFTL driver in 2.4.18. To solve the problem and have the NFTL driver recognize my NFTL-formatted device, I used GRUB 0.92 instead of the latest CVS version. You may encounter a similar error if you used dformat to install GRUB on the DOC but forgot to patch your kernel to use the latest MTD code from the CVS. Whenever you encounter such a message, review your manipulations and make sure you have faithfully followed the steps we discussed. If it is not a manipulation error, you can choose to dig deeper and use your hacking skills to figure out the problem on your own. It is often a good idea, nevertheless, to search the MTD mailing list archive and to consult with the MTD mailing list, because others may have encountered a similar problem and may have already solved it. When sending a message to the MTD mailing list, or any other mailing list for that matter, try to be as verbose as possible. It is very frustrating for mailing list subscribers to receive pleas for help that have little or no detail. Specifically, provide the versions of all the software components involved, explain the exact steps you followed, and provide the output of all the tools you used. 7.1.3.7 PartitioningWith the DOC device formatted for NFTL, you can now partition the device using fdisk. Here is the transcript of an fdisk session in which I create one partition on my NFTL device: # fdisk /dev/nftla
Device contains neither a valid DOS partition table, nor Sun or S ...
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): p
Disk /dev/nftla: 16 heads, 4 sectors, 1018 cylinders
Units = cylinders of 64 * 512 bytes
Device Boot Start End Blocks Id System
Command (m for help): d
Partition number (1-4): 1
Command (m for help): n
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1018, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1018, default 1018):
Using default value 1018
Command (m for help): p
Disk /dev/nftla: 16 heads, 4 sectors, 1018 cylinders
Units = cylinders of 64 * 512 bytes
Device Boot Start End Blocks Id System
/dev/nftla1 1 1018 32574 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl( ) to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
Note that we delete the first partition before creating it again. This is because the use of dformat to install the bootloader and format the DOC also results in the creation of a single FAT partition spanning the entire device. If you had used the Linux doc_loadbios, fdisk will display the following error message regarding the partition deletion, which you can ignore: Warning: partition 1 has empty type Also, note that instead of using a single partition on the DOC, or any other storage device for that matter, you could delete all partitions and store your filesystem on the entire device. See Chapter 3 in Running Linux for a full description of how to use fdisk. With the DOC partitioning done, you can manipulate the newly created partitions like any conventional disk partition. Among other things, you can format and mount the NFTL partitions. We will discuss these issues in detail in Chapter 8. |
|
|
|
