本文共 7116 字，大约阅读时间需要 23 分钟。

轉載自http://www.stlinux.com/howto/NAND/BadBlocks

Sometimes, an attempt to erase a bad block may appear to work. However, this does not mean that the block is usable. Even if subsequent write operations may appear to work, the reliability of the data cannot be guaranteed. In addition, attempting to erase a bad block risks erasing the MBBM and in some circumstances it may be impossible to recover this information, if further erase operations appear to work. This is obviously a dangerous state of affairs and should be avoided at all costs.

全文如下

Bad Blocks

It is in the nature of NAND Flash that a small proportion of the blocks in the device are defective and therefore unusable from the day of manufacture (typically up to 1% is deemed acceptable by the manufacturer). Manufacturers perform thorough testing to identify any potentially bad blocks. When they have been identified, bad blocks are marked with a special marker in the  of the block. This is the .

In addition, blocks become "worn" with use and stop being usable after a certain number of write and erase cycles. This condition presents itself by an error flag being set in the NAND device following an Erase operation. The software that manages the NAND device must implement a "wear-leveling" algorithm to ensure that no blocks suffer from excessive use in comparison to the others. If wear leveling is not implemented, this will dramatically reduce the lifetime of the device. The NAND-aware filesystems supported by STMicroelectronics all implement some form of wear-levelling strategy.

Sometimes, an attempt to erase a bad block may appear to work. However, this does not mean that the block is usable. Even if subsequent write operations may appear to work, the reliability of the data cannot be guaranteed. In addition, attempting to erase a bad block risks erasing the and in some circumstances it may be impossible to recover this information, if further erase operations appear to work. This is obviously a dangerous state of affairs and should be avoided at all costs.

The important point to note is that once a block has been identified as bad, either by the manufacturer or later becasue of an erase failure, that block must be excluded from further use.

Bad Block Management

To cope with the presence of bad blocks, the software must employ some form of bad block management. Typically, it uses a  to record all known bad blocks that are present on a device. Before reading from or writing to the NAND device, the software consults the to determine the locations that are safe to use. It must also monitor the status of Erase operations, with all failures being recorded in the .

There are two types of :  (that is, permanently stored in the NAND device itself) and  (stored only in volatile SDRAM and therefore regenerated on each boot).

RAM resident BBT

RAM-resident BBTs are volatile and must be recreated every time the system is booted. The process involves scanning each block in the NAND device to check for bad block markers.

The main advantage of this approach is simplicity. This is particularly true for manufacturability, where is is possible for a generic NAND programmer to program pre-prepared images without the need to understand the underlying ECC scheme or any  formats.

There are, however, a number of disadavantages. In some cases these disadvantages preclude the use of RAM-resident s.

• Performance: Typically, scanning the device for bad block markers takes considerably more time than retrieving the  from the NAND device.
• Marking worn blocks: Blocks that go bad through use must be marked in such a way that they can be detected on subsequent scans. Typically, this involves writing a marker in the  area, similar to the manufacturer's marker. However, since the block has gone bad, there is no guarantee that writing a bad block marker will succeed. The block will then fail to be detected as bad on subsequent scans which may lead to data corruption if used later.
• ECC layout clashes with the  location: Certain ECC layouts store the ECC data in the same location in the  as that used by the . This means that after a page has been programmed, the ECC data may be incorrectly interpreted as an  leading to false-positive bad blocks. In some cases, this issue can be avoided by adding tags to the  data. In other cases, there is no viable solution, other than to use NAND-resident BBTs.

NAND resident BBT

The use of NAND-Resident s overcomes many of the issues associated with RAM-resident BBTs. For most cases this is the recommended method for recording and tracking bad blocks.

As a NAND-resident  is non-volatile, it is preserved across system boots. There should never be any reason to recreate the  by scanning the NAND device for bad block markers.

Typically, the  requires two bits of storage for each block. The table is stored in the last good block with a backup in the penultimate good block. By default, the last four physical blocks are reserved for s. If there are fewer than two good blocks available in the last four, then the NAND device should be discarded.

In a ideal situation, the  should be built and written to Flash before any other data. This is mandatory in cases where it is not possible to use the ECC tags to distinguish between valid programmed  data and an . However, this has implications for manufacturability, as the NAND programmer needs to be taught how to write the , including the relevant .

In some cases, it may be appropriate for the NAND Programmer to skip writing s, and to defer  creation to the software drivers when the system is first booted. This avoids the complexities of customising the NAND Programmer, whilst retaining the benefits of using NAND-residents. This approach is only viable if there is no clash between the  layout and the  location, or where  tags can be used to avoid ECC data being misinterpreted as a .

转载地址：http://nqsgi.baihongyu.com/