• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 863 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Is AM3352 NAND BCH-8 ELM PAGE MODE (wrap mode 4) compatible with ROM Code's spare area layout, specially 14th ECC Byte?

Anja Zoelgert
Prodigy 60 points
Other Parts Discussed in Thread: AM3352

Dear Experts,

I am using a custom board with AM3352 CPU, similar to the AM3358-EVM,  with a NAND boot flash and Windows Embedded BSP from ADENEO.

With ADENEO WinEC7 BSP,  they made an attempt of copying the Liux Sources created by Avinash Philip, but unfurtunately, never finished the ECC ELM hardware correction properly.  They took the NAND driver out of the BSP instead.
So right now, we are running bare NAND without ECC correction, just detection.

It is my job to make ELM hardware usable to us in a most efficient way, so we are aiming at ELM in PAGE MODE, where CPMC and ELM can detect & correct the error loactions quickly on a whole NAND page without bothering the CPU.

Avinash explains in a comment:
>>
ECC layout uses 1 extra bytes for 512 byte of data to handle erased pages. Extra byte programmed to zero for programmed pages. Also BCH8
requires 14 byte ecc to maintain compatibility with RBL ECC layout. This results a common ecc layout across RBL, U-boot & Linux with BCH8.
<<

I am aiming at that target, too: Use the same BCH-8 ECC Layout accross RBL, XLDR, EBOOT and WinEC7.

But i found that Avinash & TI colleagues never used ELM in PAGE MODE, neither in NAND-Writer nor in U-Boot nor in Linux sources.

I tried but found that no WRAP MODE known in the AM3352 TRM datasheet 7.1.3.3.12.3.3 Supported NAND Page Mappings and ECC Schemes is suitable for a 14th ECC-Byte like RBL needs. BCH-8 with 13 ECC Bytes would work in WRAP MODE 4, but I cannot get the BCH encoded message with the 14th byte so that ELM works.

Can ELM in PAGE MODE work with RBL spare area scheme and the 14th ECC byte? Which WRAP MODE shall I use? Is there a trick on switching the ECC_ENABLE bit for the GPMC ECC engine on and off while reading the spare area so that only valid bytes are taken into the engine for ELM?


Thanks,

Anja

  • 0
    TI__Guru**** 393215 points

    Moving this to the Linux forum.

  • 0 in reply to Biser Gatchev-XID
    Prodigy 60 points
    Dear Biser,
    this is not a Linux question (I am using Windows EC7), but a question regarding the GMPC-ECC-BCH and ELM interaction.
    If it was in my power, I would contact the ASIC designer of the ELM and ECC engines, or the person who wrote the AM3352 TRM datasheet Section 7.1.3.3.12.3.3.
    -- Did the ECC-BCH and ELM PAGE MODE designer take into account the needs of the ROM Boot Loader (so we can use ONE spare area scheme throughout the whole NAND) ? --
    Regards,
    Anja
  • 0
    Prodigy 60 points

    The answer is "Yes."

    GPMC's BCH-8 ECC engine IS ABLE  to just "throw away" the 14th ECC Byte in Wrap Mode 4 = pooled spares.
    size0=2Bytes Bad block are skipped, and per 512 Byte data size1=14Bytes ECC are read.
    The GPMC knows that for BCH-8 it needs 13 Bytes per 512 Bytes Data and ignores the 14th padding Byte(s).
    It is not necessary to disable the ECC engine for "uninteresting" bytes, not even for NAND commands, for the GPMC can tell the difference.
    This is very encouraging.
    When I perform a 4096 Byte Page read, the BCH-Result-Regs are filled with numbers which look exctly like the ECC stored in the Spare Area (except the 14th Byte), but ordered in Little Endian format (NAND Spare Area is Big Endian format).
    Then I read in the Spare Area from the NAND, and - if no bit flip - the syndromes in the BCH-Result-Regs turn all to 0x00000000 which means NO ERROR.
    Reading a 4096+128 Byte page this way in wrap mode 4 is really efficient for you need not reposition the NAND's data pointer, just shovel all in using FIFO.

    Next step will be injecting bit errors into page data, see what happens to the Syndromes, and how ELM reacts.