Problems in TI omap2-nand driver OMAP_ECC_BCH8_CODE_HW_DETECTION_SW mode

Ted Juan ted.juan at gmail.com
Thu May 15 23:04:01 PDT 2014


Dear Pekon,

Thanks great help.

>>So, decode_bch() should handle both the checks implicitly:
>>- checking for bit-flip errors by matching read_ecc[] and calc_ecc[]
>>- filtering out "empty-pages" by comparing read_ecc[] with 0xff.

In lib/bch.c, I don't quiet understand how to " filtering out empty-pages".
It just check bit-flip error as below code.

                        for (i = 0, sum = 0; i < (int)ecc_words; i++) {
                                bch->ecc_buf[i] ^= bch->ecc_buf2[i];
                                sum |= bch->ecc_buf[i];
                        }


Another problem for am3505/am3517 product, we  use the new generation
nand flash that cause more bit-flip.
In the older omap nand flash driver, it seems it is no ability to
correct OOB bit-flip.
Does the latest driver support to correct OOB and Data bit-flip at the
same time?



2014-05-13 14:23 GMT+08:00 Gupta, Pekon <pekon at ti.com>:
> Hi Ted,
>
> From: Ted Juan
>>
>>Hi All,
>>
>>Sorry, there is no problem. I got it.
>>
>>The latest bch.c decode_bch() has XOR read_ecc and calc_ecc in it.
>>
>
> And IIRC, this also takes care of filtering out "empty-pages" (OOB=all(0xff)).
> because while calculating ECC_BCH8_CODE_HW_DETECTION_SW
> resultant GPMC ECC syndrome is XORed with a static bch8_polynomial[]
> in omap_calculate_ecc_bch().
>
> So, decode_bch() should handle both the checks implicitly:
> - checking for bit-flip errors by matching read_ecc[] and calc_ecc[]
> - filtering out "empty-pages" by comparing read_ecc[] with 0xff.
>
> Otherwise you would have started seeing lot of un-correctable errors
> while mounting UBIFS.
>
>
> with regards, pekon
>
>>
>>
>>2014-05-12 16:08 GMT+08:00 Ted Juan <ted.juan at gmail.com>:
>>> Hi All,
>>>
>>> TI am3517/3505 can use the  OMAP_ECC_BCH8_CODE_HW_DETECTION_SW mode in
>>> the latest linux-mtd git tree.
>>>
>>> I post the latest driver and older driver as below.
>>>
>>> Wouldn't the latest driver get bad performance since it always do the
>>> decode_bch() ?
>>>
>>> Thanks,
>>> regards,
>>>
>>> Ted
>>>
>>>
>>> ==========the latest omap2.c driver==========
>>>
>>> int nand_bch_correct_data(struct mtd_info *mtd, unsigned char *buf,
>>>                           unsigned char *read_ecc, unsigned char *calc_ecc)
>>> {
>>>         const struct nand_chip *chip = mtd->priv;
>>>         struct nand_bch_control *nbc = chip->ecc.priv;
>>>         unsigned int *errloc = nbc->errloc;
>>>         int i, count;
>>>
>>>         count = decode_bch(nbc->bch, NULL, chip->ecc.size, read_ecc, calc_ecc,
>>>                            NULL, errloc);
>>>         if (count > 0) {
>>>
>>>        ......................
>>> }
>>>
>>>
>>> ==========older omap2.c driver==========
>>>
>>> static int omap_correct_data_bch(int correct_bits, struct mtd_info *mtd,
>>>                                  uint8_t *dat, uint8_t *read_ecc,
>>>                                  uint8_t *calc_ecc)
>>> {
>>>
>>>   ..................
>>>
>>>   for (i = 0; i < blockCnt; i++) {
>>>     /* check if any ecc error */
>>>     eccflag = 0;
>>>     for (j = 0; (j < eccsize) && (eccflag == 0); j++)
>>>       if (calc_ecc[j] != 0)
>>>        eccflag = 1;
>>>
>>>     if (eccflag == 1) {
>>>       eccflag = 0;
>>>       for (j = 0; (j < eccsize) && (eccflag == 0); j++)
>>>        if (read_ecc[j] != 0xFF)
>>>          eccflag = 1;
>>>     }
>>>
>>>     if (eccflag == 1) {
>>>       /*printk(KERN_INFO "...bch correct(%d 512 byte)\n", i+1);*/
>>>       count = decode_bch(mode, calc_ecc, err_loc);
>>>
>>>   ...............
>>>
>>>
>>> }
>>
>



More information about the linux-mtd mailing list