Design of MTD falsh Management in Linux

Because the loader upgrade requires Flash to save data, but there is no suitable interface for use on the Android system
I have studied the MTD interface design and transplanted the flash Management Code. I have some experiences to record it.

Exclusive terms:
1. MTD: memory technology device, memory technology device,
2. JEDEC: Joint Electron Device Engineering couneller, electronic and electrical equipment Federation
3. CFI: Common flash interface, General flash interface, a flash interface standard initiated by Intel
4. OOB: out of band. Some memory technologies support out-of-band data. For example, each 512-byte block of NAND Flash has 16 bytes of extra data for error correction or metadata.
5. ECC: Error Correction. Some hardware not only allows access to flash, but also supports ECC. All flash devices are suffering from bit switching. In some cases, a bit may be reversed or reported to be reversed. If this bit is actually reversed, the ECC algorithm is used.
6. erasesize: The minimum block size that an erase command can erase
7. buswidth: The interface bus width of the MTD Device
8. interleave: staggered data. Several chips are connected to one chip in parallel to increase buswidth.
9. devicetype: chip type, X8, x16, or x32
10. NAND: A Flash technology. For more information, see comparison between NAND and nor.
11. Nor: A Flash technology. Refer to the comparison between NAND and nor.

1. Overview
MTD provides an abstract interface between the hardware and file system layers. MTD is the middle layer used to access memory devices (such as ROM and flash, it extracts the common features of memory devices, making it easier to add new memory device drivers. This document uses MTD to compile the upper-Layer Management Flash program interface.

The MTD middle layer is subdivided into four layers, which are: Device node, MTD device layer, MTD raw device layer, and hardware driver layer.

The interface between the MTD device layer, MTD raw device layer, and Flash hardware driver layer is as follows:


2. Several important data structures:

/* Parse the contents of the file, which looks like :*/
CAT/proc/MTD
Dev: Size erasesize name
Mtd0: 00400000 00100000 "logo"
Mtd1: 01e00000100000 "cache"
Mtd2: 00100000 00100000 "Misc"
Mtd3: 00700000 00100000 "kernel"
Mtd4: 0b40000000100000 "system"
Mtd5: 10e0000000100000 "userdata"
Mtd6: 01300000 00100000 "factorydata"
Mtd7: 00100000 00100000 "blackbox"

Open the "/proc/MTD" file to parse the MTD partition information. Here we can know the number, size, size of the MTD, and Dev name.

Ls-L/dev/MTD * [partition_info]
CrW ------- root 90, 15 mtd7ro
CrW ------- root 90, 14 mtd7
CrW ------- root 90, 13 mtd6ro
CrW ------- root 90, 12 mtd6
CrW ------- root 90, 11 mtd5ro
CrW ------- root 90, 10 mtd5
CrW ------- root 90, 9 mtd4ro
CrW ------- root 90, 8 mtd4
CrW ------- root 90, 7 mtd3ro
CrW ------- root 90, 6 mtd3
CrW ------- root 90, 5 mtd2ro
CrW ------- root 90, 4 mtd2
CrW ------- root 90, 3 mtd1ro
CrW ------- root 90, 2 mtd1
CrW ------- root 90, 1 mtd0ro
CrW ------- root 90, 0 mtd0
It can be seen that there are two MTD devices: one is RW and the other is Ro. Generally, devices without the RO suffix are used.

Mtd_info Data Structure
Struct mtd_info_user {
Unsigned char type; // memory technology type, such as mtd_ram, mtd_rom, mtd_norflash, mtd_nand_flash, and mtd_perom
Unsigned long flags; // flag bit
Unsigned long size; // total size of the MTD // the size of the MTD Device
Unsigned long erasesize; // The minimum size of the erased block.
Unsigned long writesize; // programming block size
Unsigned long oobsize; // amount of OOB data per block (e.g. 16) // OOB (out of band) block size
Unsigned long ecctype; // available OOB bytes per block // available OOB bytes for each block
Unsigned long eccsize;
};
# Define memgetinfo _ ior ('M', 1, struct mtd_info_user)

Sprintf (mtd_devname, "/dev/MTD % d", I );

You can use IOCTL (FD, memgetinfo, & mtdinfo) to obtain MTD information on an open (mtd_devname, o_rdwr) device.
Based on the above, the start address and end address of a partition can be obtained.

// Partition structure information
Struct mtd_part {
Struct mtd_info MTD; // mtd_info data structure, which will be added to mtd_table
Struct mtd_info * master; // primary partition of the partition
Uint64_t offset; // The offset address of the partition
Struct list_head list; // partitioned linked list
};

Mtd_partition describes the specific partition structure of MTD.
Struct mtd_partition {
Char * Name;/* identifier string partition name */
Uint64_t size;/* partition size */
Uint64_t offset;/* offset within the master MTD space offset address */
Uint32_t mask_flags;/* master MTD flags to mask out for this partition */
Struct nand_ecclayout * ecclayout;/* out of band layout for this partition (NAND only )*/
};

Ls-L/dev/block/[mount_partition]

BRW ------- root 31, 7 mtdblock7
BRW ------- root 31, 6 mtdblock6
BRW ------- root 31, 5 mtdblock5
BRW ------- root 31, 4 mtdblock4
BRW ------- root 31, 3 mtdblock3
BRW ------- root 31, 2 mtdblock2
BRW ------- root 31, 1 mtdblock1
BRW ------- root 31, 0 mtdblock0

This method is generally used for Mount nodes and for different file systems.

3. Read and Write Data and erase data
Basically, you can use lseek, write, and read to operate data. You must note that the processing of Bad blocks and OOB data is based on the block device operation logic.

4. Bad blocks
1. Why are there bad blocks?
Because the process of NAND Flash cannot guarantee the reliability of the memory array in its life cycle, Bad blocks will be generated during the production and use of NAND. The bad block feature is that when the block is programmed/erased, it will cause errors in page program and block erase operations and reflect the corresponding bit of Status Register accordingly.
2. Classification of Bad blocks
In general, Bad blocks can be divided into two categories: (1) Inherent Bad blocks: these are the bad blocks generated during the production process, generally, the original chip manufacturer will mark the 6th bytes of the spare area on the first page of each bad block as not equal to 0xff at the factory. (2) Use of Bad blocks: If the block erase or page program is incorrect during the use of NAND Flash, the block can be simply processed as a bad block, in this case, you need to mark the bad block. To be consistent with the inherent bad block information, mark the 6th bytes of the spare area of the first page of the new bad block as a non-0xff value.
3. Bad block management
According to the above descriptions, we can understand that bad block information has been reflected in the spare area when NAND Flash was released. Therefore, if a block is erased before, check whether the first 6th bytes of spare area on the first page are 0xff. If yes, it indicates that this is a good block and can be erased. If it is not 0xff, it cannot be erased, to avoid removing the bad block mark. Of course, this process may make a mistake-"Kill pseudo-Bad blocks", because the operating process of the chip may cause NAND operation errors due to occasional factors such as voltage instability. However, to ensure data reliability and simplify software design, we still need to follow this standard.
You can use bbt: Bad Block table, that is, bad block table, for management. Various Bad block management methods for NAND are different. For example, if NAND is used for storage, the bbt will be placed in block0, because 0th blocks must be good blocks. However, if the NAND itself is used for boot, 0th pieces will be stored in the program and no bbt can be placed. Some put the bbt in the last part. Of course, this part cannot be a bad part. The size of the bbt depends on the NAND size. The larger the NAND, the larger the bbt is required.
It should be noted that OOB is the data on every page, which contains ECC (not only of course), but bbt is a flash; the identification of Bad blocks for each block is the sixth byte of the spare area on the first page of the block.
4. Bad Block Correction
ECC: When an error occurs in NAND Flash, only one or several bits of the entire page (such as 512 bytes) are generated. Generally, ECC is a dedicated verification method. ECC can correct single-bit errors and detect dual-bit errors, and the computation speed is fast. However, it cannot correct errors of more than one bit, and it cannot detect errors of more than two bits.
ECC generally generates 3-byte ECC verification data for each 256 bytes of raw data. The three-byte 24-bit data is divided into two parts: 6-bit column verification and 16-bit row verification, the remaining two bits are set to 1. (512 generate two groups of ECC, 6 bytes in total)

When data is written to the page of NAND Flash, an ECC checksum is generated every 256 bytes, which is called the original ECC checksum and saved to the OOB (out-of-band) of the page) data zone. The location is eccpos []. During verification, based on the above ECC generation principle, it is not difficult to infer that the original ECC verification and the new ECC verification read from the OOB area are bitwise OR. If the result is 0, it indicates that there is no error (or an error that cannot be detected by ECC). If there are 11 bits in the 3-byte variance or the result is 1, it indicates that a bit error exists and can be corrected.
Positive. If three bytes are exclusive or only one bit is 1 in the result, an error occurs in the OOB area. Otherwise, an error cannot be corrected.