Problem Booting Omap3503 with 8 bit nand (Using Flash V1.2)

You are probably correct to assume the ECC issue.

Version 1.3 of the Flash tool is released, and it hopefully addresses this issue for you.

You need to use 1-bit HWECC mode to flash the ROM bootloader (usually x-loader) to address 0.  Then, for the secondary bootloader, or other NAND regions, use 1-bit SWECC mode.  The problem with version 1.2 and prior is that 1-bit HWECC is always used.

Hello Greg,

thanks for your reply.

I have re-run my tests with new flash software v1.3 and v1.4 and still acheived no success.

Greg Guyotte said:

You need to use 1-bit HWECC mode to flash the ROM bootloader (usually x-loader) to address 0.  Then, for the secondary bootloader, or other NAND regions, use 1-bit SWECC mode.  The problem with version 1.2 and prior is that 1-bit HWECC is always used.

I am not sure that this is my problem, because even with that problem I should be able to see the XLDR output (since XLDR must be written using 1bit HWECC), but I see nothing. (The same XLDR works normally booting from SD card ).

My major suspect is about ECC format for 8bit nands, but I can´t be sure. Has anyone reported success flashing a custom omap35xx board using  Flash 1.x ? On software output, I can't figure out any errors, has anybody any clue? (NAND is properly recognized when I run software - btw I modified config file to use onfi). 

Best regards

Thank you

----

Software output:

¯     -stdout

¯     -omap 3

¯     -com 3

¯     -t 60

¯     -p CUSTOM_OMAP35XX_BOARD

¯     -2

¯     chip_download NAND C:\TIEVM3530-nand.raw

¯ Leaving parameter file:temp_script.txt

¯ @temp_script.txt

¯ Looking for device (omap com3)

¯ Please turn off device, then turn it on again

¯ Awaiting ASIC id

¯ AsicId items 04

¯ AsicId id         01 05  01  34 30 07 57 

¯ AsicId secure_mode 13 02  01  00 

¯ AsicId public_id 12 15  01  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

¯ AsicId root_key_hash 14 15  01  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

¯ Searching 2nd for: CUSTOM_OMAP35XX_BOARD 343007 57 GP 

¯ Loading second file Targets\2nd-Downloaders\dnld_startup_omap3_gp_512m_12.2nd

¯ Entering parameter file:omapflash2nd.txt at line: 5

¯     -pheriphalboot_reopen

¯ Reading board configuration file Targets\Configurations\configuration_custom_omap35xx.txt

¯ Reading definition file .\targets\definitions\definitions_omap3.txt

¯     -board_config Targets\Configurations\configuration_custom_omap35xx.txt

¯ Leaving parameter file:omapflash2nd.txt

¯ Sending size of second file (0x00006804 bytes)

¯ Transferring second file to target (0x6804 bytes)

¯ Closing boot connection

¯ Found device (omap com3)

¯ Waiting for 2nd

¯ Found 2nd

¯ Looking for a driver for 'NAND'

¯ chip_driver NAND Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin gpmc 0x6E000000 cs 0 address 0x28000000 bberase 0

¯ Downloading driver

¯ Downloading 'Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin'

¯ Sending data (41724 bytes) :::::::::::::::..... [32764]

¯ Sending data (41724 bytes) :::::::::::::::::::: [41724]

¯ Sending data (41724 bytes) :::::::::::::::::::: [41724]

 Interface 'OMAPFLASH DRIVER v5'

 Driver 'NAND ONFI 16/8 BIT'

 Driver configuration: gpmc = 0x6E000000

 Driver configuration: cs = 0x00000000

 Driver configuration: address = 0x28000000

 Driver configuration: bberase = 0x00000000

 NAND HW ECC

 NAND BCH Mode = 0

 NAND HWECC offset = 1, size = 12

 NAND ONFIv2 VENDOR 0x2C MICRON      

 NAND 8 BIT DEVICE 0xAC MT29F4G08ABBDAHC    

 NAND NAND CYCLES 0x23 (3 ROW, 2 COLUMN)

 NAND 2048 BYTES/PAGE (SPARE 64)

 NAND 64 PAGES/BLOCK (131072 BYTES/BLOCK)

 NAND 4096 BLOCKS/UNIT (536870912 BYTES/UNIT)

 NAND 512 MB TOTAL SIZE

 NAND ONFI DRIVER INIT COMPLETE

¯ Downloading complete

¯ Elapsed time: 0:03.937 (13908 bytes/s)

¯ End loading driver

¯ Downloading

¯ Downloading 'C:\TIEVM3530-nand.raw'

¯ Sending data (786432 bytes) .................... [32764]

¯ Sending data (786432 bytes) :................... [65528]

...

¯ Sending data (786432 bytes) :::::::::::::::::::: [786432]

¯ Downloading complete

¯ Elapsed time: 1:08.587 (11565 bytes/s)

¯ Elapsed time: 0:00.000

Console program success, exit code: 0

I don't think you have a problem regarding 8-bit NAND, because your chosen device is ONFI compliant, so the driver can easily detect all NAND parameters and adjust accordingly.

I did notice that you have selected one of Micron's newest NAND devices that includes 4-bit on-die ECC support.  Are you planning to use the on-die ECC?  Even if you are not, you must use at least 4-bit error correction with this NAND device to ensure reliability.

The Flash tool does not yet support the enabling of the on-die ECC engine for these newer Micron parts.  This is a change that is coming in a future revision.  By default, the on-die ECC engine is disabled, so as long as your bootloader is not trying to enable it, we should still be able to function correctly.

What is your TIEVM3530-nand.raw file?  Is that a concatenation of X-loader plus a second level bootloader?  If so, I don't think it can work like this.  The X-loader needs to be downloaded separately so that it alone will be programmed with 1-bit HWECC.   Everything else, such as the second level bootloader that typically gets burned to offset 0x80000 in NAND flash, needs to be selected with 1-bit SWECC.  So you may have to perform multiple downloads to get everything working correctly. 

And, as I mentioned before - 1 bit SWECC is not going to be sufficient with this device.  Further complicating the issue is that the OMAP35xx cannot correctly calculate a 4-bit ECC, so your only option is to choose 8-bit BCH, which is an option available in Flash v1.4 and later.  Many OMAP35xx customers who are choosing this NAND memory are opting to use the on-die ECC provided by Micron.

I also need to mention that if you choose TI's 8-bit BCH error correction option, the Xloader must also support the 8-bit mode for reading the second level bootloader from NAND memory.  We have versions of Xloader, Uboot, and Linux kernel which have been updated to support 4-bit and 8-bit BCH error correction, if you need them.

Hi Greg.

Thanks again for your reply.

Regarding on-die ECC, yes, we're planning to use it, but just for windows CE kernel and filesystem, since on-die ecc is not needed for the first nand block, which is error free guaranteed using 1 bit ECC.

When I could successfully boot our board using nand, I'll look for 4-bit or 8-bit ecc support on windows ce bootloader / kernel. Maybe your xloader, uboot and linux can help me to figure out what I should change on CE. This way, your files are welcome (I can also try to flash them to my board, to test boot process).

I repeated the test, proceeding as follows:

1) Erase entire NAND (ecc seems to work, because when I don't tick "ONFI Compliant NAND?" box, the process fails for every block. When I tick, everything is fine).

2) Write XLDR to NAND, address 0x0, using 1-bit HWECC

3) Repeated (2) 3 times, for addresses 0x20000, 0x40000 and 0x60000

4) Write EBOOTNAND.NB0 to address 0x80000, using 1-bit SWECC.

When I boot, nothing shows up on UART3. The same XLDR + EBOOT works normally when booting from SD card.

I can't figure out what RomCode is doing, but I can scope nand bus activity. That's the result:

1) RomCode fetches the first NAND page. All bytes coming out from nand corresponds to written information. 

2) RomCode fetches the first page of next block, instead of fetching 2nd page of first block. Is this expected? I couldn't find any documentation about detailed bootloader operation.

3) The RomCode keeps reading first 4 blocks on a infinite loop fashion.

This behavior makes me believe that no code from flash is being executed. 

The result is the same when I try to flash the file "x-load-hwecc.bin.ift" (using the same procedure) that is present on 'test_data' folder from flash utility.

Excluding the ecc error possibility, do you have any other clue?

I am not suspecting of hardware errors because I can successfully write and read (checking consistency between written/read  data), only bootloader reads that fails. 

Thank you!

I got the same problem when use Flash1.4.

fail in x-loader write but success in u-boot/uimage write.

why?