Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
docs:techref:flash [2019/01/21 23:03] – added section "Innocent mtdblock I/O errors" with pordocs:techref:flash [2023/03/04 17:29] (current) – [NAND-specific tools for reading and writing to raw NAND] openwart
Line 69: Line 69:
 Marking a bad block means: Adding this bad block to a table of bad blocks (which is mostly settled at the end of the flash). Since this table sit within blocks on the flash, which might get bad as well, this table is usually redundant. Marking a bad block means: Adding this bad block to a table of bad blocks (which is mostly settled at the end of the flash). Since this table sit within blocks on the flash, which might get bad as well, this table is usually redundant.
    
-Bad blocks happen, especially on NAND flash. Even never used NAND flash, right from the factory, might contain bad blocks. Because of that, NAND flash manufacturers ship their flash with “pre-installed” information about which blocks are bad from the beginning. Unfortunately, how this information is stored on the flash, is vendor / product specific. Another common area to store this kind of information the OOB area (if existing) of the flash.+Bad blocks happen, especially on NAND flash. Even never used NAND flash, right from the factory, might contain bad blocks. Because of that, NAND flash manufacturers ship their flash with “pre-installed” information about which blocks are bad from the beginning. Unfortunately, how this information is stored on the flash, is vendor / product specific. Another common area to store this kind of information is the OOB area (if existing) of the flash.
    
-This also means, flash of the very some vendor and product, will have a different amount of usable blocks. This is a fact you have to deal with – don’t be too tight in your calculation, **you’re going to need space in spare as replacement for bad blocks!**+This also means, flash of the very same vendor and product, will have a different amount of usable blocks. This is a fact you have to deal with – don’t be too tight in your calculation, **you’re going to need space in spare as replacement for bad blocks!**
  
 ==== Hardware vs. Software ==== ==== Hardware vs. Software ====
Line 100: Line 100:
 <code>print_req_error: I/O error, dev mtdblock1, sector 0</code> <code>print_req_error: I/O error, dev mtdblock1, sector 0</code>
  
-Explanation: (quoted from [[https://bugs.openwrt.org/index.php?do=details&task_id=1871|FS#1871, closing comment bij Jonas Gorski]])+Explanation: (quoted from [[https://bugs.openwrt.org/index.php?do=details&task_id=1871|FS#1871, closing comment by Jonas Gorski]])
  
-The first few blocks of a NAND flash are guaranteed good to ensure that a bootloader stored there can never get corrupted, so it will get written without valid ECC data (the SoC won't check the ECC anyway). +>The first few blocks of a NAND flash are guaranteed good to ensure that a bootloader stored there can never get corrupted, so it will get written without valid ECC data (the SoC won't check the ECC anyway). 
- +> 
-When block-mount scans all block devices, it will try to read from those blocks, which are exposed as partitions, and the NAND driver will report failed ECC checks (the I/O errors in the log). +>When block-mount scans all block devices, it will try to read from those blocks, which are exposed as partitions, and the NAND driver will report failed ECC checks (the I/O errors in the log). 
- +> 
-There is nothing wrong here in either way, and nothing we can really do to prevent it.+>There is nothing wrong here in either way, and nothing we can really do to prevent it.
 ===== NAND memory and bitflips ===== ===== NAND memory and bitflips =====
  
Line 144: Line 144:
 Likewise nandwrite writes the image also writing the appropriate parity data for the ECC logic to work when reading it. Likewise nandwrite writes the image also writing the appropriate parity data for the ECC logic to work when reading it.
  
-The **dd** tool (or more advanced ones like **pv** is not aware of NAND ECC logic, so it will read all the NAND partition, both data AND parity and will generate a backup that is exactly the same as actually on flash, but is completely useless and unreadable as it will contain both data and hardware-specific parity information which cannot be restored on a different device. Likewise on writing, it will not write parity information for ECC logic to work, so whatever you write will be read as garbage.+The **dd** tool (or more advanced ones like **pv**) is not aware of NAND ECC logic, so it will read all the NAND partition, both data AND parity and will generate a backup that is exactly the same as actually on flash, but is completely useless and unreadable as it will contain both data and hardware-specific parity information which cannot be restored on a different device. Likewise on writing, it will not write parity information for ECC logic to work, so whatever you write will be read as garbage.
  
 Tools like **dd** and **pv** can only be used on block devices. SSDs, SDcards, Hard drives (yes also mechanical hard drives have ECC logic integrated),  and so on where any ECC is done by the storage controller, not by the system, so whatever it reads is pure data, no metadata or parity for ECC logic. Tools like **dd** and **pv** can only be used on block devices. SSDs, SDcards, Hard drives (yes also mechanical hard drives have ECC logic integrated),  and so on where any ECC is done by the storage controller, not by the system, so whatever it reads is pure data, no metadata or parity for ECC logic.
  
  
  • Last modified: 2019/01/21 23:03
  • by por