AM3354: GPMC ECC BCH configuration

siangming foo

Part Number: AM3354

I was going through the AM3354 Technical Reference Manual, GPMC ECC section when i came across the GPMC_ECC_CONFIG register, Field ECCWRAPMODE, Bit 11-8.

Description reads 'Spare area organization definition for the BCH algorithm. See the BCH syndrome/parity calculator module functional specification for more details'.

I was not able to find more info on this register field.

Any one can point to a documentation?

I briefly read up on the BCH algo and have the following questions on TI implementation of BCH ECC engine on this CPU...

Also, If i configure the CPU ECC to BCH 8bit....

1. What information exactly is stored on the GPMC_BCH_RESULTx_y after I do a read of the NAND sector (only 'normal data' and not the SPARE AREA)? Is it the parity from the BCH encoding? or the syndrome which i can feed directly to the CPU ELM module to locate the error location?

2. Do i have to also to read the SPARE AREA before I retrieve from GPMC_BCH_RESULTx_y?

thanks

over 4 years ago

0 Mark M over 4 years ago

TI__Mastermind 30260 points

Hi,

This is out of my area of expertise, but I believe the contents of GPMC_BCH_RESULTx_y depend on whether or not the parity from the OOB is concatenated with the data block and processed by the ECC engine.
* Without concatenating the parity with the data block, the ECC engine processes the data block only and computes the ECC into GPMC_BCH_RESULTx_y (ECC = the remainder of dividing data block by generator polynomial). If no errors, this result should match the ECC that was stored in the OOB. The ECC engine sees the same data stream that it sees when computing the ECC parity to be written during a write. bch_decode() can input recv_ecc and calc_ecc and either return 0 if no errors, or compute the syndrome from the data and calc_ecc, and then locate the errors. The ELM consumes the syndrome, not the ECC.
* With parity from OOB concatenated to the data and fed to the ECC engine, the GPMC_BCH_RESULTx_y will contain the syndrome polynomial. If no errors, the division of the codeword (data block concatenated with ECC) will be evenly divisible by the generator polynomial and have a remainder of zero. So if the syndrome in GPMC_BCH_RESULTx_y is zero, then there are no errors in the data block, and no need to feed the syndrome to the ELM.

This is why omap_enable_hwecc (in omap_gpmc.c) sets eccsize0 and eccsize1 differently for write vs read.

case OMAP_ECC_BCH16_CODE_HW:
   ecc_algo = 0x1;
   bch_type = 0x2;
   if (mode == NAND_ECC_WRITE) {
       bch_wrapmode = 0x01;
       eccsize0 = 0; /* extra bits in nibbles per sector */
       eccsize1 = 52; /* OOB bits in nibbles per sector */
   } else {
       bch_wrapmode = 0x01;
       eccsize0 = 52; /* ECC bits in nibbles per sector */
       eccsize1 = 0; /* non-ECC bits in nibbles per sector */
   }

Check out the following TRM sections that explain the different meanings of eccsize0/1...

GPMC
7.1.2.3.12.3 ECC Calculator
7.1.2.3.12.3.2.2 Memory-Mapping of the BCH Codeword
7.1.2.3.12.3.2.5 Wrapping Modes
7.1.2.3.12.3.3 Supported NAND Page Mappings and ECC Schemes
Figure 7-38. NAND Page Mapping and ECC: Per-Sector Schemes

ELM
7.4.2 Integration
7.4.4.1 ELM Low Level Programming Model
7.4.4.2 Use Case: ELM Used in Continuous Mode

See also uBoot source code (omap_gpmc.c, omap_elm.c, am335x_spl_bch.c) in
am335x-evm-linux-sdk-src-07.03.00.005\board-support\u-boot-2020.01+gitAUTOINC+2781231a33-g2781231a33\drivers\mtd\nand\raw\
Download from www.ti.com/.../PROCESSOR-SDK-AM335X

I will also loop in someone from software team to check my understanding.

Hope this helps,
Mark

Processors

Processors forum

AM3354: GPMC ECC BCH configuration