summaryrefslogtreecommitdiff
path: root/include/mxs_nand.h
diff options
context:
space:
mode:
authorYe Li <ye.li@nxp.com>2020-05-04 22:08:50 +0800
committerStefano Babic <sbabic@denx.de>2020-05-10 20:55:20 +0200
commit616f03dabacb6c500e8a7ceb920cd08554c9fcae (patch)
tree78912a6c4a22c389867d433eadcb780a22f933e7 /include/mxs_nand.h
parent77ed80c9ec415ac8b77336215c1cf2fa26d00689 (diff)
mtd: gpmi: change the BCH layout setting for large oob NAND
The code change updated the NAND driver BCH ECC layout algorithm to support large oob size NAND chips(oob > 1024 bytes) and proposed a new way to set ECC layout. Current implementation requires each chunk size larger than oob size so the bad block marker (BBM) can be guaranteed located in data chunk. The ECC layout always using the unbalanced layout(Ecc for both meta and Data0 chunk), but for the NAND chips with oob larger than 1k, the driver cannot support because BCH doesn’t support GF 15 for 2K chunk. The change keeps the data chunk no larger than 1k and adjust the ECC strength or ECC layout to locate the BBM in data chunk. General idea for large oob NAND chips is 1.Try all ECC strength from the minimum value required by NAND spec to the maximum one that works, any ECC makes the BBM locate in data chunk can be chosen. 2.If none of them works, using separate ECC for meta, which will add one extra ecc with the same ECC strength as other data chunks. This extra ECC can guarantee BBM located in data chunk, of course, we need to check if oob can afford it. Previous code has two methods for ECC layout setting, the legacy_calc_ecc_layout and calc_ecc_layout_by_info, the difference between these two methods is, legacy_calc_ecc_layout set the chunk size larger chan oob size and then set the maximum ECC strength that oob can afford. While the calc_ecc_layout_by_info set chunk size and ECC strength according to NAND spec. It has been proved that the first method cannot provide safe ECC strength for some modern NAND chips, so in current code, 1. Driver read NAND parameters first and then chose the proper ECC layout setting method. 2. If the oob is large or NAND required data chunk larger than oob size, chose calc_ecc_for_large_oob, otherwise use calc_ecc_layout_by_info 3. legacy_calc_ecc_layout only used for some NAND chips does not contains necessary information. So this is only a backup plan, it is NOT recommended to use these NAND chips. Signed-off-by: Han Xu <b45815@freescale.com> Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Diffstat (limited to 'include/mxs_nand.h')
-rw-r--r--include/mxs_nand.h12
1 files changed, 8 insertions, 4 deletions
diff --git a/include/mxs_nand.h b/include/mxs_nand.h
index ada20483d0..497da77a16 100644
--- a/include/mxs_nand.h
+++ b/include/mxs_nand.h
@@ -16,22 +16,26 @@
* @gf_len: The length of Galois Field. (e.g., 13 or 14)
* @ecc_strength: A number that describes the strength of the ECC
* algorithm.
- * @ecc_chunk_size: The size, in bytes, of a single ECC chunk. Note
- * the first chunk in the page includes both data and
- * metadata, so it's a bit larger than this value.
+ * @ecc_chunk0_size: The size, in bytes, of a first ECC chunk.
+ * @ecc_chunkn_size: The size, in bytes, of a single ECC chunk after
+ * the first chunk in the page.
* @ecc_chunk_count: The number of ECC chunks in the page,
* @block_mark_byte_offset: The byte offset in the ECC-based page view at
* which the underlying physical block mark appears.
* @block_mark_bit_offset: The bit offset into the ECC-based page view at
* which the underlying physical block mark appears.
+ * @ecc_for_meta: The flag to indicate if there is a dedicate ecc
+ * for meta.
*/
struct bch_geometry {
unsigned int gf_len;
unsigned int ecc_strength;
- unsigned int ecc_chunk_size;
+ unsigned int ecc_chunk0_size;
+ unsigned int ecc_chunkn_size;
unsigned int ecc_chunk_count;
unsigned int block_mark_byte_offset;
unsigned int block_mark_bit_offset;
+ unsigned int ecc_for_meta; /* ECC for meta data */
};
struct mxs_nand_info {