mtd: nand: raw: gpmi: new bch geometry settings
Subsystems (4)
Han Xu
maintainerPATCH 1/2 mtd: nand: raw: gpmi: new bch geometry settings
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility.
- For the legacy bch geometry settings
The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info.
The legacy_set_geometry() sets the data chunk size(step_size) larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk.
This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time.
- For the large oob bch geometry settings
This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is,
1.Try all ECC strength from the minimum value required by NAND chip
to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible.
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, also we need to check if oob can afford it.
- For all other common cases
set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required.
--- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 262 ++++++++++++++++++--- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h | 12 +- 2 files changed, 231 insertions(+), 43 deletions(-)
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +223 -39
@@ -218,7 +218,8 @@ static void gpmi_dump_info(struct gpmi_nand_data *this)"ECC Strength : %u\n" "Page Size in Bytes : %u\n" "Metadata Size in Bytes : %u\n" -"ECC Chunk Size in Bytes: %u\n" +"ECC Chunk0 Size in Bytes: %u\n" +"ECC Chunkn Size in Bytes: %u\n" "ECC Chunk Count : %u\n" "Payload Size in Bytes : %u\n" "Auxiliary Size in Bytes: %u\n"
@@ -229,7 +230,8 @@ static void gpmi_dump_info(struct gpmi_nand_data *this) geo->ecc_strength, geo->page_size, geo->metadata_size, - geo->ecc_chunk_size, + geo->ecc_chunk0_size, + geo->ecc_chunkn_size, geo->ecc_chunk_count, geo->payload_size, geo->auxiliary_size,
@@ -251,6 +253,37 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)return geo->ecc_strength <= this->devdata->bch_max_ecc_strength; } +static inline bool bbm_in_data_chunk (struct gpmi_nand_data *this, +unsigned int *chunk_num) +{ +struct bch_geometry *geo = &this->bch_geometry; +struct nand_chip *chip = &this->nand; +struct mtd_info *mtd =nand_to_mtd (chip); +unsigned int i, j; + +if (geo->ecc_chunk0_size != geo->ecc_chunkn_size) { +dev_err (this->dev,"The size of chunk0 must equal to chunkn\n" ); +return false; + } + + i = (mtd->writesize *8 - geo->metadata_size *8 ) / + (geo->gf_len * geo->ecc_strength + + geo->ecc_chunkn_size *8 ); + + j = (mtd->writesize *8 - geo->metadata_size *8 ) - + (geo->gf_len * geo->ecc_strength + + geo->ecc_chunkn_size *8 ) * i; + +if (j < geo->ecc_chunkn_size *8 ) { + *chunk_num = i+1 ; +dev_dbg (this->dev,"Set ecc to %d and bbm in chunk %d\n" , + geo->ecc_strength, *chunk_num); +return true; + } + +return false; +} +/* * If we can get the ECC information from the nand chip, we do not * need to calculate them ourselves.
@@ -280,13 +313,14 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this, nanddev_get_ecc_requirements(&chip->base)->step_size);return -EINVAL ; } - geo->ecc_chunk_size = ecc_step; + geo->ecc_chunk0_size = ecc_step; + geo->ecc_chunkn_size = ecc_step; geo->ecc_strength =round_up (ecc_strength,2 );if (!gpmi_check_ecc (this))return -EINVAL ;/* Keep the C >= O */ -if (geo->ecc_chunk_size < mtd->oobsize) { +if (geo->ecc_chunkn_size < mtd->oobsize) {dev_err (this->dev,"unsupported nand chip. ecc size: %d, oob size : %d\n" , ecc_step, mtd->oobsize);
@@ -296,7 +330,7 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this,/* The default value, see comment in the legacy_set_geometry(). */ geo->metadata_size =10 ; - geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size; + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunkn_size;/* * Now, the NAND chip with 2K page(data chunk is 512byte) shows below:
@@ -399,6 +433,132 @@ static inline int get_ecc_strength(struct gpmi_nand_data *this)return round_down (ecc_strength,2 ); } +static int set_geometry_for_large_oob (struct gpmi_nand_data *this) +{ +struct bch_geometry *geo = &this->bch_geometry; +struct nand_chip *chip = &this->nand; +struct mtd_info *mtd =nand_to_mtd (chip); +const struct nand_ecc_props *requirements = +nanddev_get_ecc_requirements (&chip->base); +unsigned int block_mark_bit_offset; +unsigned int max_ecc; +unsigned int bbm_chunk; +unsigned int i; + +/* sanity check for the minimum ecc nand required */ +if (!(requirements->strength >0 && + requirements->step_size >0 )) +return -EINVAL ; + geo->ecc_strength = requirements->strength; + +/* check if platform can support this nand */ +if (!gpmi_check_ecc (this)) { +dev_err (this->dev, +"unsupported NAND chip, minimum ecc required %d\n" , + geo->ecc_strength); +return -EINVAL ; + } + +/* calculate the maximum ecc platform can support*/ + geo->metadata_size =10 ; + geo->gf_len =14 ; + geo->ecc_chunk0_size =1024 ; + geo->ecc_chunkn_size =1024 ; + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunkn_size; + max_ecc =min (get_ecc_strength (this), + this->devdata->bch_max_ecc_strength); + +/* search a supported ecc strength that makes bbm */ +/* located in data chunk */ + geo->ecc_strength = requirements->strength; +while (!(geo->ecc_strength > max_ecc)) { +if (bbm_in_data_chunk (this, &bbm_chunk)) + goto geo_setting; + geo->ecc_strength +=2 ; + } + +/* if none of them works, keep using the minimum ecc */ +/* nand required but changing ecc page layout */ + geo->ecc_strength = requirements->strength; +/* add extra ecc for meta data */ + geo->ecc_chunk0_size =0 ; + geo->ecc_chunk_count = (mtd->writesize / geo->ecc_chunkn_size) +1 ; + geo->ecc_for_meta =1 ; +/* check if oob can afford this extra ecc chunk */ +if (mtd->oobsize *8 < geo->metadata_size *8 + + geo->gf_len * geo->ecc_strength * geo->ecc_chunk_count) { +dev_err (this->dev,"unsupported NAND chip with new layout\n" ); +return -EINVAL ; + } + +/* calculate in which chunk bbm located */ + bbm_chunk = (mtd->writesize *8 - geo->metadata_size *8 - + geo->gf_len * geo->ecc_strength) / + (geo->gf_len * geo->ecc_strength + + geo->ecc_chunkn_size *8 ) +1 ; + +geo_setting: + + geo->page_size = mtd->writesize + geo->metadata_size + + (geo->gf_len * geo->ecc_strength * geo->ecc_chunk_count) /8 ; + geo->payload_size = mtd->writesize; + +/* +* The auxiliary buffer contains the metadata and the ECC status. The +* metadata is padded to the nearest 32-bit boundary. The ECC status +* contains one byte for every ECC chunk, and is also padded to the +* nearest 32-bit boundary. +*/ + geo->auxiliary_status_offset =ALIGN (geo->metadata_size,4 ); + geo->auxiliary_size =ALIGN (geo->metadata_size,4 ) + +ALIGN (geo->ecc_chunk_count,4 ); + +if (!this->swap_block_mark) +return 0 ; + +/* calculate the number of ecc chunk behind the bbm */ + i = (mtd->writesize / geo->ecc_chunkn_size) - bbm_chunk +1 ; + + block_mark_bit_offset = mtd->writesize *8 - + (geo->ecc_strength * geo->gf_len * (geo->ecc_chunk_count - i) + + geo->metadata_size *8 ); + + geo->block_mark_byte_offset = block_mark_bit_offset /8 ; + geo->block_mark_bit_offset = block_mark_bit_offset %8 ; + +dev_dbg (this->dev,"BCH Geometry :\n" +"GF length : %u\n" +"ECC Strength : %u\n" +"Page Size in Bytes : %u\n" +"Metadata Size in Bytes : %u\n" +"ECC Chunk0 Size in Bytes: %u\n" +"ECC Chunkn Size in Bytes: %u\n" +"ECC Chunk Count : %u\n" +"Payload Size in Bytes : %u\n" +"Auxiliary Size in Bytes: %u\n" +"Auxiliary Status Offset: %u\n" +"Block Mark Byte Offset : %u\n" +"Block Mark Bit Offset : %u\n" +"Block Mark in chunk : %u\n" +"Ecc for Meta data : %u\n" , + geo->gf_len, + geo->ecc_strength, + geo->page_size, + geo->metadata_size, + geo->ecc_chunk0_size, + geo->ecc_chunkn_size, + geo->ecc_chunk_count, + geo->payload_size, + geo->auxiliary_size, + geo->auxiliary_status_offset, + geo->block_mark_byte_offset, + geo->block_mark_bit_offset, + bbm_chunk, + geo->ecc_for_meta); + +return 0 ; +} +static int legacy_set_geometry (struct gpmi_nand_data *this) {struct bch_geometry *geo = &this->bch_geometry;
@@ -407,6 +567,7 @@ static int legacy_set_geometry(struct gpmi_nand_data *this)unsigned int status_size;unsigned int block_mark_bit_offset; +dev_warn (this->dev,"use legacy bch geometry\n" );/* * The size of the metadata can be changed, though we set it to 10 * bytes now. But it can't be too large, because we have to save
@@ -418,13 +579,15 @@ static int legacy_set_geometry(struct gpmi_nand_data *this) geo->gf_len =13 ;/* The default for chunk size. */ - geo->ecc_chunk_size =512 ; -while (geo->ecc_chunk_size < mtd->oobsize) { - geo->ecc_chunk_size *=2 ;/* keep C >= O */ + geo->ecc_chunk0_size =512 ; + geo->ecc_chunkn_size =512 ; +while (geo->ecc_chunkn_size < mtd->oobsize) { + geo->ecc_chunk0_size *=2 ;/* keep C >= O */ + geo->ecc_chunkn_size *=2 ;/* keep C >= O */ geo->gf_len =14 ; } - geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size; + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunkn_size;/* We use the same ECC strength for all chunks. */ geo->ecc_strength =get_ecc_strength (this);
@@ -514,24 +677,23 @@ static int legacy_set_geometry(struct gpmi_nand_data *this)static int common_nfc_set_geometry (struct gpmi_nand_data *this) {struct nand_chip *chip = &this->nand; +struct mtd_info *mtd =nand_to_mtd (&this->nand);const struct nand_ecc_props *requirements =nanddev_get_ecc_requirements (&chip->base); -if (chip->ecc.strength >0 && chip->ecc.size >0 ) -return set_geometry_by_ecc_info (this, chip->ecc.strength, - chip->ecc.size); - -if ((of_property_read_bool (this->dev->of_node,"fsl,use-minimum-ecc" )) - ||legacy_set_geometry (this)) { -if (!(requirements->strength >0 && requirements->step_size >0 )) -return -EINVAL ; +/* first check if need to use legacy bch geometry settings */ +if ((!(requirements->strength >0 && requirements->step_size >0 ) && + mtd->oobsize <1024 ) || +of_property_read_bool (this->dev->of_node,"fsl,legacy-bch-geometry" )) +return legacy_set_geometry (this); -return set_geometry_by_ecc_info (this, - requirements->strength, - requirements->step_size); - } +/* then check if need to set bch geometry for large oob nand */ +if (mtd->oobsize >1024 || requirements->step_size < mtd->oobsize) +return set_geometry_for_large_oob (this); -return 0 ; +/* set bch geometry by nand chip minimum required strength & step size*/ +return set_geometry_by_ecc_info (this, requirements->strength, + requirements->step_size); }/* Configures the geometry for BCH. */
@@ -806,7 +968,7 @@ static int gpmi_raw_len_to_len(struct gpmi_nand_data *this, int raw_len)* we are passed in exec_op. Calculate the data length from it. */ if (this->bch) -return ALIGN_DOWN (raw_len, this->bch_geometry.ecc_chunk_size); +return ALIGN_DOWN (raw_len, this->bch_geometry.ecc_chunkn_size);else return raw_len; }
@@ -1212,7 +1374,7 @@ static int gpmi_count_bitflips(struct nand_chip *chip, void *buf, int first,/* Read ECC bytes into our internal raw_buffer */ offset = nfc_geo->metadata_size *8 ; - offset += ((8 * nfc_geo->ecc_chunk_size) + eccbits) * (i +1 ); + offset += ((8 * nfc_geo->ecc_chunkn_size) + eccbits) * (i +1 ); offset -= eccbits; bitoffset = offset %8 ; eccbytes =DIV_ROUND_UP (offset + eccbits,8 );
@@ -1249,16 +1411,16 @@ static int gpmi_count_bitflips(struct nand_chip *chip, void *buf, int first,if (i ==0 ) {/* The first block includes metadata */ flips =nand_check_erased_ecc_chunk ( - buf + i * nfc_geo->ecc_chunk_size, - nfc_geo->ecc_chunk_size, + buf + i * nfc_geo->ecc_chunkn_size, + nfc_geo->ecc_chunkn_size, eccbuf, eccbytes, this->auxiliary_virt, nfc_geo->metadata_size, nfc_geo->ecc_strength); }else { flips =nand_check_erased_ecc_chunk ( - buf + i * nfc_geo->ecc_chunk_size, - nfc_geo->ecc_chunk_size, + buf + i * nfc_geo->ecc_chunkn_size, + nfc_geo->ecc_chunkn_size, eccbuf, eccbytes,NULL ,0 , nfc_geo->ecc_strength);
@@ -1287,20 +1449,21 @@ static void gpmi_bch_layout_std(struct gpmi_nand_data *this)struct bch_geometry *geo = &this->bch_geometry;unsigned int ecc_strength = geo->ecc_strength >>1 ;unsigned int gf_len = geo->gf_len; -unsigned int block_size = geo->ecc_chunk_size; +unsigned int block0_size = geo->ecc_chunk0_size; +unsigned int blockn_size = geo->ecc_chunkn_size; this->bch_flashlayout0 =BF_BCH_FLASH0LAYOUT0_NBLOCKS (geo->ecc_chunk_count -1 ) |BF_BCH_FLASH0LAYOUT0_META_SIZE (geo->metadata_size) |BF_BCH_FLASH0LAYOUT0_ECC0 (ecc_strength, this) |BF_BCH_FLASH0LAYOUT0_GF (gf_len, this) | -BF_BCH_FLASH0LAYOUT0_DATA0_SIZE (block_size, this); +BF_BCH_FLASH0LAYOUT0_DATA0_SIZE (block0_size, this); this->bch_flashlayout1 =BF_BCH_FLASH0LAYOUT1_PAGE_SIZE (geo->page_size) |BF_BCH_FLASH0LAYOUT1_ECCN (ecc_strength, this) |BF_BCH_FLASH0LAYOUT1_GF (gf_len, this) | -BF_BCH_FLASH0LAYOUT1_DATAN_SIZE (block_size, this); +BF_BCH_FLASH0LAYOUT1_DATAN_SIZE (blockn_size, this); } static int gpmi_ecc_read_page(struct nand_chip *chip, uint8_t *buf,
@@ -1383,9 +1546,22 @@ static int gpmi_ecc_read_subpage(struct nand_chip *chip, uint32_t offs, } } +/* +* if there is an ECC dedicate for meta: +* - need to add an extra ECC size when calculating col and page_size, +* if the meta size is NOT zero. +* - chunk0 size need to set to the same size as other chunks, +* if the meta size is zero. +*/ + meta = geo->metadata_size;if (first) { - col = meta + (size + ecc_parity_size) * first; +if (geo->ecc_for_meta) + col = meta + ecc_parity_size + + (size + ecc_parity_size) * first; +else + col = meta + (size + ecc_parity_size) * first; + meta =0 ; buf = buf + first * size; }
@@ -1393,19 +1569,27 @@ static int gpmi_ecc_read_subpage(struct nand_chip *chip, uint32_t offs, ecc_parity_size = geo->gf_len * geo->ecc_strength /8 ; n = last - first +1 ; - page_size = meta + (size + ecc_parity_size) * n; + +if (geo->ecc_for_meta && meta) + page_size = meta + ecc_parity_size + + (size + ecc_parity_size) * n; +else + page_size = meta + (size + ecc_parity_size) * n; + ecc_strength = geo->ecc_strength >>1 ; - this->bch_flashlayout0 =BF_BCH_FLASH0LAYOUT0_NBLOCKS (n -1 ) | + this->bch_flashlayout0 =BF_BCH_FLASH0LAYOUT0_NBLOCKS ( + (geo->ecc_for_meta ? n : n -1 )) |BF_BCH_FLASH0LAYOUT0_META_SIZE (meta) |BF_BCH_FLASH0LAYOUT0_ECC0 (ecc_strength, this) |BF_BCH_FLASH0LAYOUT0_GF (geo->gf_len, this) | -BF_BCH_FLASH0LAYOUT0_DATA0_SIZE (geo->ecc_chunk_size, this); +BF_BCH_FLASH0LAYOUT0_DATA0_SIZE ((geo->ecc_for_meta ? +0 : geo->ecc_chunk0_size), this); this->bch_flashlayout1 =BF_BCH_FLASH0LAYOUT1_PAGE_SIZE (page_size) |BF_BCH_FLASH0LAYOUT1_ECCN (ecc_strength, this) |BF_BCH_FLASH0LAYOUT1_GF (geo->gf_len, this) | -BF_BCH_FLASH0LAYOUT1_DATAN_SIZE (geo->ecc_chunk_size, this); +BF_BCH_FLASH0LAYOUT1_DATAN_SIZE (geo->ecc_chunkn_size, this); this->bch = true;
@@ -1577,7 +1761,7 @@ static int gpmi_ecc_read_page_raw(struct nand_chip *chip, uint8_t *buf,struct mtd_info *mtd =nand_to_mtd (chip);struct gpmi_nand_data *this =nand_get_controller_data (chip);struct bch_geometry *nfc_geo = &this->bch_geometry; -int eccsize = nfc_geo->ecc_chunk_size; +int eccsize = nfc_geo->ecc_chunkn_size;int eccbits = nfc_geo->ecc_strength * nfc_geo->gf_len;u8 *tmp_buf = this->raw_buffer;size_t src_bit_off;
@@ -1662,7 +1846,7 @@ static int gpmi_ecc_write_page_raw(struct nand_chip *chip, const uint8_t *buf,struct mtd_info *mtd =nand_to_mtd (chip);struct gpmi_nand_data *this =nand_get_controller_data (chip);struct bch_geometry *nfc_geo = &this->bch_geometry; -int eccsize = nfc_geo->ecc_chunk_size; +int eccsize = nfc_geo->ecc_chunkn_size;int eccbits = nfc_geo->ecc_strength * nfc_geo->gf_len;u8 *tmp_buf = this->raw_buffer;uint8_t *oob = chip->oob_poi;
@@ -2036,7 +2220,7 @@ static int gpmi_init_last(struct gpmi_nand_data *this) ecc->read_oob_raw = gpmi_ecc_read_oob_raw; ecc->write_oob_raw = gpmi_ecc_write_oob_raw; ecc->engine_type =NAND_ECC_ENGINE_TYPE_ON_HOST ; - ecc->size = bch_geo->ecc_chunk_size; + ecc->size = bch_geo->ecc_chunkn_size; ecc->strength = bch_geo->ecc_strength;mtd_set_ooblayout (mtd, &gpmi_ooblayout_ops);
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h +8 -4
@@ -30,9 +30,9 @@ struct resources {* @page_size: The size, in bytes, of a physical page, including * both data and OOB. * @metadata_size: The size, in bytes, of the metadata. -* @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, * @payload_size: The size, in bytes, of the payload buffer. * @auxiliary_size: The size, in bytes, of the auxiliary buffer.
@@ -42,19 +42,23 @@ struct resources {* 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 page_size;unsigned int metadata_size; -unsigned int ecc_chunk_size; +unsigned int ecc_chunk0_size; +unsigned int ecc_chunkn_size;unsigned int ecc_chunk_count;unsigned int payload_size;unsigned int auxiliary_size;unsigned int auxiliary_status_offset;unsigned int block_mark_byte_offset;unsigned int block_mark_bit_offset; +unsigned int ecc_for_meta;/* ECC for meta data */ };/**
Signature · 1 line
2.17.1
Han Xu
maintainerPATCH 2/2 dt-bindings: mtd: gpmi-nand: add new fsl,legacy-bch-geometry flag
New bch geometry setting uses the minimum NAND chip required ecc strength and step size by default. This flag was designed for backward compatible. The fsl,use-minimum-ecc flag can be deprecated.
--- Documentation/devicetree/bindings/mtd/gpmi-nand.yaml | 9 +++++++++ 1 file changed, 9 insertions(+)
Documentation/devicetree/bindings/mtd/gpmi-nand.yaml +9 -0
@@ -62,6 +62,7 @@ properties: fsl,use-minimum-ecc: type: boolean + deprecated: true description: | Protect this NAND flash with the minimum ECC strength required. The required ECC strength is automatically discoverable for some
@@ -69,6 +70,14 @@ properties: if this strength is not discoverable or this property is not enabled, the software may chooses an implementation-defined ECC scheme. + fsl,legacy-bch-geometry: + type: boolean + description: | + Enable the legacy bch geometry setting, which will set the data chunk + size larger than oob size and chose the maximum ecc strength oob can + hold. This flag was designed for backward compatible or old NAND chip + support, should be en/disabled in u-boot and kernel at the same time. + fsl,no-blockmark-swap: type: boolean description: |
Signature · 1 line
2.17.1
Quoted 5 lines · Han Xu
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility.
This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch)
Quoted 5 lines
- For the legacy bch geometry settings
The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info.
NAND's are providing the minimum required ecc, the now legacy method actually gives more ecc bits and quite cheap when using hw ecc.
Quoted 25 lines
The
legacy_set_geometry()sets the data chunksize(step_size)larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk.This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time.
- For the large oob bch geometry settings
This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is,1.Try all ECC strength from the minimum value required by NAND chip
to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible.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, also we need to check if oob can afford it.
Quoted 5 lines
- For all other common cases
set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required.Signed-off-by Han Xu <[email protected]>
One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is calculated with this patch applied(without the legacy option set).
It's quite a mess :/
I would recommend to use the legacy mode as default, and add the new style as "modern" option. (Also in u-boot)
/Sean
Han Xu
maintainerQuoted 49 lines · Sean Nyekjaer
Quoted 5 lines · Han Xu
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility.
This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch)
Quoted 5 lines
- For the legacy bch geometry settings
The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info.NAND's are providing the minimum required ecc, the now legacy method actually gives more ecc bits and quite cheap when using hw ecc.
Quoted 25 lines
The
legacy_set_geometry()sets the data chunksize(step_size)larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk.This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time.
- For the large oob bch geometry settings
This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is,1.Try all ECC strength from the minimum value required by NAND chip
to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible.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, also we need to check if oob can afford it.Quoted 5 lines
- For all other common cases
set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required.Signed-off-by Han Xu <[email protected]>
Quoted 8 lines
One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is calculated with this patch applied(without the legacy option set).
It's quite a mess :/
I would recommend to use the legacy mode as default, and add the new style as "modern" option. (Also in u-boot)/Sean
Hi Sean,
I know this change brings mess but the legacy way is wrong. The way it determine the data chunk size is arbitrary, take any 8K + 448 (not 744, typo in previous comments) Micron NAND chips as example, the legacy way can only provide 16bit ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips. According to the A/B X/Y ecc requirement, this is not acceptable. The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed.
This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way.
The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
Miquel Raynal
maintainerHi Han,
Han Xu <[email protected]> wrote on Tue, 25 May 2021 14:13:08 -0500:
Quoted 57 lines · Sean Nyekjaer
Quoted 56 lines · Han Xu
Quoted 5 lines
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility.
This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch)
Quoted 5 lines
- For the legacy bch geometry settings
The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info.NAND's are providing the minimum required ecc, the now legacy method actually gives more ecc bits and quite cheap when using hw ecc.
Quoted 25 lines
The
legacy_set_geometry()sets the data chunksize(step_size)larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk.This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time.
- For the large oob bch geometry settings
This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is,1.Try all ECC strength from the minimum value required by NAND chip
to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible.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, also we need to check if oob can afford it.Quoted 5 lines
- For all other common cases
set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required.Signed-off-by Han Xu <[email protected]>One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is calculated with this patch applied(without the legacy option set).
It's quite a mess :/
I would recommend to use the legacy mode as default, and add the new style as "modern" option. (Also in u-boot)
Quoted 7 lines
Quoted 1 line
/Sean
Hi Sean,
I know this change brings mess but the legacy way is wrong. The way it determine the data chunk size is arbitrary,
Yes, that's always the case: all default choices are arbitrary in the Linux kernel, there is actually a lot of logic provided by the core to handle that, unless the user requires something specific.
Quoted 3 lines
take any 8K + 448 (not 744, typo in previous
comments) Micron NAND chips as example, the legacy way can only provide 16bit ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips.
This means a strength of 32 bits per kilobyte of data vs 24 bits per kilobyte.
Quoted 1 line
According to the A/B X/Y ecc requirement, this is not acceptable.
What you call the legacy way is even better, the only situation where it may be an issue is if the NAND chip does not feature enough OOB bytes to store the ECC codes, which does not seem to be your primary concern here.
Quoted 2 lines
The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed.
What does "safety guaranteed" means?
Quoted 4 lines
This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way.
How is this an argument? I am usually in favor of moving forward when there is a real justification, but this does not seem the case, unless I am understanding it all the wrong way.
Quoted 3 lines
The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
You are well aware of the upstreaming process, trying to merge something locally, making it used and then complaining because not upstreaming it would break your customers really is your own responsibility.
IMHO the solutions are:
- the current (mainline) default will remain the standard for geometries which are already widely supported
- if there are new geometries that must be supported and do not fit because of the "legacy" logic, then you may detect that and try to fallback to the "modern" way of calculating the ECC parameters (or even jump directly to the modern way if the geometry really is not currently supported officially)
- if your customers want a specific chunk size/strength when rebasing on top of a mainline kernel there are DT properties which do that anyway
- follow Sean advice: introduce a property requesting to use the 'modern' or 'legacy' logic (with a better name than modern) but first check with Rob that this if valid.
Thanks,
Miquèl
Han Xu
maintainerQuoted 80 lines · Miquel Raynal
Hi Han,
Han Xu <[email protected]> wrote on Tue, 25 May 2021 14:13:08 -0500:
Quoted 57 lines · Sean Nyekjaer
Quoted 56 lines · Han Xu
Quoted 5 lines
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility.
This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch)
Quoted 5 lines
- For the legacy bch geometry settings
The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info.NAND's are providing the minimum required ecc, the now legacy method actually gives more ecc bits and quite cheap when using hw ecc.
Quoted 25 lines
The
legacy_set_geometry()sets the data chunksize(step_size)larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk.This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time.
- For the large oob bch geometry settings
This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is,1.Try all ECC strength from the minimum value required by NAND chip
to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible.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, also we need to check if oob can afford it.Quoted 5 lines
- For all other common cases
set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required.Signed-off-by Han Xu <[email protected]>One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is calculated with this patch applied(without the legacy option set).
It's quite a mess :/
I would recommend to use the legacy mode as default, and add the new style as "modern" option. (Also in u-boot)Quoted 7 lines
Quoted 1 line
/Sean
Hi Sean,
I know this change brings mess but the legacy way is wrong. The way it determine the data chunk size is arbitrary,
Yes, that's always the case: all default choices are arbitrary in the Linux kernel, there is actually a lot of logic provided by the core to handle that, unless the user requires something specific.
Quoted 3 lines
take any 8K + 448 (not 744, typo in previous
comments) Micron NAND chips as example, the legacy way can only provide 16bit ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips.This means a strength of 32 bits per kilobyte of data vs 24 bits per kilobyte.
Quoted 6 lines
Quoted 1 line
According to the A/B X/Y ecc requirement, this is not acceptable.
What you call the legacy way is even better, the only situation where it may be an issue is if the NAND chip does not feature enough OOB bytes to store the ECC codes, which does not seem to be your primary concern here.
Hi Miquel,
The legacy ecc strength is fine or even better by average, but it doesn't meet the requirement #2
(1) A / B >= X / Y
(2) A >= X
that's my primary concern.
Quoted 5 lines
Quoted 3 lines
The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed.
What does "safety guaranteed" means?
set minimum ecc required by nand chip at least meet all requirements
Quoted 10 lines
Quoted 5 lines
This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way.
How is this an argument? I am usually in favor of moving forward when there is a real justification, but this does not seem the case, unless I am understanding it all the wrong way.
Quoted 8 lines
Quoted 3 lines
The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
You are well aware of the upstreaming process, trying to merge something locally, making it used and then complaining because not upstreaming it would break your customers really is your own responsibility.
Sorry I understand I should try upstreaming it early, so I am still looking for a chance to avoid further divergence.
Quoted 18 lines
IMHO the solutions are:
- the current (mainline) default will remain the standard for geometries which are already widely supported
- if there are new geometries that must be supported and do not fit because of the "legacy" logic, then you may detect that and try to fallback to the "modern" way of calculating the ECC parameters (or even jump directly to the modern way if the geometry really is not currently supported officially)
- if your customers want a specific chunk size/strength when rebasing on top of a mainline kernel there are DT properties which do that anyway
- follow Sean advice: introduce a property requesting to use the 'modern' or 'legacy' logic (with a better name than modern) but first check with Rob that this if valid.Thanks,
Miquèl
Miquel Raynal
maintainerHi Han,
Han Xu <[email protected]> wrote on Wed, 26 May 2021 09:17:00 -0500:
Quoted 90 lines · Miquel Raynal
Quoted 80 lines
Hi Han,
Han Xu <[email protected]> wrote on Tue, 25 May 2021 14:13:08 -0500:
Quoted 57 lines · Sean Nyekjaer
Quoted 56 lines · Han Xu
Quoted 5 lines
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility.
This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch)
Quoted 5 lines
- For the legacy bch geometry settings
The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info.NAND's are providing the minimum required ecc, the now legacy method actually gives more ecc bits and quite cheap when using hw ecc.
Quoted 25 lines
The
legacy_set_geometry()sets the data chunksize(step_size)larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk.This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time.
- For the large oob bch geometry settings
This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is,1.Try all ECC strength from the minimum value required by NAND chip
to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible.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, also we need to check if oob can afford it.Quoted 5 lines
- For all other common cases
set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required.Signed-off-by Han Xu <[email protected]>One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is calculated with this patch applied(without the legacy option set).
It's quite a mess :/
I would recommend to use the legacy mode as default, and add the new style as "modern" option. (Also in u-boot)Quoted 7 lines
Quoted 1 line
/Sean
Hi Sean,
I know this change brings mess but the legacy way is wrong. The way it determine the data chunk size is arbitrary,
Yes, that's always the case: all default choices are arbitrary in the Linux kernel, there is actually a lot of logic provided by the core to handle that, unless the user requires something specific.
Quoted 3 lines
take any 8K + 448 (not 744, typo in previous
comments) Micron NAND chips as example, the legacy way can only provide 16bit ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips.This means a strength of 32 bits per kilobyte of data vs 24 bits per kilobyte.
Quoted 6 lines
Quoted 1 line
According to the A/B X/Y ecc requirement, this is not acceptable.
What you call the legacy way is even better, the only situation where it may be an issue is if the NAND chip does not feature enough OOB bytes to store the ECC codes, which does not seem to be your primary concern here.
Hi Miquel,
Quoted 7 lines
The legacy ecc strength is fine or even better by average, but it doesn't meet the requirement #2
(1) A / B >= X / Y
(2) A >= Xthat's my primary concern.
I understand that (2) might be ideal to meet but is breaking all the boards that use this driver really worth the trouble?
Short answer: no. So we need to adapt the calculation for new boards/new flash chips/certain geometries at most.
Quoted 21 lines
Quoted 4 lines
Quoted 2 lines
The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed.
What does "safety guaranteed" means?
set minimum ecc required by nand chip at least meet all requirements
Quoted 14 lines
Quoted 5 lines
This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way.
How is this an argument? I am usually in favor of moving forward when there is a real justification, but this does not seem the case, unless I am understanding it all the wrong way.
Quoted 3 lines
The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
Quoted 23 lines
Quoted 4 lines
You are well aware of the upstreaming process, trying to merge something locally, making it used and then complaining because not upstreaming it would break your customers really is your own responsibility.
Sorry I understand I should try upstreaming it early, so I am still looking for a chance to avoid further divergence.
Quoted 15 lines
IMHO the solutions are:
- the current (mainline) default will remain the standard for geometries which are already widely supported
- if there are new geometries that must be supported and do not fit because of the "legacy" logic, then you may detect that and try to fallback to the "modern" way of calculating the ECC parameters (or even jump directly to the modern way if the geometry really is not currently supported officially)
- if your customers want a specific chunk size/strength when rebasing on top of a mainline kernel there are DT properties which do that anyway
- follow Sean advice: introduce a property requesting to use the 'modern' or 'legacy' logic (with a better name than modern) but first check with Rob that this if valid.
Another hint: please check the core helpers and use them instead of trying to re-invent the wheel: normally just describing the engine capabilities and calling a single helper should do the trick. But this 'new' calculation should only apply to eg. MLC devices or devices with specific geometries, not to all devices.
Thanks,
Miquèl
Quoted 2 lines · Miquel Raynal
Hi Han,
[ ... ]
Quoted 52 lines
I understand that (2) might be ideal to meet but is breaking all the boards that use this driver really worth the trouble?
Short answer: no. So we need to adapt the calculation for new boards/new flash chips/certain geometries at most.
Quoted 21 lines
Quoted 4 lines
Quoted 2 lines
The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed.
What does "safety guaranteed" means?
set minimum ecc required by nand chip at least meet all requirements
Quoted 14 lines
Quoted 5 lines
This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way.
How is this an argument? I am usually in favor of moving forward when there is a real justification, but this does not seem the case, unless I am understanding it all the wrong way.
Quoted 3 lines
The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
Quoted 23 lines
Quoted 4 lines
You are well aware of the upstreaming process, trying to merge something locally, making it used and then complaining because not upstreaming it would break your customers really is your own responsibility.
Sorry I understand I should try upstreaming it early, so I am still looking for a chance to avoid further divergence.
Quoted 15 lines
IMHO the solutions are:
- the current (mainline) default will remain the standard for geometries which are already widely supported
- if there are new geometries that must be supported and do not fit because of the "legacy" logic, then you may detect that and try to fallback to the "modern" way of calculating the ECC parameters (or even jump directly to the modern way if the geometry really is not currently supported officially)
- if your customers want a specific chunk size/strength when rebasing on top of a mainline kernel there are DT properties which do that anyway
- follow Sean advice: introduce a property requesting to use the 'modern' or 'legacy' logic (with a better name than modern) but first check with Rob that this if valid.
Quoted 8 lines
Another hint: please check the core helpers and use them instead of trying to re-invent the wheel: normally just describing the engine capabilities and calling a single helper should do the trick. But this 'new' calculation should only apply to eg. MLC devices or devices with specific geometries, not to all devices.
Thanks,
Miquèl
Hi Han,
Is this something you are working on?
If not I really think we need to revert the changes to u-boot, to allign vanilla u-boot and kernel.
/Sean
Han Xu
maintainerQuoted 64 lines · Sean Nyekjaer
Quoted 2 lines · Miquel Raynal
Hi Han,
[ ... ]
Quoted 58 lines
I understand that (2) might be ideal to meet but is breaking all the boards that use this driver really worth the trouble?
Short answer: no. So we need to adapt the calculation for new boards/new flash chips/certain geometries at most.
Quoted 21 lines
Quoted 4 lines
Quoted 2 lines
The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed.
What does "safety guaranteed" means?
set minimum ecc required by nand chip at least meet all requirements
Quoted 14 lines
Quoted 5 lines
This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way.
How is this an argument? I am usually in favor of moving forward when there is a real justification, but this does not seem the case, unless I am understanding it all the wrong way.
Quoted 3 lines
The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
Quoted 23 lines
Quoted 4 lines
You are well aware of the upstreaming process, trying to merge something locally, making it used and then complaining because not upstreaming it would break your customers really is your own responsibility.
Sorry I understand I should try upstreaming it early, so I am still looking for a chance to avoid further divergence.
Quoted 15 lines
IMHO the solutions are:
- the current (mainline) default will remain the standard for geometries which are already widely supported
- if there are new geometries that must be supported and do not fit because of the "legacy" logic, then you may detect that and try to fallback to the "modern" way of calculating the ECC parameters (or even jump directly to the modern way if the geometry really is not currently supported officially)
- if your customers want a specific chunk size/strength when rebasing on top of a mainline kernel there are DT properties which do that anyway
- follow Sean advice: introduce a property requesting to use the 'modern' or 'legacy' logic (with a better name than modern) but first check with Rob that this if valid.Another hint: please check the core helpers and use them instead of trying to re-invent the wheel: normally just describing the engine capabilities and calling a single helper should do the trick. But this 'new' calculation should only apply to eg. MLC devices or devices with specific geometries, not to all devices.
Quoted 8 lines
Quoted 2 lines
Thanks,
MiquèlHi Han,
Is this something you are working on?
If not I really think we need to revert the changes to u-boot, to allign vanilla u-boot and kernel.
I will send patches for both kernel and u-boot to use legacy bch scheme by default, and add some code to treat few MLC nand chips as corner cases.
Quoted 2 lines
/Sean
Quoted 3 lines · Han Xu
Quoted 2 lines · Sean Nyekjaer
Quoted 1 line · Miquel Raynal
Hi Han,
[ ... ]
Quoted 11 lines
Quoted 6 lines
Hi Han,
Is this something you are working on? If not I really think we need to revert the changes to u-boot, to allign vanilla u-boot and kernel.
I will send patches for both kernel and u-boot to use legacy bch scheme by default, and add some code to treat few MLC nand chips as corner cases.
Have I missed the series patches for this? :)
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Miquel Raynal
maintainerHi Han,
[email protected] wrote on Tue, 12 Oct 2021 11:15:27 +0200:
Quoted 14 lines · Han Xu
Quoted 3 lines · Sean Nyekjaer
Quoted 2 lines · Miquel Raynal
Quoted 1 line
Hi Han,
[ ... ]
Quoted 7 lines
Quoted 6 lines
Hi Han,
Is this something you are working on? If not I really think we need to revert the changes to u-boot, to allign vanilla u-boot and kernel.
Quoted 6 lines
Quoted 4 lines
I will send patches for both kernel and u-boot to use legacy bch scheme by default, and add some code to treat few MLC nand chips as corner cases.
Have I missed the series patches for this? :)
Yes, this needs to be fixed.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/