NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
DM643x 24-bit SPI Secondary Boot Loader
Example DM6437 24-bit secondary SPI boot
- 1 Secondary Boot for SPI Storage Devices
- 2 Preparing Images Needed for Secondary Boot
- 3 SPI flash Boot Flow with Secondary Boot-loader Notes
- 4 EVM Surgery to enable 24-bit SPI boot
- 5 Usage Notes
- 6 Vital Stats
Secondary Boot for SPI Storage Devices
The ROMed SPI boot-loader for the DM643x does not utilize the full SPI band-width, resulting in slow boots. To workaround this issue a two stage boot process is proposed. At the first stage, a secondary boot code will be loaded via the ROMed SPI boot-loader. This code will then execute and download application code from the SPI storage device.
Secondary Boot Flow
The process flow for the secondary boot involves Primary boot of the DM643x via SPI. The DM643x ROM boot-loader will load the secondary boot code thru the SPI device. This secondary boot-loader (BL) then loads the application code from the same device. Both the secondary boot-loader and the application code are assumed to be in Application Image Script (AIS) format. AIS is a Texas Instruments Incorporated proprietary image format and is described in the application note, "Using the DM643x Boot-loader" (SPRAAG0D). The secondary boot code provided with this article assumes that the application image conforms to the AIS format. The secondary boot-loader does not implement the full range of AIS commands, but implements only the minimal subset required to load code from the SPI device. Limiting the AIS instruction set to the minimum required, is done to reduce the code size of the secondary boot-loader. Source for the boot-loader has been provided to allow further customization of the code if required by an application. One example customization would be to reduce code size by hard coding the parameters describing the actual SPI device that will be used. An outline of the basic flow for secondary boot is shown below.
|1||Compile secondary boot (customize if required)|
|2||Use genAIS utility to create AIS bootable image for secondary boot code from SPI storage device.|
|3||Compile application code.|
|4||Use genAIS utility to create binary AIS bootable image of application code from SPI storage device.|
|5||Use the “combineAIS” utility to combine the two images|
|6||Use the flash writer utility to write the combined code to SPI flash.|
|7||Set BOOTMODE [3:0] = 1111b to select boot from SPI|
|8||Issue POR reset to DM643x device|
Preparing Images Needed for Secondary Boot
Preparing Application Image for SPI Flash
The secondary boot-loader expects code to be stored on SPI flash device to be an AIS bootable image. The genAIS utility should be used to create an AIS image suitable for flashing to the SPI device. After compiling and linking the application code, the resulting object should be converted to a bootable image using genAIS. An example invocation of genAIS for NAND would be:
genAIS -otype bin –i myApp.out -o myAppAisImage.bin -bootmode raw
The secondary boot-loader will not check for bad blocks. It will also not perform any PLL or other settings (as specified by the “Function Execute” command) and the genAIS should not be run on the application code in such a way as to generate such commands. CRC checking can be switched off in the above command.
NOTE: The secondary boot-loader will work with images generated with the “raw” bootmode only.
Preparing Secondary Boot-loader Image for SPI Boot
Boot from SPI flash is accomplished by the ROMed boot-loader code. The ROM boot-loader expects the data in the SPI flash to be in AIS image format. The secondary boot code may be converted to an AIS image using the genAIS utility. Any PLL or other setting commands can be used here.
The combineAIS Utility
The combineAIS utility will accept the AIS images for the secondary boot-loader and the application code. It will combine the two images and produce a single output file which can be burned to the flash memory. The combineAIS utility will support AIS images in binary format only. Invocation without parameters prints a help message. An example invocation of the combineAIS utility is as below:
$> perl combineAIS.pl SPI_secondary_boot.bin GPIO_toggle_noCFG.bin test.bin 10
- SPI_secondary_boot.bin : Secondary boot-loader AIS image
- GPIO_toggle_noCFG.bin : Sample application AIS image
- test.bin : Combined AIS image
- 10 : Secondary boot-loader block size on the SPI flash in KB. i.e.: this much memory on the SPI flash is allocated to store the Secondary boot-loader image. This should be greater than the size of the secondary boot-loader AIS image and should be consistent with the value defined in SPI_2nd_boot.c
SPI 24 Write Utility
A sample SPI 24 write utility is provided that can be used to write the combined AIS boot image to a 24-bit SPI flash. The utility is provided in the form of a CCS project and source code. The corresponding “.out” can be loaded with the CCS after enabling the DM6437 EVM gel file settings. The input to the utility is the name of a binary AIS image file containing the secondary Boot-loader code/data to be written to SPI flash. The source and project files for the SPI write routine may be found in the SPI24Writer folder in the final release.
SPI flash Boot Flow with Secondary Boot-loader Notes
Please note, that the secondary boot-loader code will only parse a subset of the AIS commands. If your application uses an AIS configuration file, this file should be included with the AIS build for the secondary boot-loader. Do not include an AIS configuration file with the AIS build of application code written to the flash device.
Secondary boot-loader memory usage.
The secondary boot-loader will use a small amount of DDR memory to execute. The higher region of DDR will be used for this purpose. The application developer should ensure that he does not use this memory in his application. Exact size will be known on full development. An example “.cmd” file, to be used for the development of the secondary boot-loader on the DM6437 EVM, is attached. This file should be modified before use with custom boards having different amount of DDR2.
A proprietary 32-bit CRC check algorithm may be used as described in Sec 3.7 of spraag0d.pdf. Section wise CRC will be computed. In case of error, the section will be reloaded.
Internal memory / cache requirements
The boot-loader is required to perform CRC check on the read data. To achieve the desired performance cashes will be turned on as follows: L1P – 32KB used as cache L1D – 32KB used as cache L2 – 32KB used as cache
As a result, the entire L1P, 32KB of L1D and 32KB of L2 will not be available for allocation of initialized sections of the application. The unavailable memory ranges for these memories can be seen in sprs345d.pdf (TMS320DM6437 Digital Media Processor)
Consequently, the secondary boot-loader will not support loading code sections to the L1P.
To match the behavior of the primary boot-loader, the caches are turned off when the secondary boot-loader exits.
Profiling for the complete secondary boot process (loading from SPI flash and CRC check) is enabled through GPIO pin no. 87. At the start of boot process, the GPIO 87 pin is set and at the end of boot the GPIO 87 pin is cleared. These two events can be observed and timed on the scope to compute the combined load and data verification performance of the secondary boot-loader.
The GPIO signaling option can be turned on by defining the macro _GPIO_PROFILE_ in the file SPI_2nd_boot.c. By default, profiling is off.
EVM Surgery to enable 24-bit SPI boot
By default, the DM6437 EVM is configured for 16-bit SPI support over McBSP. To run the 24-bit SPI boot mode, a separate pin, "GP97" is used as chip select. This pin (GP97 from the DSP) needs to be connected to the Chip Select (CS) pint of the SPI flash (Instead of the default FSX pin). This connection can be done as follows:
- Remove R433 resistor (page 5 of the EVM schematics)- This would disconnect pin 1 of U65 socket (SPI flash) from FSX0.
- Make the connection between GP97 and Pin1 of U65 socket via R436 (page 5 of the EVM schematics).
- The sample application can be found here.
- A test application “GPIO_toggle” is provided for verifying the boot process. This application toggles the GPIO pin 87. The source and project files can be found in the GPIO_toggle folder.
- Use the script build/gen_app_img.sh to build an image for use with the primary bootloader
- Use the script build/gen_app_img_noCFG.sh to build an image for use with the secondary boot-loader.
- The secondary boot-loader code can be found in the SPI_secondary_boot directory. Follow the steps below to use the secondary boot-loader.
- The boot-loader image size is about 5KB and requires about 11KB of RAM to load and execute. Modify the SPI_secondary_boot.cmd to match your board specifications. Note that the above figures will change if any changes are made to the project (including recompilation with different compiler version). See the map file for exact details.
- Generate the application AIS image. A sample script using spraag0d configuration is provided as “make_AIS.sh”. (Change paths to match your system)
- Use the combineAIS.pl to generate the final image “test.bin” which can be burned to the SPI flash.
- The SPI read speed can be tested by running the SPI_read executable.
- Code size of secondary boot-loader : 4.5 KB
- Image size of secondary boot-loader: 11 KB in DDR
- Speed: depends on configuration (Memory, SPI clock). In excess of 700 KB/sec.