OMAP3530 4-bit and 8-bit ECC (errata advisory 3.1.1.181)

Jeff,

The 8-bit hardware ECC works correctly.  Note that the hardware does only the actual detection so you would need additional software support to actually implement the correction.  I'm going to move this thread over to the Linux forum for comment from our Linux driver teams to see what's available in terms of 8-bit ECC support.

Best regards,
Brad

Hi Brad,

I am working on the same project with Jeff and I guess we have some more questions here.

Looking at the TRM for the OMAP3530, it suggests that the GPMC has two ECC engines.  A Hamming code engine

and a BCH code engine.  The Hamming code engine is used for 1-bit ECC and the BCH for all others.  You then

configure the BCH for the bit depth that you wish to operate over.   So, the question arises how the engine is broken

for 4-bit but works correctly for 8-bit, when most likely it is the same engine in either case?

You state that the hardware does only detection but in section 11.1.4.4, there is this statement,

"The GPMC does not directly handle the error code correction itself. During writes, the GPMC computes
parity bits. During reads, the GPMC provides enough information for the processor to correct errors
without reading the data buffer all over again."

which suggests that the hardware does generation and detection and it is up to the software to do the

correction.  So, we have some hardware support on read _and_ write and correction is a software function.

As we move into much higher density NAND flash, at 35 and 25nm, stronger ECC is becoming a requirement.  Parts that

will be available later this year are calling for 8-bit ECC and so we are looking for help in deploying a Linux solution on 3530

that can do that.  Does TI have code that will interoperate with the hardware support on the 3530 for an 8-bit ECC implementation?

Chris Elmquist

Chris,

I've talked with many people inside TI trying to get answers.  Here are some of the data points I have picked up:

• In the near term your best option would be to choose another memory vendor that is not so aggressive in moving to 4-bit and greater ECC.  Hynix and Toshiba are a couple options.
• Another option to avoid the issue is to use eMMC which is a managed NAND technology that looks like an SD card (i.e. interfaces to SD/MMC interface) but would be soldered down on the board.
• We are working to put Linux/u-boot patches together for 4-/8-bit ECC.  We should have an updated timeline available at the end of next week.
• The errata affecting 4-bit ECC has been confirmed fix in the AM35x and AM37x devices.

Best regards,
Brad

Brad,

Thanks for the info.

Another memory vendor is an option we're exploring.  We've also looked at eMMC, but the our client's requirements for power and resistance to data corruption on abrupt loss of power have made that an unlikely choice.  It seems that there is a non-zero chance that if power is removed from a eMMC during a transaction, that data other that that which is currently being written can be corrupted.  We're trying to get clarification on that from the Micron.

We're unable to switch to a different processor because the client wants to use a Logic Torpedo SOM.

Linux and U-Boot patches may be the only route forward for us.

What kernel version are the patches being developed for?

thanks,

Jeff

Brad,

Any word on that updated timeline?

thanks,

Jeff

Jeff,

we would be working on releasing patch for PSP v3.01.00.06.

Current Target date for this release is Aug 13th.

Vaibhav,

Thanks for the update!

Do you know what kernel version will be released in PSP v3.01.00.06?

thanks,

Jeff

Hi...

Can you elaborate on what this patch will offer?

4-bit ECC?

8-bit ECC?

How much of each (generation, detection, correction)  is done in SW vs HW?

Our customer(s) are pretty insistent on moving to flash geometries around 25nm and therefore are already

requiring 8-bit ECC to make that reliable.

Chris Elmquist

LogicPD

jeffc said:

Do you know what kernel version will be released in PSP v3.01.00.06?

The currently released PSP version is 3.00.01.06.  I believe the plan is for someone on Vaibhav's team to create a patch that would be applied to 3.00.01.06 to provide this capability.  In other words I think Vaibhav transposed a couple digits and so you thought an entirely new PSP release was coming, but they are just working on a patch to the current version.  I imagine it would make its way into a future version at some point though.

How are things looking on this patch?  Can you give an update?

We are anxious to get 8-bit ECC support so hope things are on schedule.

Can you also comment on what capabilities the patch will provide...  ie, 4-bit and 8-bit ECC, just 8-bit?  We'd like to try to gauge

the effort in integrating it with our existing BSP.

Thank you.

Chris

LogicPD

A patch is now available which provides 4-bit and 8-bit software ECC correction.  Please obtain the patch from your local FAE.

Hi,

could someone point me to arago tree commit IDs for those 4-bit/8-bit ECC correction patches? I would be looking for both u-boot and kernel.

Thanks,

--Gunter

Hi,

Did someone outside of TI tried this patch and can provide feedback?

Can someon within TI give a quick explanation about the nature of the fix made?

Regards,

David

Updated patches are now available on Arago.

These patches apply on our PSP 03.00.01.06 release. You can access these under

Kernel : http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/OMAPPSP_03.00.01.06

X-loader: http://arago-project.org/git/projects/?p=x-load-omap3.git;a=shortlog;h=refs/heads/OMAPPSP_03.00.01.06

U-boot : http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=shortlog;h=refs/heads/OMAPPSP_03.00.01.06

Future PSP releases are planned to include this work.

As a note, these patches implement the 4b/8b BCH based correction and detection, but do not include support for enabling Micron on-die ECC processing.  That feature will be forthcoming.

Hi Brad,

We are having a plan to use emmc in future may be next week;

I want to ask, after soldering onto the board, wheather we need to make any changes in x-loader, uboot and uImage or

automatically it will mount please help me?

I will work if any changes needed ?

Regards,

santosh vastrad

Are you putting your eMMC on MMC2?  That's the intended use.  You may need to make a small tweak to the bootloader to tell it to grab the next image from MMC2 rather than MMC1.  I don't remember if anyone ever integrated a patch to have it grab the next bootloader from the same port as the boot ROM grabbed it from, i.e. I'm not sure if xloader is "smart" enough to just look at the boot table to see that it booted from MMC1 vs MMC2.