This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

4-bit ECC compatibility - Can the OMAP boot on any flash block from MT29C4G48MAZAPAKQ-5 which uses 4bit ECC on blocks other than 0?

Other Parts Discussed in Thread: OMAP3503, AM3715, OMAP3530

The OMAP3503 supports two different algorithms with different error correction capabilities: Hamming code (for 1-bit error code correction), and BCH code (for 4- or 8-bit error correction) through the GPMC_ECC_CONFIG[16] ECCALGORITHM bit.

 But as per the OMAP35xx errata (Silicon Revisions 3.1, 3.0, 2.1, and 2.0) there is bug in 4-bit mode. FYI…the Errata sheet (SPRZ278E) is latest which is revised on March-2010.

 In Micron (MT29C4G48MAZAPAKQ-5) datasheet the ECC requirement is 4-bit ECC except block 0.

Block 0 ECC requirement is 1-bit ECC.

 As per the Micron datasheet (MT29C2G48MAKLCJI-6) which is used in Beagle board. The ECC requirement is 1-bit ECC.

 And as per OMAP35xx Boot ROM initialization procedure, for NAND boot, four physical blocks are searched for image.

And also Boot ROM supports only 1-bit ECC. (Pls refer 25.4.7.2 and 25.4.7.4 section in OMAP35x Reference Manual (SPRUF98G))

 But in Micron (MT29C4G48MAZAPAKQ-5) minimum ECC requirement for Block 0 is 1-bit ECC but for other blocks requirement is 4-bit ECC.

So once the Block 0 corrupted there may be issue to boot with other block images since the 4-bit ECC is not supported in Boot ROM and as well bug in OMAP35xx.

So the usage of MT29C4G48MAZAPAKQ-5 with OMAP3503 may be issue. Could somebody shed some light on this please?

  • Please see:  http://processors.wiki.ti.com/index.php/GPMC_ECC for more detail of ECC on the OMAP35xx devices.

    In response to you question, Yes, your assumption is correct: once block 0 is corrupted, the OMAP3503/15/25/30 internal ROM bootcode cannot support alternative bootstraps at block 1 - 3 because these blocks are not 1 bit ECC on the Micron NAND you use.

    The 4-bit ECC polynomial has been corrected on the 37xx and on the 3505/17. You could consider moving your design forward to the 37xx device family (see migration guide at: http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide ) as it will allow you a power saving at the same speed, or a speed increase at the same power. In most cases the 37xx will be nearly 100% pin-compatible with the 35xx with addition of a few external capacitors - see migration guide above.

    Hope this helps

  • One other clarification. As per the AM37xx (AM3715/03) errata (Silicon Revisions 1.1) also there is bug in 4-bit ECC mode. The Errata sheet (SPRZ318) is latest which is revised on June-2010.

    Can you please confirm that whether AM37xx solves this issue?

  • Ranjith,

    in AM37x this bug exist on ES1.0 silicon, this is fixed in ES1.1 silicon revision. today ES1.1 silicon is already available to customers which actually have this bug fixed.

     

  • We work with OMAP3530 with Micron Flash that has on die 4-bit ECC engine (disabled on power-up). This flash part requires 1-bit ECC for block 0 and 4-bit ECC for the rest of the blocks.

    What happens in programming phase? Who calculates ECC bits and writes them to memory spare area?

    We expect that 1-bit ECC is generated for block 0 and 4-bit ECC for all other blocks.

    Is it calculated and written by EVM_FLASH utility or another TI flashing utility?

    The flashing utility could calculate and write 1-bit ECC for block 0, then disable its ECC and enable the on-die memory flash 4-bit ECC engine. Is that a supported mode?