This section describes the file system and MTD technologies. FFS is familiar with ext2, 3, and 4, but these are all for disk devices. The general storage devices in Es are flash, because of the special characteristics of FLASH:
- Flash storage is divided by block size, and a memory generally has dozens of K. (Only 512 bytes for a cluster on the disk ). What are the disadvantages of such a large volume? Obviously, it takes a long time to erase an BL.
- In addition, the flash operation must target a bl at a time, that is, if I want to modify a byte, I must first erase 128 kb. Isn't it true that you want to die?
- In flash, each bl is erased for a limited number of times, for example, 2 million times? If the same BL is operated every time, the BL will soon die.
Therefore, a journaling flash File System (jffs2, Second Edition) is developed based on the flash features ). It has the following features:
- The loss is balanced, that is, each write wipe will not stay on a BL. For example, if a file is written on BL1, then when a new file is created, FS will not select BL1, but bl2. This technology is called weal Leveling: Loss balancing
(APT-Get install MTD-tools, download a lot of good tools, in addition, it can be seen that writing logs to flash devices may cause flash to be short-lived) some pseudo file systems: proc/sysfs, OOl ool tool is used to analyze sysfs. Common Fs IN Es include ramfs/rootfs/tmpfs, which are memory-based FS. What does this have to do with initramfs? In fact, these are based on initramfs. Here we will explain several confusing things:
- RAM disk: This is a ram-based disk used to simulate Block devices. Therefore, it is built on a virtual block device. It doesn't matter what the above FS uses. this will cause efficiency and other problems. After all, your read and other operations will still be passed to the driver, and if the device constructs an ext2 FS, there will be a corresponding ext2-FS module. Trouble ..
- Ramfs: This is a memory-based FS, not a real-device-based FS. Ramfs enables users to write memory until the system memory is empty.
- In order to control this disadvantage, tmpfs is introduced, and the size of tmpfs can be specified. (This is similar to a real device because the storage space of the real device is also limited)
- Rootfs is a special ramfs or tmpfs (check whether tmpfs is enabled in lk). In addition, rootfs cannot be umount.
The following describes how to use Mount loop to create a virtual file-based block device.
- First, create a file with all values 0. Run the DD command: dd If =/dev/Zero of = .. /fstest BS = 1024 COUNT = 512 this explanation is as follows: Copy data from if to of, each copy byte is 1024, the total number of copies is 512. you can use a hexadecimal tool to check whether all the generated files are 0x00.
- Create FS, mkfs. ext2fs ../fstest in this file. Now, FS exists in this file. In fact, FS is some organizational structures, such as superblock and inode.
- How can I mount this file with FS information? In fact, how does one regard this file as a block device? Use the Mount loop option to mount-T ext2-o loop fstest/tmp /. In this way, the file is mounted to TMP as a virtual block device.
2 MTD technology MTD is memory technology device, memory technology device? It is actually a virtual device driver layer, similar to virtual file system. It provides standard APIs for device drivers that operate raw flash. So what is the difference between flash device and general block device?
- A normal BLD has only two types of operations: read and write.
- Flash device has three types of operations: read, write, and erase. In addition, a wear leveling algorithm is required to balance the loss.
It should be noted that SD/mmccard, CF (compact flash) card and USB Flash are not MTD devices, because these devices already have a built-in flash Translation Layer, this layer handles erase and wear leveling (this TL should be supported in the firmware ). Therefore, these devices are directly used as common Block devices (the above description still does not clarify how MTD is used, and will be analyzed based on the source code in the future) 2.1 it is very easy to enable MTD support in the kernel. You can enable it when making menuconfig. There are several options. Figure 1 configuration options supported by MTD in LK:
- Mtc_char and mtd_block are used to read and write MTD devices in char and block modes. This is the same as normal char and Block devices.
- The last two are to set an MTD test driver in the kernel. 128 KB is used to set the total size, and the second is used to set the block size. A virtual flash device is built in the kernel for testing.
How do I configure MTD and related things in es?
- Set a partition for flash disk (the entire device can also be a partition. BTW, I have never thoroughly figured out what the partition is trying to do. This may be a historical reason ....)
- Set the Flash type and location. Flash devices are classified into nor and NAND devices. This section briefly introduces the differences between the two devices.
- Select the appropriate driver for the flash chip
- Configure driver for LK
Next let's take a look at the partition settings for the flash partition. Here we have some slightly important content: how to pass the flash partition information to lk? There are two methods:
- Store the entire device partition in a block, so that when bootloader is started, relevant information will be created according to the content in the block. It seems that only red boot is supported. This is called Redboot partition table. In addition, Lk can identify this partition and read its information through the CFI (command flash interface.
- Kernel command line partitioning: input parameters when starting with kernel, But KL must be configured. Command Format:
Figure 2 now let's look at the mapping of the driver, that is, pairing MTD with the corresponding Flash Driver... kernel/Drivers/MTD/maps ......, what about the driver of the flash chip in the future? Kernel/Drivers/MTD/chips, currently popular is CFI Interface 3 references and supplementary knowledge worker working on a generic Linux subsystem for memory devices, especially flash devices.
The aim of the system is to make it simple to provide a driver for new hardware, by providing a generic interface between the hardware drivers and the upper layers of the system.
Hardware drivers need to know nothing about the storage formats used, such as FTL, ffs2, Etc ., but will only need to provide simple routines for read, write and erase. presentation of the device's contents to the user in an appropriate form will be handled by the upper layers of the system. MTD Overview
MTD subsystem (stands for memory technology devices) provides an alternative action layer for raw flash devices. it makes it possible to use the same API when working with different flash types and technologies, e.g. nand, onenand, nor, Ag-and, ECC 'd nor, etc.
MTD subsystem does not deal with Block devices like MMC, emmc, SD, compactflash, etc. these devices are not raw flashes but they have a Flash Translation Layer Inside, which makes them look like Block devices. these devices are the subject of the Linux block subsystem, not MTD. please, refer to this FAQ section for a short list of the main differences between block and MTD devices. and the raw Flash. FTL devices ubifs section discusses this in more details.
MTD subsystem has the following interfaces.
- MTD character devices-usually referred to as/dev/mtd0,/dev/mtd1, and so on. these character devices provide I/O access to the raw flash. they support a number of IOCTL cballs for erasing eraseblocks, marking them as bad or checking if an eraseblock is bad, getting information about MTD devices, etc. /dev/mtdx is actually a char device !!
- The sysfs interface is relatively newer and it provides full information about each MTD device in the system. this interface is easily extensible and developers are encouraged to use the sysfs interface instead of older IOCTL or/proc/MTD interfaces, when possible.
- The/proc/MTD proc file system file provides general MTD information. This is a legacy interface and the sysfs interface provides more information.
MTD subsystem supports bare NAND flashes with software and hardware ECC, onenand flashes, CFI (Common flash Interface) nor flashes, and other flash types.
Additionally, MTD supports legacy FTL/nftl "Translation layers", M-systems 'diskonchip 2000 and Millennium chips, and pcmcia flashes (pcmciamtd driver ). but the corresponding drivers are very old and not maintained very much. MTD block DRIVER: The mtdblock driver available in the MTD is an archaic tool which emulates Block devices on top of MTD devices. it does not even have bad eraseblock handling, so it is not really usable with nand flashes. and it works by caching a whole flash erase block in Ram, modifying it as requested, then erasing the whole block and writing back the modified. this means that mtdblock does not try to do any optimizations, and that you will lose lots of data in case of power cuts. and last, but not least, mtdblock does not do any wear-leveling.
Often people consider mtdblock as general FTL layer and try to use block-based file systems on top of bare flashes using mtdblock. this is wrong in most cases. in other words, please, do not use mtdblock unless you know exactly what you are doing.
There is also a read-only version of this driver which doesn't have the capacity to do the caching and erase/writeback, mainly for use with uCLinux where the extra RAM requirement was considered too large these are the modules which provide interfaces that can be used directly from userspace. the user modules currently planned include:
- Raw character access: A character device which allows direct access to the underlying memory. useful for creating filesystems on the devices, before using some of the translation drivers below, or for raw storage on Infrequently-changed flash, or RAM devices.
- Raw block access: A block device driver which allows you to pretend that the flash is a normal device with sensible sector size. it actually works by caching a whole flash erase block in Ram, modifying it as requested, then erasing the whole block and writing back the modified data.
This allows you to use normal filesystems on flash parts. obviusly it's not particle ly robust when you are writing to it-You lose a whole erase block's worth of data if your read/modify/Erase/Rewrite cycle actually goes read/modify /Erase/poweroff. but for development, and for setting up filesystems which are actually going to be mounted read-only in production units, it shocould be fine. there is also a read-only version of this driver which doesn't have the capacity to do the caching and erase/writeback, mainly for use with uCLinux where the extra RAM requirement was considered too large.
- Flash Translation Layer (FTL): nftl, block device drivers which implement an FTL/nftl filesystem on the underlying memory device. FTL is fully functional. nftl is currently working for both reading and writing, but cocould probably do with some more field testing before being used on production systems.
- Journalling FLASH file system, V2: This provides a filesystem directly on the flash, rather than emulating a block device. For more information, see sources.redhat.com.
- MTD Hardware Device Drivers
These provide physical access to memory devices, and are not used directly-they are accessed through the user modules above.
On-board memory: Your PC chipsets are incapable of correctly Caching System memory above 64 m or 512 m. A driver exists which allows you to use this memory with the Linux-MTD system.
- PCMCIA devices: PCMCIA flash (not compactflash but real Flash) cards are now supported by the pcmciamtd driver in CVS.
- Common flash interface (CFI) onboard nor FLASH: this is a common solution and is well-tested and supported, most often using jffs2 or cramfs file systems.
- Onboard nand flash: NAND Flash is rapidly overtaking nor flash due to its larger size and lower cost; jffs2 support for NAND Flash is approaching production quality.
- M-systems 'diskonchip 2000 and Millennium: The diskonchip 2000, Millennium and Millennium plus devices shoshould be fully supported, using their native nftl and inftl 'translation' layers '. support for jffs2 on diskonchip 2000 and Millennium is also operational although lacking proper support for bad block handling.
What is the difference between nor and NAND? Beside the different silicon cell design, the most important difference between NAND and nor flash is the bus interface. nor flash is connected to a address/Data Bus direct like other memory devices as SRAM etc. NAND Flash uses a multiplexed I/O interface with some additional control pins. NAND Flash is a sequential access device appropriate for mass storage applications, while nor Flash is a random access device appropriate for code storage application. nor flash can be used for code storage and code execution. code stored on NAND flash can't be executed from there. it must be loaded into RAM memory and executed from there.
- Nor can be directly connected to the CPU, just like the memory. Nand is not allowed, because NAND also needs some other I/O control interfaces. So NAND is more like a disk, and nor is more like a memory.
- Nor is more expensive than nand, and NAND supports sequential reading, while nor supports random reading.
- Therefore, you can store code in the nor statement so that the CPU can directly read the code and run it. Nand is not allowed (mainly because NAND cannot be directly found when the CPU obtains the address)
