On 21/05/23 07:44PM, Sean Nyekjaer wrote: > On 22/05/2021 22.51, Han Xu wrote: > > 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) > > > > > - 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. > > > > > 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. > > > > Signed-off-by: Han Xu <han.xu@xxxxxxx> > > 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?
