OMAPL-138 USE MT29C2G24MAAA(nand + mDDR) issue

Hello Beifeng,

Can you try writing some data on NAND and read back directly ?

Since the memory device is special type (NAND+mDDR), i would suggest you to follow all the design guidelines in the memory device datasheet.

Regards,
Senthil

Dear Senthil

Our products have been mass production based on OMAP-L138,Most of the products can work normally,A small amount of product will appear kernel CRC failure，Reading and writing NAND is normal, we have a backup  5 copies of UBL, 2 copies of UBOOT, 2 copies of Kernel, 2 copies of rootfs in the NAND Flash.

The main issue is Kernel CRC check failure occasionally, the system will stay in the uboot phase，We are looking for the main cause of the problem.Since we have used MCP (NAND + mDDR) in my design,May i reset the register of NAND flash after UBL?Or we have to modify the schematics,and use a new NAND flash base on TI official recommendation?

The following is the system log:

D8135_ubl_V2.0.0.2

Loading from NAND 256MiB 1,8V 8-bit, offset 0x200000
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3428856 Bytes = 3.3 MB
Load Address: c0008000
Entry Point: c0008000
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3428856 Bytes = 3.3 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

//Before that, the NAND signal quality was poor.

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

//After that, the NAND signal quality was good.

 

Please help check，thanks a lot!

 

hello,
If you see any CRC failures, after that you were able to boot next time when you do "Reset" the board ??
//NO, we checked the contents of the NAND using nanddump,we see some bytes difference between the original image.we must be reload kernel image for working normal.

Now,We have a relatively stable product（Module: D8135）based on OMAP-L138,There is some EMI filters in emifa bus，so We did not find the kernel CRC validation failed. and NAND signals is good.
Unfortunately，Other products based on OMAP-L138 have some kernel crc failure,The signal waveform of NAND is shown in the appendix.

I added code at UBL,The signal waveform of NAND is good, but UBL can not bootup,log as follows:
/***************************************/
M30P1_ubl_V1.0.0.0

Device OPP (408MHz, 1.3V)
Booting Catalog Boot Loader
BootMode = NAND_open error
NAND_open error
NAND Bootwith backup boot failed.
system will be power off

/*******************************************/

Code as follows：
AEMIF->A2CR = 0
| (0 << 31 ) /* selectStrobe */
| (0 << 30 ) /* extWait */
| (24 << 26 ) /* writeSetup 10 ns */
| (21 << 20 ) /* writeStrobe 40 ns */
| (14 << 17 ) /* writeHold 10 ns */
| (19 << 13 ) /* readSetup 10 ns */
| (50<< 7 ) /* readStrobe 60 ns */
| (1 << 4 ) /* readHold 10 ns */
| (3 << 2 ) /* turnAround ?? ns */
| (0 << 0 ) /* asyncSize 8-bit bus */
;

do you think we have to solve the problem of NAND signal waveform?

//NO, we checked the contents of the NAND using nanddump,we see some bytes difference between the original image.we must be reload kernel image for working normal.

If you see the some bytes difference between with original image, then its ECC problem.

"We must be reload kernel image for working normal"
Are you flashing the kernel in the same partition or just reading the kernel from NAND to DDR ??

Can you share the bootlog when you see the NAND CRC failures ?

If you see the some bytes difference between with original image, then its ECC problem.

"We must be reload kernel image for working normal"
Are you flashing the kernel in the same partition or just reading the kernel from NAND to DDR ??

Can you share the bootlog when you see the NAND CRC failures ?
//no,sorry, i must be reburn through the UART serial port.So bring bad influence to the customers

Now we want to know if we can fix the BUG by adding driver software?
Because the large number of single board CRC error occurs,We don't think it should be the NAND bit flip feature itself，do you think we have to solve the problem of NAND signal waveform?？？

log as follows:

M30P1_ubl_V1.0.0.0
Device OPP (408MHz, 1.3V)
Booting Catalog Boot Loader
BootMode = davinci: 0
Bad block table written to 0x00000ffe0000, version 0x01
Bad block table written to 0x00000ffc0000, version 0x01
ARM Clock : 408000000 Hz
DDR Clock : 150000000 Hz
PLL1 Clock1: 150000000 Hz
PLL1 clock2 :8001
Ethernet PHY: GENERIC @ 0x00

Hit any key to stop autoboot: 0

Loading from NAND 256MiB 1,8V 8-bit, offset 0x200000
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3771660 Bytes = 3.6 MB
Load Address: c0008000
Entry Point: c0008000
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3771660 Bytes = 3.6 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... Bad Data CRC
boot nand 0x200000 is error,now boot 0x600000

//no,sorry, i must be reburn through the UART serial port.So bring bad influence to the customers
Now we want to know if we can fix the BUG by adding driver software?
Because the large number of single board CRC error occurs,We don't think it should be the NAND bit flip feature itself，do you think we have to solve the problem of NAND signal waveform?？？

After flashing the kernel again on problematic board, then NAND signal wave form is proper now ??

Edited:

I hope, No, its because this problem is due to ECC bitflips but not with NAND signal.
Have you referred the below two post which I have given earlier ?

e2e.ti.com/.../73788
e2e.ti.com/.../236870

To confirm that this is not ECC or bitflip issue and its due to NAND signals are not proper,
Can you try to patch the u-boot for the ECC which I have mentioned in the above TI e2e post and try to reflash the u-boot (not kernel) which has the fix and see if the board is booting with older kernel itself...

I hope the u-boot is not capable of correcting the ECC bitflips and hence, not able to boot, once you reflashed the kernel via UART, ECC is rewritten with newer kernel image and booting.

Thanks you helps

After flashing the kernel again on problematic board, then NAND signal wave form is proper now ??
//NO
Have you referred the below two post which I have given earlier ?
//yes,i added some code in uboot,but i need some time to observe the effects of changes。

To confirm that this is not ECC or bitflip issue and its due to NAND signals are not proper,
Can you try to patch the u-boot for the ECC which I have mentioned in the above TI e2e post and try to reflash the u-boot (not kernel) which has the fix and see if the board is booting with older kernel itself...
//i see,I will update UBOOT once there is a new kernel CRC failed to happen。

I added NAND_Init code in UBL,the nand signal wave is good.but failed at NAND_open.

I think, your u-boot is not able to find the bitflips, that's why its simply load and run the kernel thus cause the CRC failure.
//yes,i changed kernel image (A few bytes are changed)by FlexHex that a bin file edit software.but the board can load and run the kernel.there is not find CRC check error.

You can do one more thing that try to make 1 or 2 bitflips (0 -> 1 or 1 -> 0) in kernel area (some how) and see u-boot is able to find and correct the bitflips (remember to add the printfs respective u-boot's ECC functions)
//I will test according to what you said.

I still have a question.can you help to check the schematic?
Another product based on OMAP-L138 is work Very perfect。The only difference is that his NAND signal wave is good,the product have sold thousands of units,No one CRC failed

thanks a lot

hello
i recieve a board from customs,log as follows:

T5180_ubl_V1.0.0.0

copy the backuboot
davinci: 0
Bad block table written to 0x00000ffe0000, version 0x01
Bad block table written to 0x00000ffc0000, version 0x01
ARM Clock : 408000000 Hz
DDR Clock : 150000000 Hz
PLL1 Clock1: 150000000 Hz
PLL1 clock2 :8001
Ethernet PHY: GENERIC @ 0x00

Hit any key to stop autoboot: 0

Loading from NAND 256MiB 1,8V 8-bit, offset 0x200000
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3771660 Bytes = 3.6 MB
Load Address: c0008000
Entry Point: c0008000
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3771660 Bytes = 3.6 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... Bad Data CRC
boot nand 0x200000 is error,now boot 0x600000

Loading from NAND 256MiB 1,8V 8-bit, offset 0x600000
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3771660 Bytes = 3.6 MB
Load Address: c0008000
Entry Point: c0008000
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4-D8135
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3771660 Bytes = 3.6 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
boot nand error 1
U-Boot >

Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
boot nand error 1
U-Boot >

Its clear that its due to ECC issue.
You can refer to the above given two posts which is explaining this problem.

hello

i have modified it refer to the above given two posts,and testing it.

i have checked the device ID and fourth ID of NAND Flash,the device ID is 0xAAh,the Fourth ID is 0x06h。

In other words,it use default NAND parameters(Method 5),so the register AEMIF->A2CR is 0x3ffffffc。if we continue to use the current NAND,we must modify the register AEMIF->A2CR in UBL？

Thanks a lot

You should modify the NAND timing parameters for the new NAND flash if it has different timings.