SAMA5D27 NAND Compatibilities

Moderator: nferre

igortf95
Posts: 1
Joined: Mon May 07, 2018 2:52 pm

SAMA5D27 NAND Compatibilities

Mon May 07, 2018 3:44 pm

Hello,

I am using a SAMA5D27C-D5M processor in a custom board and test the follow nand flash memories: K9F2G08U0C-SIB0000 and MT29F2G08ABAEAWP-IT:E.

My issue regards the ECC Correctability Bits. According to datasheet, the first memory have 1 bit and the second have 4 bits. So, I did the follows NAND PMECC configurations on bootstrap and PMECC header in SAM-BA:

K9F2G08U0C-SIB0000:
*ECC Correctability Bits: Auto-detection; PMECC header: 0xc0902405 -> Doesn't work it (Failed to load image)
*ECC Correctability Bits: 2; PMECC header: 0xc0900405 -> Doesn't work it (Failed to load image)
*ECC Correctability Bits: 4; PMECC header: 0xc0902405 -> Work it (Done to load image)

MT29F2G08ABAEAWP-IT:E:
*ECC Correctability Bits: Auto-detection; PMECC header: 0xc0902405 -> Work it (Done to load image)

I need to use the first nand memory. And I don't understand what the ECC Correctability Bits do. So, I want to ask four things:

1) What the function of the ECC Correctability Bits in the header? Is a minimum value?
2) If the processor is responsible for run the ECC, why this variable needs to be compatible with the nand?
3) Is there a problem on using 4 bits instead of 1 to ECC Correctability Bits?
4) How can I force an error in the ECC to verify if it works?

Thank you in advance,
Igor
blue_z
Location: USA
Posts: 1721
Joined: Thu Apr 19, 2007 10:15 pm

NAND ECC specification and PMECC header

Tue May 08, 2018 12:43 am

igortf95 wrote:I am using a SAMA5D27C-D5M processor in a custom board
That's a SoC, not a processor. It has an ARM Cortex-A5 processor.

igortf95 wrote:According to datasheet, the first memory have 1 bit and the second have 4 bits.
You're mis-stating what is written in the NAND datasheets.
These "1 bit" and "4 bit" are not attributes that these NAND flash chips possess (as you have written), but rather are the recommended requirements for an ECC implementation when using these chips.
The "ECC Correctability Bits" (or ECC capability) refers to the maximum quantify of bit-errors that could occur during a read, and still be correctable.
But if there are more than that number of bit errors, then the read is deemed uncorrectable and a failure.

igortf95 wrote:*ECC Correctability Bits: Auto-detection; PMECC header: 0xc0902405 -> Doesn't work it (Failed to load image)
*ECC Correctability Bits: 2; PMECC header: 0xc0900405 -> Doesn't work it (Failed to load image)
*ECC Correctability Bits: 4; PMECC header: 0xc0902405 -> Work it (Done to load image)
These results are not useful, since the PMECC header values for the "failed" cases are not correct for their description.
Note that for three different cases, you have employed only two different header values!
What are you claiming is "Auto-detection"?
Clearly the second case has an incorrect eccOffset, since it hasn't changed compared to the other header values.
Refer to this page for calculating the proper eccOffset based on OOB size, number of bits of correctability, sector size, and number of sectors per page.

igortf95 wrote:1) What the function of the ECC Correctability Bits in the header?
Your question is poorly worded.

ECC provides the capability to detect and correct bit errors in a block of data (e.g. a "sector" or page).
N-bits of correctability means that up to N bits in the block can be in error (i.e. flipped), but the ECC process can detect this condition and correct the bit flips; such a block read is considered correctable.
If more than N bits are in error in the block, then this condition is also detected, but the errors cannot be corrected; such a block read is considered uncorrectable and therefore unreadable.

To accomplish error detection and correction, additional bytes (the ECC) must be generated and then stored on the media with the actual data block.
This Error Correction Code, ECC, is generated specifically for each block of data before it is written.
The length of this Error Correction Code is a function of (a) the length of the block of data, (b) the number of bits of correction capability, and (c) the code scheme employed (e.g. BCH, Hamming, or Fire).
For a read operation, both data and ECC must be retrieved from the media, and then the ECC is used to validate/correct the data.

The "header" that you refer to is a method employed by the SoC ROM program to configure its PMECC peripheral for read operations to match the ECC parameters used when that image was written.
The "ECC Correctability Bits" (or ECC capability) is just one of several PMECC parameters that need to be specified when configuring the PMECC peripheral.
Note that some of these PMECC parameters are interrelated. E.G. changing the number of eccBitReq affects the value of eccOffset.

igortf95 wrote:Is a minimum value?
The question is ambiguous, and the answer depends on the perspective.
A NAND chip will typically specify a bit number per "sector" for a minimum level of correctability that needs to be employed for reliable operation.
An ECC implementation (either HW or SW) will advertise a bit number of correction capablity. That number is a maximum.

igortf95 wrote:2) If the processor is responsible for run the ECC, why this variable needs to be compatible with the nand?
ECC can be performed in software (by the processor) or in hardware (e.g. a PMECC peripheral).
Since the SAMA5D27 has a PMECC for performing ECC by hardware, you should take advantage of that capability.

By "this variable" you are presumably referring to the value of the PMECC header parameter.
The value of this parameter can/will be used to configure the PMECC hardware of the SoC, so that the NAND can be read reliably.
Providing this value allows the use of non-ONFI NAND, and (according to the datasheet) could be more reliable or flexible than using the internal ONFI parameters.
This PMECC header value needs to exactly match the ECC configuration used when the boot image was written, rather than just the minimal ECC requirements of the NAND chip.

igortf95 wrote:3) Is there a problem on using 4 bits instead of 1 to ECC Correctability Bits?
No, you can safely use more bit-correction capability (as long as there is space in the out-of-band region for the larger ECC).

igortf95 wrote:4) How can I force an error in the ECC to verify if it works?
You wouldn't necessarily put an "error in the ECC". Presumably you want to test that ECC can detect and correct errors?
U-Boot has the capability to read and write an entire (raw) page with the out-of-band region (aka OOB). Presumably this capability can be used to override the generation of the proper ECC when a raw page is written with fake error bits and original ECC in the OOB.

Regards

Return to “SAMA5-based”

Who is online

Users browsing this forum: No registered users and 2 guests