View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005118 | fsimx_Linux | NAND-FMD | public | 2021-11-09 11:29 | 2021-11-30 13:15 |
| Reporter | gerbach | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | fsimx6-B2019.08 | ||||
| Target Version | fsimx6ul-B2022.04 | Fixed in Version | fsimx6ul-B2022.04 | ||
| Summary | 0005118: The gpmi-nand-fus driver computes the eec byte sitze wrong | ||||
| Description | The gpmi-nand-fus driver computes the eex byte size as ecc_bytes = ecc_strength * chip->ecc.steps * priv->gf_len / 8; But the recent kernel update shows that linux expects the byte sice per step as the follwoing new error capture in drivers/mtd/nand/nand_base.c shows : ecc->total = ecc->steps * ecc->bytes; if (ecc->total > mtd->oobsize) { WARN(1, "Total number of ECC bytes exceeded oobsize\n"); ret = -EINVAL; goto err_nand_manuf_cleanup; } | ||||
| Steps To Reproduce | This only occured because a customer had an old board with 224 OOB size and used the new fsimx6-B2021.10.1 release https://forum.fs-net.de/index.php?thread/4661-kernel-panic-on-buildroot-b2021-10-1/&postID=15961#post15961 | ||||
| Forum Link | |||||
|
|
Git commit: 52acc27c21a25472b08cb90eaf5e50035d95eb96 In gpmi-nand-fus.c, set and use ecc.total/ecc.bytes correctly Our code simply used ecc.bytes as the total number of ECC bytes for the whole page. However ecc.bytes is now only meant for one ECC step, and there is a different value ecc.total that holds the total number of ECC bytes. Change the code to use ecc.total whereever ecc.bytes was used. However there is a problem. The BCH hardware on i.MX CPUs may use ECC sums per step that are not a multiple of bytes. For example when using ecc_strength = 62 and two steps with 1024 bytes each (gf=14), the total number of ECC bits for one step is 62*14 = 868 bits, which is 108.5 bytes. So it is impossible to give a correct value for ecc.bytes, just for ecc.total. But ecc.total is computed in nand_base.c::nand_scan_tail() as ecc->steps * ecc->bytes. So this value would always be wrong. Change the code in nand_scan_tail() to only compute ecc->total anew if it is still zero at this time. If it is non-zero, it is assumed that the value was already computed in the attach() function of the specific driver. |
