SPVA070 June   2026 AM2752-Q1 , AM2754-Q1 , AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM62A1-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62D-Q1 , AM62P , AM62P-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Bad Block Management
    1. 2.1 Block Failure
    2. 2.2 Feasibility of Reversing Bad Blocks
  6. 3Bad Block Management in ROM Bootloader
  7. 4Bad Block Management in TITM MCU+ SDK
    1. 4.1 Flash Read Operation Flow
    2. 4.2 Flash Write Operation Flow
    3. 4.3 Flash Erase Operation Flow
  8. 5Bad Block Management in TITM Processors SDK
    1. 5.1 Flash Read Operation Flow
    2. 5.2 Flash Write Operation Flow
    3. 5.3 Flash Erase Operation Flow
  9. 6Summary
  10. 7References

5 Bad Block Management in TITM Processors SDK

The Linux Kernel implements Bad Block Management through the Memory Technology Device (MTD) subsystem and the Unsorted Block Images (UBI) with the following key features:

  1. Bad Block Table Initialization
    • During flash driver initialization, the system creates an in-memory Bad Block table using a bitmap structure:

      • Each block's first page Out-Of-Band area is read.

      • The bad block marker consists of 2 bytes at typically the beginning of the OOB area.

      • A marker value of 0xFF for both bytes indicates a good block.

      • Any non-0xFF value (typically 0x00) indicates a factory-marked bad block or runtime bad block.

    • A Bad Block Table is constructed in memory using 2 bits per block to encode the status:
      • 00b = Good block, which indicates that the block is available for use.
      • 01b = Worn or runtime bad block which indicates that the erase or write operation failed during runtime.
      • 10b = Reserved block.
      • 11b = Factory bad block which is marked by the manufacturer.

    • On every system boot, the Bad Block Table is rebuilt by scanning the OOB markers of all the blocks present in the Flash.

  2. Bad Block Skipping
    • All read, write, and erase operations automatically consult the in-memory Bad Block Table before accessing physical blocks.
    • The UBI layer maintains the Physical Erase Block (PEB) organization using three Red-Black trees:
      • Free Tree: Contains erased, good PEBs available for allocation, sorted by erase count for wear-leveling.
      • Used Tree: Contains PEBs currently storing volume data.
      • Erroneous Tree: Contains PEBs marked as bad or unreliable.
    • When the UBI layer needs to allocate a block for writing:
      • A PEB is selected from the free tree. A PEB is never selected from the erroneous tree.
      • The bad block status is verified by querying the BBT through the MTD layer.
      • If the block is marked bad, it is removed from the free tree, added to the erroneous tree, and a different PEB is selected.
    • The BBT lookup uses efficient bit manipulation for fast access:
      • Byte offset in BBT array = PEB number ÷ 4 (since each byte holds four 2-bit entries)
      • Bit position within byte = (PEB number mod 4) × 2
    • The 2-bit status code is the extracted using the following implementation: (BBT_byte >> bit_position) & 0x03
    • When a bad block is encountered during logical-to-physical address translation, the operation automatically skips to the next good block, making bad block avoidance transparent to upper layers.
  3. Runtime Bad Block Marking
    • Program, erase, and read operations are continuously monitored for failure conditions through multiple mechanisms:
      • NAND controller status register checking after program and erase operations.
      • Error Correction Code (ECC) engine monitoring during read operations.
      • Wear-leveling algorithm tracking of marginal block behavior.
    • When an operation fails, the affected block is immediately marked as bad through the following sequence:
      • Program Failure: The P-FAIL bit of the NAND controller status register is checked after each program operation. If P-FAIL = 1 indicates that the program operation timed out or failed, triggering bad block marking.
      • Erase Failure: E-FAIL bit of the NAND controller status register is checked after each erase operation. If E-FAIL = 1 indicates that the erase operation failed, triggering bad block marking.
      • ECC Uncorrectable Error: When the number of bit errors in a page exceeds the ECC correction capability, that is, more than 8 bits for BCH-8 or 16 bits for BCH-16, the block is marked as failing.
    • The bad block marking procedure executes the following steps:
      • Update In-Memory BBT: The 2-bit status code for the failed block is changed from 00b, indicating a good block to 01b indicating runtime bad block.
      • Write Bad Block Marker to OOB: The bad block marker bytes (0x00,0x00) is written to the spare area or OOB of the first page of the failed block.

      • This ensures persistence across power cycles, as the in-memory BBT will be rebuilt from these markers on the next boot.

    • The UBI layer updates its data structures:

      • The bad PEB is removed from the free tree or used tree, depending on where it was located.

      • The bad PEB is added to the erroneous tree to prevent future allocation.

      • If the bad PEB was storing volume data, the LEB-to-PEB mapping is updated to invalidate affected logical erase blocks.

    • Subsequent operations automatically avoid the newly marked block, as it now resides in the erroneous tree and has status 01b in the BBT.