Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
Flash v1.0 User Guide
- 1 Installation Instructions
- 2 About Flash v1.2
- 3 Release Notes
- 4 Usage Instructions (USB connection)
- 5 Usage Instructions (UART connection)
- 6 Flash v1.2 (for developers)
- 7 Feedback
- 8 Porting Guide
- Locate the Flash application files on the Linux machine where the SDK was installed to. Typically, it will be installed to a folder under your home folder; i.e. /home/user/ti-sdk-x.x/host-tools/Windows/Flash-Utility.
- Move all the files from /Flash-Utility to a Windows machine. The current version of the tool runs on Windows only. A good method for moving the files is to use a samba server (www.samba.org). (TBD: please add link to more detailed instructions)
- Run setup.exe (or FlashInstaller.msi) to install the application on your PC. It can be uninstalled at any time by accessing the Add/Remove Programs function of Windows.
- Follow the installer instructions.
- Typical installation directory is c:\Program Files\Texas Instruments\Flash v1.0, but this can be modified from the installer's dialog screens.
- Source code is provided in a zip file in /Flash-Utility/Source. If you want to view the source (not necessary), unzip the file. Later versions will provide complete developers documentation which will instruct users on how to rebuild the sources, which tools are required, etc.
About Flash v1.2
This page contains a description of a tool – Flash v1.2 – that can be used to transfer binary images from a host PC to certain TI ARM-based target platforms. The tool consists of two main components:
- a GUI host application, called Flash v1.2 - a CLI host application, called OMAPFlash.
It is recommended to use the GUI for performing flashing functions. This documentation covers usage of the GUI. Future documentation will cover the CLI interface in more detail.
This application has been designed with flexibility and portability in mind. It is now possible to modify target register configurations without rebuilding the tool. This allows for easy modifications to various target peripheral configurations (such as SDRC, GPMC, Pad Control, etc.). This capability makes it possible to support new DDR devices and NAND devices without software changes. Check out the section #Porting Guide for more information on this feature.
Internally, the tool makes use of a ROM code mechanism for peripheral boot from UART or USB to transfer compatible drivers to the internal memory of the OMAP device. These drivers provide the mechanism by which the host applications can program binary images into the internal memories (NOR, NAND, SDRAM, etc.) of the target. All of this operation is hidden from the user.
- New Features
- USB Support
- Can install over previous versions without manual uninstall
- Selectable NAND vs. ONFI NAND mode
- Same as before
- New Features
- 35xx Support.
- Same as before
- UART support
- 37xx support
- Can support new NAND devices via text config file modification.
- Can modify target registers via text config file modification (for example SDRC, GPMC, pad config settings)
- ONFI NAND Support
- Supported operations: Download, Download and Execute (to Thumb mode code), Erase Region, Erase All.
- Windows GUI (no Linux yet).
- Scriptable Windows CLI (no Linux yet).
- Fully open source, BSD-style license.
- Download and execute can only branch to Thumb code.
- Storing images to NAND uses HWECC. Therefore, you cannot use a standard xloader to load uboot from NAND. Xloader uses SWECC when reading from NAND. The workaround is to use the uboot provided on the SD card to flash itself into NAND memory.
- GUI support does not yet exist to define new platforms. However, two memory choices are supplied, Hynix and Micron. For experimenting with modifications to the configuration text file (for instance, to port to a new platform) it is recommended that you modify the Micron files (and save a copy if you need the originals).
Usage Instructions (USB connection)
- Using a USB cable, connect the board's USB "On the Go" port to a USB port on the PC.
- Ensure that your EVM is set up for peripheral boot from USB. This may require changing the setting of SW4 on the EVM. Switch bits 2 and 3 to the ON position. Other bits should be off.
- After launching Flash app, ensure that the USB box is selected under "Link Selection".
- When you connect your board to your PC for the first time, you need to configure the PC to use the correct USB driver.
- You will see the "Found New Hardware Wizard" dialog box. Select "No, no this time", then "Next".
- Select "Install from a list or specific location (Advanced)".
- Use the browse box to select the following folder: <install dir>\usb_drv_windows. Normally, the full path will be c:\Program Files\Texas Instruments\Flash vX.X\usb_drv_windows.
- Make sure the box "search removable media" is unchecked.
- Make sure the box "Include this location in the search" is checked.
- Click Next. The driver should install correctly without error messages.
- Click Finish.
- Continue following the instructions below (UART connection) at #4.
Usage Instructions (UART connection)
- (Using a 9-pin serial cable, physically connect your host PC to the UART3 port on the target board.
- Ensure that your EVM is set up for peripheral boot from UART. This may require changing the setting of SW4 on the EVM. Switch bits 2 and 4 to the ON position. Other bits should be off.
- There are three ways to launch the Flash app. You can use the shortcut on the desktop, the entry that was created under Start->Texas Instruments, or directly from the application installation directory. The executable name is Flash.exe. See below for a snapshot of the user interface:
- In this initial version of the tool, device and board selections are grayed out. Currently, support is limited to AM37xx devices on the EVM.
- Next to the label "Choose memory:", select the SDRAM memory device for your target. Out of the box, the Hynix selection is the correct choice. You also have the option of choosing Micron.
- Next, select which peripheral memory you would like to program. Current choices are limited to NAND, ONFI NAND, and SDRAM.
- Choose the UART port that you have connected to on the host PC. Typically this will be 1 (i.e. COM1), or 2 (COM2) if you have two serial ports.
- Choose the operation that you want to perform:
- Download - download a binary image to the target
- Download and Execute - download a binary image and execute it. Must be loaded to SDRAM.
- Erase Region - Erase a select region of memory.
- Erase All - Erase all of the desired memory.
- Now, if the offset field is enabled, enter an offset from the start of the peripheral memory for your operation. This is a hexadecimal address value. For example, if you enter 0x80000 with Download and SDRAM selected, the application will download a binary image to address 0x8008:0000 (assuming the base SDRAM address is 0x8000:0000).
- If you have selected the operation "Erase Region", you will see the Size field enabled. Enter a size (hexadecimal, in bytes) that you want to clear. Clearing will begin at the selected offset.
- For download operations, you must select a binary file that you want to download. Click the "Browse..." button in order to browse the filesystem to select a file. The default folder that is opened is the "test_data" folder under the application installation folder. There are a few example binaries located in that folder for evaluation purposes.
- Once you have successfully made your selections, the "Go" button will be enabled. Press the "Go" button to execute your operation.
- While the operation is executing, you will have the option of pressing the "Abort" button in order to cancel the operation and make modifications to your selections.
- You will see the output of the operation in the Output text box at the bottom of the screen. If errors occur, related information will also be reported within the box.
- If everything is setup correctly, you will soon see is a line in the output with the text "Awaiting ASIC ID". When you see this line, reset the target platform.
- After you reset the target, your selected operation will be executed. Progress is reported within the output text box. Download speeds over UART are in the range of 10Kbps, so be patient if you have a large download - it could take several minutes.
- At any time, you may clear all of the text in the output box by pressing the button "Clear Output".
Flash v1.2 (for developers)
- GForge Page: https://gforge.ti.com/gf/project/flash
- Comprehensive developer documentation coming soon.
- Several options exist for feedback:
- Leave comments using the link at the bottom of the page. For any error conditions, please copy and paste the text in the output box into the body of the email. Also, identify your target board, processor, and memory types. Provide a synopsis of what you are trying to do.
- Join the mailing list (email@example.com)
- Join the development effort via the GForge page, and provide feedback there.
[Remainder of document intended for advanced users]
This is a small porting guide for Flash. It contains an introduction to the modifications that may be necessary in order to get Flash working on a new board or with a new memory device.
Porting to a new platform
In general, porting to a new platform should not require the modification or recompilation of the code base. The starting point will be to create a board configuration file for the new platform.
Existing board configuration files are found in .\Targets\Configurations. In order to add support for a new platform it is necessary to add a new board configuration file to the configuration folder.
Once the board configuration file has been created, it will need to be added to the content of omapflash2nd.txt, present in the application installation folder. This file allows Flash to find the board configuration file. When modifying the file, simply add a new line to it:
<platform> <omap id> <omap version> <omap type> <second loader file> -pheripheralboot_reopen -board_config <board configuration file>
where <platform> is the platform name (use a new name for the new platform), <omap id> is an id number provided by the OMAP device during peripheral boot over UART or USB along with the <omap version> number, <omap type> specifies whether the OMAP detected should be a High Security 'HS' or General Purpose 'GP' type, <second loader file> specifies the second loader to use with the combination of <platform>, <omap id>, <omap version> and <omap type> and the <board configuration file> is the newly added board configuration.
An example could be:
SDP_MDDR_HYNIX_4G 363007 07 GP Targets\2nd-Downloaders\dnld_startup_omap3_gp_4g.2nd -pheriphalboot_reopen -board_config Targets\Configurations\configuration_sdp3630_hynix_4g.txt
Note that the installation currently comes with second loaders supporting memory sizes of 2 Gb, 4 Gb and 8 Gb for GP and HS devices:
dnld_startup_omap3_gp_2g.2nd - OMAP3 GP w 2 Gb SDRAM dnld_startup_omap3_gp_4g.2nd - OMAP3 GP w 4 Gb SDRAM dnld_startup_omap3_gp_8g.2nd - OMAP3 GP w 8 Gb SDRAM dnld_startup_omap3_hs_2g.2nd - OMAP3 HS w 2 Gb SDRAM dnld_startup_omap3_hs_4g.2nd - OMAP3 HS w 4 Gb SDRAM dnld_startup_omap3_hs_8g.2nd - OMAP3 HS w 8 Gb SDRAM dnld_startup_omap4_gp_2g.2nd - OMAP4 GP w 2 Gb SDRAM dnld_startup_omap4_gp_4g.2nd - OMAP4 GP w 4 Gb SDRAM dnld_startup_omap4_gp_8g.2nd - OMAP4 GP w 8 Gb SDRAM dnld_startup_omap4_hs_2g.2nd - OMAP4 HS w 2 Gb SDRAM dnld_startup_omap4_hs_4g.2nd - OMAP4 HS w 4 Gb SDRAM dnld_startup_omap4_hs_8g.2nd - OMAP4 HS w 8 Gb SDRAM
The reason for this is that there is a link-time dependency on the placement of the heap and external memory for the memory device drivers in SDRAM and on the location of the second loader components in internal memory between HS and GP devices. Pick the right one - e.g. if you have a 4 Gbit memory on an OMAP3 GP based board, use 'dnld_startup_omap3_gp_4g.2nd'.
In order to create the new file it is often useful to start with a copy of one of the existing files. The file has three main sections:
- 'use' directive, pointing to a definition file listing a number of OMAP registers and their addresses
- 'memory' directives, specifying the memories on the platform
- initialization commands, modifying registers to control the configuration of the OMAP to match the platform
A 'use' directive can be used to point to a device definition file, e.g.:
Only one definition file can be used and it must be indicated before the first element using its definitions occurs in the configuration file.
The device definition file basically holds a set of paired of labels and values. The labels can be used in the device configuration file in place of the values in order to make the device configuration file more readable. The syntax is as follows:
PRM_CLKSRC_CTRL 0x48307270 CM_CLKEN_PLL 0x48004D00 PRM_CLKSEL 0x48306D40 CM_CLKSEL1_PLL 0x48004D40 CM_CLKSEL2_PLL 0x48004D44 CM_CLKSEL3_PLL 0x48004D48
A maximum of 1000 definition pairs can be present in a definition file.
Memories are specified using the 'memory' directive:
memory NAME [driver DRIVER] [parameters PARAMETER1 VALUE1 PARAMETER2 VALUE2 ... PARAMETERN VALUEN]
An example of a memory specification could be:
memory NAND driver Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin parameters gpmc 0x6E000000 cs 1 address 0x28000000 bberase 0
where the device name is NAND and the driver required to access it is present in the binary file nand_onfi_16bit_8bit.bin (part of this distribution). The driver needs a number of configuration parameters for correct operation. These are passed directly to driver as written on the line following the 'parameters' keyword. This distribution contains a number of driver binaries for various memory types. At present these are:
File : nand_onfi_16bit_8bit.bin Type : NAND Parameters: gpmc (mandatory) Base address of the GPMC in the OMAP cs (mandatory) Chip select where the device is present (or GPMC-config index) address (mandatory) Address of the device as mapped in the GPMC bberase (mandatory) Erase bad blocks in the device (0 for no, 1 for yes). Caution: erasing bad blocks may cause an irreversible loss of manufacturing information. onfi (optional) Read and use ONFI device description from the device (0 for no, 1 for yes). bpp (mandatory if onfi = 0) Bytes per page if ONFI information is not used. sbpp (mandatory if onfi = 0) Spare bytes per page if ONFI information is not used. ppb (mandatory if onfi = 0) Pages per block if ONFI information is not used bpl (mandatory if onfi = 0) Blocks per logical unit if ONFI information is not used l (mandatory if onfi = 0) Logical unit count (only 1 supported by the driver) acv (mandatory if onfi = 0) Address cycle values - 8 bit value with lower 4 bits for row and upper 4 bits for column. f (mandatory if onfi = 0) Features - 16 bit value with bit 0 = 16 bit data operation, rest are don't-care Examples : memory NAND driver Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin parameters gpmc 0x6E000000 cs 1 address 0x28000000 bberase 0 memory NAND driver Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin parameters gpmc 0x6E000000 cs 1 address 0x28000000 bberase 0 onfi 0 bpp 2048 sbpp 64 ppb 64 bpl 4096 l 1 acv 0x23 f 0x0019
For SDRAM, no driver is required, but the memory type must be specified with one parameter stating the base address in the memory map, e.g.:
memory SDRAM parameters address 0x80000000
Initialization of Target Device
A number of register operation commands can be used to configure the target device:
- WRITE - Write a value to a register
- MODIFY - Modify the value of a register
- POLL_ZERO - Poll a register value until zero
- POLL_NZERO - Poll a register value until not zero
- POLL_VALUE - Poll a register until value
- WAIT_N - Loop n times in a simple while-loop (where n is a value from 0x0000 to 0xFFFF)
- SPIN - Loop forever. This may be used for debugging.
- MODE_16 - Use 16 bit register access mode
- MODE_32 - Use 32 bit register access mode
The command structures are:
- WRITE : WRITE REGISTER VALUE
- MODIFY : MODIFY REGISTER MASK VALUE
- POLL_ZERO : POLL_ZERO REGISTER MASK
- POLL_NZERO : POLL_NZERO REGISTER MASK
- POLL_VALUE : POLL_VAL REGISTER MASK VALUE
- WAIT_N : WAIT_N N
- SPIN : SPIN
- MODE_16 : MODE_16
- MODE_32 : MODE_32
The definitions included from a definition file specified in a 'use' directive can be used with the commands. Definitions can be used for registers, values and masks, e.g.:
MODIFY CM_CLKEN_PLL_MPU EN_XXX_DPLL_MODE_MASK EN_XXX_DPLL_LOCK_MODE WRITE CM_CLKSEL3_PLL 0x00000009 POLL_ZERO CM_IDLEST_CKGEN ST_PERIPH_CLK_DPLL4_LOCKED