DM365 with new NAND (Samsung NAND 128MiB)

But leopardboard (Micron NAND 256MiB) is good like message..

boot message ....

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

U-Boot 1.3.4 (Dec 17 2012 - 12:40:27)

I2C:   ready DRAM:  128 MB NAND: 
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
Bad block table not found for chip 0
Bad block table not found for chip 0
nand_bbt: Error while writing bad block table -5 256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial Out:   serial Err:   serial Ethernet PHY: GENERIC @ 0x00 Hit any key to stop autoboot:  0 

DM365 :>saveenv
Saving Environment to NAND... Erasing Nand... Erasing at 0x3e0000 -- 100% complete.
Writing to Nand... done 
DM365 :>

Attached Detail Log messag

DM365 + Samsung NAND 128MiB

 View:http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/100/8838.log.txt]

Daniel,

Can you try a "nand scrub"? 

Hi,

I think you prefer to check u-boot build option to enable HW ECC and enable BBT. then, also check whether ECC table is the same as kernel.

BR.

Choi 

I subscribe to that.

I'm having ECC problems with this new NAND and IPNC Appro (using jffs2).

Also default binaries we have from Appro, via dm3xx_sdcard_boot flashing, are causing CRC errors.

Can someone help?

Maybe with the correct settings (at start) for UBOOT config (ecc, etc)? 

Mircea,

From my past experience with NAND, its almost impossible to explain these things in one place. There are various parameters that influence this.

1. Different people are using different NAND parts with SLC/MLC and even TLC technologies. The page size and other parameters changes across all these. Also ECC requirements changes across different NAND parts.

2. Different TI silicons support different hardware ECC algorithms. 1-bit hamming, 4-bit, 8-bit and 16-bit BCH for ECC etc. So the same SoC will implement one of these algorithms in the boot ROM code also, which also will vary. 

3. Also different file systems are used for different applications. Some of the applications use JFFS2 another will use UBIFS and some people choose to use YAFFS etc. The parameters for creating or flashing the images are also different across different NANDs.

4. Also different stages of booting supports different algorithms. For example RBL support one, UBL/U-boot supports another, kernel may support a third one etc.

5. Also on top of all these there are few bugs in the implementation NAND driver with hardware ECC support. 

Considering all these, it takes a lot of effort in gathering all these, test and documenting it in one place. 

Hi,

You can find config header file named davinci_dm365_ipnc.h in directory "u-boot/include/configs"

You check  options relate with hw ecc  is turned on. If it is on, you check ecc layout in "u-boot/cpu/arm926ejs/davince/nand.c.

In the Kernel, ecc layout would be found in linux//drivers/mtd/nand/davinci_nand.c. 

BR,

Choi

Hi?

Thanks your reply,

I already did 'nand scrub" for clean up the bad block..

It's not solved this problem...

Daniel,

What is the Samsung NAND part number for your board and the leopard board's Micron flash?

Hi all ?

I used binnary files
--------------------------------------------------------------
 1) U-BOOT: u-boot-1.3.4-dm365_evm.bin
 2) UBL: UBL_DM36x_NAND.bin

I write flash by dm3xx_sd_boot tools SW
--------------------------------------------------------------
 1) dm3xx_sd_boot-6_leopard is OK
 2) dm3xx_sd_boot-6.1 is BAD
to write to NAND

I have tested two types NAND
-------------------------------------------------------------
1)  MICRON - MT29F2G08AADWP
 $$$$$$$$$$$$$$$$$$$ LOG $$$$$$$$$$$$$$$$$$$$$$$$$$$$
U-Boot 1.3.4 (Dec 17 2012 - 12:40:27)

I2C:   ready DRAM: 
128 MB NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
256 MiB
In: serial
Out: serial
Err: serial
Ethernet PHY: GENERIC @ 0x01
Hit any key to stop autoboot:  0

u-boot:>saveenv
Saving Environment to NAND... Erasing
Nand... Erasing at 0x3e0000 -- 100% complete.
Writing to Nand... done

2) SAMSUNG - K9F1G08U0D
 $$$$$$$$$$$$$$$$$$$ LOG $$$$$$$$$$$$$$$$$$$$$$$$$$$$

U-Boot 1.3.4 (Dec 17 2012 - 12:40:27)

I2C:   ready
DRAM:  128 MB
NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
Bad block table not found for chip 0
Bad block table not found for chip 0
No space left to write bad block table
128 MiB
*** Warning - bad CRC or NAND, using default environment
In:    serial
Out:   serial
Err:   serial
Ethernet PHY: GENERIC @ 0x01
Hit any key to stop autoboot:  0

u-boot:>saveenv
Saving Environment to NAND...
Erasing Nand...
Skipping bad block at  0x003c0000
Skipping bad block at  0x003e0000

Writing to Nand... FAILED! 

u-boot:>nand bad
Device 0 bad blocks:  
00000000  
00020000  
00040000  
00060000  
~~~~~~~~
07fa0000
07fc0000
07fe0000

What is files and how to fixe or patch in u-boot source tree to fixed this problem..
Maybe  I need fixed UBL or u-boot binnary files to write to NAND by dm3xx_sd_boot_6 tools SW.

Daniel,

Can you check the EMIF timings register for NAND?

Please check AWCCR and A1CR registers and try to configure maximum values and see. Since UBL is working and able to detect NAND, its better you keep either maximum values or copy the values from UBL itself. 

Hi

I have check and change AWCCR, A1CR to maximum values in u-boot source, I did not change UBL because of i have not source about UBL source.

Anyway Test result same...

* u-boot >> cpu/arm926ejs/davinci/nand.c

Daniel,

Will it be possible to spare on board with me. I'm finding it an interesting issue to resolve. If you can spare one board do let me know.

Kernel gives me theese errors, NAND is K9F1G08U0D:

jffs2_flush_wbuf(): Write failed with -5

or

jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found

or sometimes it just stops while writing a file

Platform is IPNC-DM368-OV2715 and files are those provided by Appro, except I'm trying to make a custom kernel/layout. I know there are some changes of specifications of K9F1G08U0D from K9F1G08U0B, but I, for now, don't know/understand how to modify davinci_nand (if there is the problem)

Hi, I have the very same question with you. I also use the dm36x_sdcard_tool and the same u_boot.bin.

And have you solved this problem? If yes, would you like to let me know? I am anxious about this problem. 

Thank you very much.

Hi, same problem here swithching from K9F1G08U0B to K9F1G08U0D. 

I am using dvr-sdk (dvsdk2).

The situation

1) UBL is OK with both flash

2) u-boot 1.3.4 does not write the flash

     u-boot 2010.12-rc2 write but then I have some problem loading the linux kernel also with the B version of the flash;

3) Linux kernel does not write on flash.

I would like to change u-boot 1.3.4 and kernel in order to support the D generation of the flash but, looking at the datasheet of the flash I don't understand the difference which causes the issue.

Peregrinus,

What is the issue that you are facing while writing u-boot and kernel? 

How are you flashing both of them?

Hi Thomas, 

    thank you for the support. The u-boot is flashed through the CCS NANDWrite and it works fine with both flashes (K9F1G08U0B to K9F1G08U0D).

Then, if I use the u-boot 1.3.4, the command nand write from u-boot fails. 

With u-boot 2010.12-rc2 the command nand write is OK. 

From the u-boot I can flash the kernel and this step is fine.  I need the Montavista kernel since my code is based on the dvsdk.

After that I need to flash the filesystem. I do this by booting the kernel from flash and the filesystem from host PC in NFS. Then I mount the /dev/mtd3 and I use the

flash_eraseall/dev/mtd3

which produces a lot of "skipping bad block at..." so I suspect the flash has not been erased at all.

Then when I try to write on flash: 

yaffs tragedy: no more eraased blocks

!!!!!! Allocator out !!!!!!!

Hi Peregrinus,

Can you try to do a "nand scrub" from u-boot and see the behavior?

Hi Renjit,
  at the moment I am using the u-boot 2010.12-rc2 which writes on flash. 

As you suggested I made a nand scrub. I try it both with kernel area and filesystem area of the flash:

nand scrub 0x680000 0x400000

...

Erasing at 0x680000 -- 3% complete.
Erasing at 0x6a0000 -- 6% complete.
...
Erasing at 0xa60000 -- 100% complete.

Bad block table found at page 65472, version 0x01
Bad block table found at page 131008, version 0x01
Bad block table found at page 65408, version 0x01
Bad block table found at page 130944, version 0x01
OK

nand scrub 0x900000 0x780000

...

Erasing at 0x900000 -- 1% complete.
Erasing at 0x920000 -- 3% complete.
...
Erasing at 0x1060000 -- 100% complete.

Bad block table found at page 65472, version 0x01
Bad block table found at page 131008, version 0x01
Bad block table found at page 65408, version 0x01
Bad block table found at page 130944, version 0x01
OK

After that i flashed the kernel and made a boot using the kernel in flash and the network filesystem. 

Finally, I tried to erase the filesystem portion of the flash but the flash_eraseall command marks all block as bad as before.

thank you for your support. 

Hi,

Can you validate the same behavior on a different board? If this same behavior is seen the we need to see why flash_eraseall is marking every block as bad. This could be an issue in the NAND driver. 

Hi Renjith, 
      bingo, it seems that the issue was related to the timings of the nand device. The fix involve the following changes:

1) Kernel:
/drivers/mtd/nand/davinci_nand.c __devinit_nand_davinci_probe(...)

this->chip_delay was changed from 25 to 50

2) U-boot 1.3.4

/drivers/mtd/nand/nand_base.c chip->chip_delay was changed from 20 to 50

/cpu/arm926ejs/davinci/nand.c was changed from 0 to 50

With these changes both u-boot and kernel can read and write from flash.

However, I was not able to use the kernel with the u-boot 2010.12.rc2. In this case I am able to flash the kernel and the filesystem but when I boot the system with filesystem on flash I see on the console bad ascii characters alternated with meaningful strings, showing me that these is something wrong during the boot. This issue happen also with the old, "B" version, of the flash so it is not related to the flash but it is a compatibility issue between u-boot and kernel. I will use the u-boot 1.3.4 but, for the love of knowledge, I would like to know why the u-boot 2010.12.rc2 does not work with my kernel. 

I will test the board a bit before marking the question as solved. 

Thank you again for your support. 

Unfortunately this does not fix my issue. When I start my application and I begin using the voice codec the operating system crash after few seconds. My code was tested before I rebuild the kernel and u-boot and as was perfect.

Sorry my mistake with the file system creation. The solution I found seems reliable

Good to know that its resolved.