i.MX ECC Bits Organization within NAND

[davidbeaty]

As I understand the i.MX536’s use of NAND it doesn’t matter if the NAND has large or small pages the i.MX family always uses 512B + 16B size pages and you need move the bad block marker to fourth section free space… But I need one more level of description… I need to know exactly how the ECC lays into the free spare area. How are the ECC bits organized within the 16B free space…?

[davidbeaty]

Tom,

> How are the ECC bits organized within the 16B free space…?

Yes, that's correct...

> Why do you need to know this? What does decoding the syndrome get you?

We're trying to describe how to program our NAND Flash parts...  I've been through this with a TI Sitara micro and Flash...  The NAND Flash programmers want a description of the spare area...  See my Sitara example below...

I've also copied Mark William's attempt at the NXP NAND Flash page layout below for reference...  His layout doesn't account for all the bits in the page (2112) but it details the structure...  I'm looking for the bit layout in the ECC and meta data sections...

  Here's the TI Sitara Nand Flash spare area layout...

1. 1. If the spare area information is to be calculated by the programmer, please provide the structure of the spare area below:

The 2048 bytes of data is split into four 512 byte subsections: A, B, C, D.  For each subsection, a BCH8 ECC is calculated.  The 13-byte ECC of each subsection is then stored as follows:

2048	2049	2050	2051	2052	2053	2054	2055
		ECC-A[0]	ECC-A[1]	ECC-A[2]	ECC-A[3]	ECC-A[4]	ECC-A[5]

2056	2057	2058	2059	2060	2061	2062	2063
ECC-A[6]	ECC-A[7]	ECC-A[8]	ECC-A[9]	ECC-A[10]	ECC-A[11]	ECC-A[12]	0

2064	2065	2066	2067	2068	2069	2070	2071
ECC-B[0]	ECC-B[1]	ECC-B[2]	ECC-B[3]	ECC-B[4]	ECC-B[5]	ECC-B[6]	ECC-B[7]

2072	2073	2074	2075	2076	2077	2078	2079
ECC-B[8]	ECC-B[9]	ECC-B[10]	ECC-B[11]	ECC-B[12]	0	ECC-C[0]	ECC-C[1]

2080	2081	2082	2083	2084	2085	2086	2087
ECC-C[2]	ECC-C[3]	ECC-C[4]	ECC-C[5]	ECC-C[6]	ECC-C[7]	ECC-C[8]	ECC-C[9]

2088	2089	2090	2091	2092	2093	2094	2095
ECC-C[10]	ECC-C[11]	ECC-C[12]	0	ECC-D[0]	ECC-D[1]	ECC-D[2]	ECC-D[3]

2096	2097	2098	2099	2100	2101	2102	2103
ECC-D[4]	ECC-D[5]	ECC-D[6]	ECC-D[7]	ECC-D[8]	ECC-D[9]	ECC-D[10]	ECC-D[11]

2104	2105	2106	2107	2108	2109	2110	2111
ECC-D[12]	0

This is Mark William's interpretation of the NXP NAND Flash page layout but it doesn't account for all the bits in the page (2112B)...  I need to know how each of the ECC sections and the meta data section bits are placed in the sections...

[TomE]

> The NAND Flash programmers want a description of the spare area

So your requirement is to get the flash parts separately programmed by some other hardware before being installed on your board. That's tricky, and looks to be "unsupported" without following Igor's latest advice concerning NDAs and so on.

> This is Mark William's interpretation of the NXP NAND Flash page layout

Looks nothing like it to me. In his first response to your first post, igorpadykov provided the "AN_MX_NAND_BAD_BLOCK.pdf" document.

It includes the "FSL IMX NFC" layout, detailed as follows:

There is no "metadata" There are four 8-byte ECCs, one for each block, stored in the second 8 bytes of each 16 byte section. The Reference Manual only states that they are 8 bytes, and gives the "generator polynomial". This may be a "standard BCH4" if there is such a thing. The following document says that the 8-byte BCH ECC is called "BCH4" as it can only correct 4 bits.

http://processors.wiki.ti.com/index.php/Raw_NAND_ECC

It also names the different methods of storing alternating data and ECC blocks as being "compatible mode" and storing the ECCs all in the spare area (your Sitara example) as "non-compatible mode".

If your NAND drivers are performing Freescale's "BBI Swap Solution" then you're going to have to get the Flash Programmer to do that swap on your data as well.

I think you might also have to have the Programmer scan the Flash, find the Factory Bad Blocks and construct the Freescale Bad Block Table as well. This would be difficult to test as you'll need some Flash chips with Factory Bad Blocks (to test that it works properly) or you'll have to set up a programmer to create "fake factory bad blocks".

Good luck with this.

Tom

[igorpadykov]

Hi David

please elevate that using local fae/marketing channel.

Note as this may confidential info, nda with nxp may be required

and information about project opportunity.

Best regards

igor

[davidbeaty]

Karina, I still don't have the information I need...  Tom's comments were very interesting and informative but my question still goes unanswered...  I still need to know how the ECC is laid out in the NAND page...  There's another post in the i.MX Community that's looking for the same information, https://community.nxp.com/thread/343771...  He's attempted to interpret the layout but I don't think it's correct...  But that's the best attempt I've seen...  We need help from NXP...

Dave

[TomE]

It helps (me) to re-read your original question:

> I need to know exactly how the ECC lays into the free spare area.

> How are the ECC bits organized within the 16B free space…?

Why do you need to know this? What does decoding the syndrome get you?

> There's another post in the i.MX Community that's looking for the same information,

I've read through all of that. He was having a bad file system corruption problem, and found that the DRIVER code wasn't reading the correct "bad block marker" byte for his particular NFC chip (apparently NOT supported by the driver, but nothing told him that), and chased that problem down the rabbit hole for what looks to have been three months. That particular incompatibility in the driver (with the chip they were using) had nothing to do with his real problem, which was a DMA bug in Windows which they found eventually.

Attempting (and probably failing) to answer your question by reading the i.MX53rm.pdf (version 2.1) manual:

Table 51-6. Spare Area Buffer for NAND devices of 512B+16B, 2K+64, 4K +128B

That shows the first 8 bytes are the "user bytes" and the second 8 are the ECC. But you want to know which BITS are which?

51.8.15 ECC status result (NFC_ECC_STATUS_RESULT)

For further information of the ECC algorithm refer to 51.12.4/51-77

51.12.4 gives the physical connections to the chip, and "51-77" doesn't exist (51.36 is the last one) so that looks like a cut-and-paste error from a different manual. I'm not sure about the grammar either [1], but "information of" should be an unusual enough error that it should make something Google can find in other documents. No, Google doesn't have that phrase indexed. The NXP Search won't find it either. That's two good tools I've used to track these things down in the past that aren't working any more. This other reference seems to be what the first one was meant to be:

for further information of the ECC algorithm refer to ECC Normal Operation .

That is this section:

51.11.4.1 ECC Normal Operation

These 8/14/24/26 bytes of ECC code are calculated based on the generator

polynomial g(x) = x^13 + x^4 + x^3 + x + 1.

The above definition and the following might be enough to get you started if you want to back to basic ECC theory:

https://en.wikipedia.org/wiki/BCH_code

It is likely that the NFC module in the i.MX53 was bought in from outside. So it is likely that nobody at Freescale/NXP ever needed to know how this works, because it worked fine. Being bought in, the IP is probably NDA to the original owner. The development people also moved to i.MX6 work years ago. The i.MX6 chips have a DIFFERENT NFC controller that it seems you have to "build yourself" out of the DMA controller and the (apparently lot more complicated) 40-bit BCH controller. I'd suggest reading the following chapter in the i.MX6DQ manual to see how complicated it now is:

Chapter 17 40BIT Correcting ECC Accelerator (BCH)

Note 1: Google counts:

"for information about the": 61.3 million

"for information on the" 430 million

"for information of the" 971 thousand

Tom

[karina_valencia]

HI David,

Igor  will continue with the follow up.

[karina_valencia]

igorpadykov​ can you help to continue with the follow up?

[TomE]

This is the best example I found for working this out.

Start from the big diagram in the section "The Spare Cell Array description" of the following, which documents "Samsung's Standard":

https://www.elnec.com/sw/an_elnec_nand_flash.pdf

Then, as my notes say:

"But the i.MX53 doesn't use it that way. It designates the FIRST EIGHT bytes of each 16 byte OOB page as 'Reserved for user' and the last EIGHT bytes for ECC."

As well, when you write a page, the NFC calculates the ECC for all of your data plus the first 8 bytes of the OOB and then writes its calculated ECC in place of whatever data you had in the buffer in the last 8 locations. When the data is read, it calculates the ECC over the data and compares with the last 8 bytes read.

I think there's a hardware setting to have it not do that, so you can then do all the ECC in software according to whatever standard you want to follow. Maybe.

At least this NFC is better than the one in the i.MX28 where the ECC of an erased block isn't all-ones!

Tom

[davidbeaty]

Thanks Igor but the document doesn't answer my question...  The document discusses the bad block marker location issues with the i.MX processor...  I need to know how the ECC bits are stored in the spare area on a NAND Flash part...

Dave

[igorpadykov]

Hi Dave

one can also check sect.51.7.1 Internal RAM Address Space and Organization

i.MX53 Reference Manual

http://www.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf

Best regards

igor

[igorpadykov]

Hi David

please look at attached document describing nand bad block

handling from i.MX53 L2.6.35_11.09.01 bsp package.

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------