OMAP3530: PoP with 4bits ECC nand flash

Hi grp,

While using OMAP3530 the best solution is to use Micron's on-die ECC as you stated.  Really the only other option would be to switch to Hynix which is currently still using 1b ECC, but they will also migrate to 4b ECC soon and they are sometimes difficult to get parts from unless you are a very large volume customer.  Here is another link that discusses the different memory options available:

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

Regarding your point about cycling power on the NAND, this is because Micron's on-die ECC can only be turned off by either sending a command to turn it off, or when power cycles.   When a reset occurs, the ROM code executes and has it's own ECC that runs and conflicts with the Micron on-die ECC.  The easiest way to get around this is to cycle power on the NAND when a reset is issued. 

Another solution would be to change the NAND to a discrete package that is not on the PoP device.  You would still have your LPDDR on PoP, but you can get a 1b ECC NAND that is a discrete option this would also solve the issue. 

Yet another solution would be to use eMMC for booting.  With this you would not have to worry about ECC at all. 

Moving to DM3730 would allow you to use our software ECC as you stated and then you wouldn't have to worry about the Micron on-die ECC. 

Jeff,

Thanks very much for your prompt reply.

Do you have an application note for Linux OS regarding the cycling of the nand power supply  on reset ? Is it easy to implement ?

On the other hand, there's no error management in u-boot & linux code (according to my knowledge) for the case where the on-die ECC returns an error (error means: errors larger than four bits have occurred)

Unfortunately i can't add an eMMC or an external NAND on my board.

If i could add an eMMC, do you provide a flash utility for eMMC ?

Regarding the software solution with the DM3730, do you provide a specific u-boot & linux code or is it already available in the mainline ?

regards

grp

Hi grp,

If you are using a PMIC you can use the reset signal to cycle the power to the NAND. 

x-loader, u-boot, and the kernel all have error handling code in there, unless you disable it to use the Micron on-die ECC.  If you have disabled the OMAP35x Software ECC and the NAND sees more than 4 bit errors then the NAND on-die ECC will generate an uncorrectable read error and it will not attempt to correct the data.  

The software ECC solution is now in the mainline for the AM/DM37x devices when you download the latest version of the SDK.

Hi Jeff,

can you provide another word of clarification?

in omap2.c in drivers/mtd/nand

there is a constant : #define CONFIG_MTD_NAND_OMAP_HWECC

do you suggest that in DM3730 this should be commented out?

what goes this flag represents? the hw detection?

since DM3730 has only hw detection and sw correction, can you explain your statement of :"The software ECC solution is now in the mainline for the AM/DM37x devices when you download the latest version of the SDK."

what is the HW solution?

Thanks,

Oren.

Hi Oren,

You do not need to modify that.  Are you wanting to use the Micron On-die ECC?  If you want to use Micron's ECC then here is an app note from Micron:

http://www.micron.com//products/ProductDetails.html?product=products/nand_flash/enterprise_nand//MT29E64G08AKCBBH2-12

You are correct, the AM/DM37x devices only have hw detection and sw correction.  My comment was if you want to use our sw ECC vs Micron's built in on-die ECC.  If you use the on-die ECC then you need to disable our sw correction.  which is discussed in the app note linked above.

Thank you Jeff,

that was indeed out understanding.

we have being burning jffs2 file system using teh following commands:

nandecc bch4_sw
nand erase 780000
nand write.i 0x81600000 780000 7220000

At first FS load there is no ecc errors, but after file system mounts, in second system loads we are getting ecc error with "...bch_correct" logs.

we are using 4 bit ecc micron nand, with on-die ECC disable.

omap2.c in mtd/nand was left untouched. so HW ecc detecion & sw corrction should be working.

Can you maybe spot the problem ?

Thanks,

Oren.

I think I am having the same or similar problems on OMAP3530 with 2 Micron NANDs (CS0 and CS3). I have both NANDs working as 1 bit SW but need to implement 4-bit support. I updated xloader, uboot, and Linux based on am37x-sdk-src-04.01.00.00 to add 4-bit support, based on the advise above. I'm flashing in u-boot with nandecc bch4_sw but then Linux is running with HW ecc detection/correction (CONFIG_MTD_NAND_OMAP_HWECC && CONFIG_MTD_NAND_OMAP_BCH_4). Are the ECC detection/correction errors due to OMAP3530 errata advisory 3.1.1.181?

--stevem

Hello oren,

I have exactly the same behaviour with the sameconfiguration (4 bit ecc micron nand, with on-die ECC disable).

My board is populated with the DM3730 ES 1.2

I'm actually investigating the problem.

Did you find a solution to the issue ?

BR,

grp

Hi,

yes i have solved the issue.

the reason was that while flashing the jffs2 file system, you should flash EXACTLY the size of the file system image, rounded to the nearest sector size (not block size)

i.e 0x800.

The problem was because uboot didn't calculate the oob same as previous uboot, and doens't deal with the last block of the image properly (even if padded with 0xff)

BR,

Oren.

Hello oren,

Thanks very much for your reply.

Do you know why exactly u-boot is not able to flash a jffs2 image padded with 0xff (that is say jffs2 image size multiple of the block size).

Btw, from which version did you build u-boot ?

BR,

greg

Hello all,

This thread is very helpfull and I have a side-track question: Is the POP NAND flash considered a RAW flash? I would like to try and use UBIFS which requires a raw NAND flash, meaning the FS implements its own software Flash Translation Layer (FTL) without an embedded controller.

So, is it RAW?

Thanks,

Matan

I am interested in this app note but it appears that the link above takes us to the datasheet for an obsolete Micron part.

Was there a specific app note associated with that part we should look for?   I did see a webinare discussing on-die ECC but that

doesn't seem like an app note to me.

I wish to use on-die ECC with non-obsolete Micron parts on OMAP3530 with Linux kernel 3.0...

Chris

LogicPD

Hello steve and all,

We are also using two nand flashes ,

one is hynix at chip select 0

and another one is micron at chip select 7

You said , updated x-loader, u-boot and uImage for 4bit ecc!

So i need your help where i 've to modify ?

Both nand we tried with 1 bit ecc, second nand at chip select 7 is unable to mount file system , read error gettting,

so now thinking to move for 4bit ecc,,,any clarification from your side is help ful?

Regards,

santosh vastrad

I'm sorry to report I moved on to another project before ever getting it to work. We reverted to 1 bit ecc.

Same Problem here: have to upgrade to a 4 bit ECC.

As uboot supports BCH4_SW I added BCH4 to my kernel (2.6.33, OMAP 3503, http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6), according to the TN-29-71 from Micron.

BUT: The BCH4 in kernel and uboot seems to be different. OOB data are at the same place, but not with same content. So isn't BCH4 != BCH4 ???

Uboot and XLoader are from git here

http://arago-project.org/git/projects/?p=u-boot-omap3.git

Hi Arno,

I suggest you to compare all settings in the uboot and kernel related to the BCH4 then find and eliminate the differences.

BR

Tsvetolin Shulev

Hi Tsvetolin,

Thanks for advice, this is what I did first, after discovering that content of calculation is different.

If you look at sources, you will find that they are not derived from each other. They differ completly, not just in function names, also in structures.

As I am not the only one, who uses TIs OMAP processors and PSP and struggles with EOL SDRAMs, I thought there is already a solution for that. Do I really have to reinvent the wheel ? I am neither an expert in RAMs nor in Galois fields.

Best regards

Arno

I tried this. I am just failed to enable and disable this on-die-ECC out of user Level (with some help of a Driver).

I need this (Switch off/on) to reflash the X-loader out of a running System.

At the first glance BCH was second best option, but on-die-ecc also has some drawbacks (including compatibility).

I did some "backporting" of Linux to Uboot. I was succesful in a way, that uboot could read the kernel, which is stored in BCH4(Linux style).

BUT: This only works once after power up. Interupting the boot process in uboot and do a "reset" in uboot cmdline, than CRC check of kernel fails. It seems, I changed something in hardware/register settings.

I really need help to change uboot/xloader to use the Linux kernel BCH4.