Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| docs:techref:flash [2020/09/01 17:50] – [Innocent mtdblock I/O errors] Quoting added tmomas | docs: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, | + | 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, |
| - | 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, | + | 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, |
| ==== Hardware vs. Software ==== | ==== Hardware vs. Software ==== | ||
| 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), | 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), | ||