Using Flash Tool v1.6 with 8-bit NAND Flash

Kevin:

In the configuration file for your board in the platform memories section at the top look at one of the last parameters:

f 0x0019   /* for 16-bit NAND */

Change that to:

f 0x0018  /* for 8-bit NAND */

That corresponds to the "Features Supported" word in the Parameter Page Data Structure of the Micron NAND devices.

HWECC BCH8 is most commonly used.    You may need to change GPMC_CONFIG7 depending on your memory sizes. 

Keep in mind that the NAND is not memory mapped.  Also, the flash tool cannot program NAND beyond an offset in NAND

of 2**32.

MichaelT

Also, the NAND driver in U-Boot & Kernel can detect and adjust for the NAND width.

If your device is ONFI-compliant, check the ONFI checkbox in flash tool.  That

eliminates possible user error since it automatically reads the geometry info

from the NAND device.

MichaelT

Michael,

Thank you for the quick response.  I will test with a 2nd board tomorrow as I'm having USB connectivity issues with the board I'm presently testing.

I will respond with my results as I learn more.

Thank you,

Kevin

Michael,

Continuing on with our testing, we are still receiving the same response - "Waiting for 2nd".  I spent a bit of time searching the forums for this same symptom and it appears to be a common problem.  Perhaps I'm missing something, but I have not (yet) found an answer that seems to address our problem.  I apologize if this question has actually been answered, but please allow me to ask it again with the specifics for our board.

We have a fairly simple design using a CMOS Image Sensor, and SDRAM and NAND Flas and the USB interface.  As I stated we are attempting to use Flash v1.6 over USB to bring up the first 2 boards.

Our SDRAM is a 2Gbit Micron MT47H128M16RT-25E, our NAND Flash is a 1Gbit Micron MT29F1G08ABBDAH4 (8-bit wide) - I'm using a 26MHz oscillator.  I am using the Custom AM35xx Board Target in Flash Tool.  I've modified configuration_custom_am35xx.txt to:

• use "f 0x0018" versus "f 0x0019" in all the ONFI NAND Flash lines
• changed GPMC_CONFIG1_0 line to "WRITE         GPMC_CONFIG1_0       0x00000800" to support 8-bit NAND Flash
• added a number of GPMC Register writes to configure 4 GPIO pins which drive 4 User LEDs

If I attempt to do anything at all - including Erasing a 0x80000 region at offset 0 I get the following.

¯ -stdout

¯ -omap 3

¯ -no_force_package_alignment

¯ -t 60

¯ -p CUSTOM_AM35XX_BOARD

¯ -2

¯ chip_erase NAND1BITBOOT 80000

¯ Leaving parameter file:temp_script.txt

¯ @temp_script.txt

¯ Looking for device (omap usb)

¯ Please turn off device

¯ Please turn on device

¯ Waiting for device (omap usb)

¯ Found device (omap usb)

¯ Awaiting ASIC id

¯ AsicId items 05

¯ AsicId id 01 05 01 34 30 07 58

¯ 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

¯ AsicId checksum 15 09 01 59 DB 63 8B 00 00 00 00

¯ Searching 2nd for: CUSTOM_AM35XX_BOARD 343007 58 GP

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

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

¯ -pheriphalboot_reopen

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

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

¯ -board_config Targets\Configurations\configuration_custom_am35xx.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 usb)

¯ Waiting for 2nd

¯ Reception failed - timeout after 60 s during peripheral boot (waiting for 2nd)

Console program failed, exit code: 2

If I understand the "Waiting for 2nd" line correctly, the tool is waiting for the file dnld_startup_omap3_gp_2g.2nd to execute, which appears to have been successfully transferred to our device and should be the correct file for our device.

The User LEDs are set correctly based on the register writes that I added to the configuration_custom_am35xx.txt file and I can access the registers and modify the states of these 4 LEDs via JTAG and an XDS100 v2 emulator from CCS.

So at this point, I'm beginning to hope that my hardware may be OK and I am just missing some small detail in terms of my configuration.

As I'm presently only attempting to eras a selected region of the NAND Flash, does the SDRAM configuration matter at this point? Can you explain what "Waiting for 2nd" actually means and perhaps offer a suggestion or two as to what I may need to check or change?

Any and all help is greatly appreciated.

Thank you,

Kevin Taberski

The 2nd loader binary you are using tries to place itself into the top end of the 2Gbit SDRAM.  How big is your SDRAM?

MichaelT

Michael,

Our SDRAM is a 2Gbit Micron MT47H128M16RT-25E - as I stated above.

So it seems likely that I either have the SDRAM mis-configured, or I have a physical problem with the SDRAM interface.  I will study the configuration file as it pertains to the SDRC - any suggestions?

Is the 2nd loader needed just to erase the NAND Flash?

Thank you,

Kevin Taberski

Michael,

I solved perhaps my biggest problem - I can now erase the NAND Flash (i.e. Flash tool is no longer "Waiting for 2nd").

The discrepancy lies if the fact that I am using a single Micron MT47H128M16RT-25E.  In other words, I have a 16-bit data bus interface to the SDRAM.  The default configuration supports a 32-bit interface, so all the eval boards must contain 2 SDRAMs!

Here's the changes that I made to "configuration_custom_am35xx.txt" - (comments added):

#WRITE        EMIF_SDRAM_CONFIG        0x40801432 # DDR2, Differential DQS Enable, Full Drive Strength, 32-bit, CAS Latency 5, 8 Banks, 1024 Word Page
WRITE        EMIF_SDRAM_CONFIG        0x40805432 # DDR2, Differential DQS Enable, Full Drive Strength, 16-bit, CAS Latency 5, 8 Banks, 1024 Word Page

So the hint or tip that I was looking for was SDRAM data bus width.

Perhaps this information will prove useful to future users of this tool.

Thank you,

Kevin Taberski

The second loader programs are pre-compiled when the flash tool is built.  There are different versions based on the SDRAM size in the system.  The program takes care of initializing clocks and SDRAM interface per the text entries in the configuration file.  The 2nd loader also contains drivers for various flash memory types.  For Sitara ARM we have only made use of the NAND driver.  This allows flashing of the bootloader(s) and Linux kernel into NAND without the aid of a working U-Boot or Linux kernel for a custom board.  The underlying program is a console application called OMAPFlash.  The flash tool is actually a GUI application that wraps OMAPFlash.  Starting with the AM389x (DM816x), AM387x (DM814x) and AM335x devices, the ROM boot loader has been redesigned to use off-the-shelf tools for booting, such as ordinary DHCP/TFTP servers and basic terminal programs with XMODEM / KERMIT file transfer capabilities.  For AM335x a new flash tool is under development that makes use of the USB and Ethernet booting and flashing capabilities in U-Boot.  The new flash tool will be available in 2Q13.  See the preliminary user's guide here:

http://processors.wiki.ti.com/index.php/AM335x_Flash_Tool_User%27s_Guide

Do you require any more assistance with the AM35x/AM37x Flash Tool?

MichaelT

As the software developer on this project I have a few questions:

1. I see from the description that the AM335x Flash tool will program the root file system onto NAND.  Does the exisiting Flash1.6 do this, or is it a new feature only for AM335x.

2. Where may I find guidance on the changes needed to both phases (xloader/MLO and "u-boot") of the u-boot system for hardware differences?  I see that one input to this is include files from the Pin Mux utility, but what are the others?  Is there, perhaps, a checklist?

I have discovered that one can use Flash 1.6, at least on the EVM board, to download a root file system onto NAND flash.  I used the following procedure:

1. First, erase the entire NAND flash.

2. Then download the MLO (xloader), u-boot, and uImage(Linux) onto the NAND flash at the offsets given in the Flash 1.6 User Guide, Example 2 for Micron NAND flash.  Ensure that the MLO and u-boot are downloaded using the "X-Loader / U-Boot" 1-Bit ECC Layout, and that the uImage of the kernel is downloaded using "Kernel."

3. Finally, download the jffs2 image of the root file system onto the NAND flash at the offset (0x780000) given in:

http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_04.02.00.07_UserGuide#Flashing_from_u-boot

section "Flashing JFFS2 filesystem" under NAND.

That's all, change the DIP switches to boot from NAND and power cycle!

In order to obtain the root file system image, take one of the the tarballs from the "filesystem" subdirectory of the AM35127 SDK, unpack it into temporary directory as the root user, and use mkfs.jffs2 to create a .bin file of the directory as described in:

http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_04.02.00.07_UserGuide#Flashing_from_u-boot

section "Creating JFFS2 filesystem"