View Issue Details

IDProjectCategoryView StatusLast Update
0005134UBootU-Bootpublic2021-11-30 13:20
Reportergerbach Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Versionfsimx6-B2019.08 
Target Versionfsimx6ul-B2022.04Fixed in Versionfsimx6ul-B2022.04 
Summary0005134: 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;
}

Because the Uboot driver is analogouse to the linix driver, we have to apply the same fix here-
Forum Link

Activities

gerbach

2021-11-30 13:20

developer   ~0003790

Git commit: 2046bdebbb13adcb9b20a64f10ec43e15324534d

In mxs-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 set ecc.bytes and ecc.total correctly.

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.