4. Foundational Components¶

4.5.1. AM335x/AM437x¶

Overview

Source Reference

< BASE_DIR = PDK_INSTALL_DIR\packages\ti\starterware>

Source files:

• BASE_DIRbootloadersrc: Common source files for bootloader functionality
• BASE_DIRbootloadersrc<device>: Files specific to device to initialize platform features like PLL, pinmux and DDR

Build Files:

• BASE_DIR/build/makerules/rules_a8.mk: Common Compiler flags used for A8 cores. Applies to AMIC110 and AM335x
• BASE_DIR/build/makerules/rules_a8.mk: Common Compiler flags used for A9 cores. Applies to AM437x devices
• BASE_DIR/build/makerules/platform.mk: Global settings for all components for a particular platform.
• BASE_DIR/build/makerules/components.mk: Specific settings for components in starterware
• BASE_DIR/build/makerules/build_cfg.mk: Flags to enable features in the build
• BASE_DIR/bootloader/Makefile: Makefile for bootloader that provides list of source files and library to create bootloader binary.

Boot and flashing tools:

• BASE_DIR/tools Contains tools to create boot images and flashing tools to program the boot binary on the boot media.

Bootloader execution sequence

The Processor SDK RTOS boot loader uses a two stage boot process. The different stages of the application boot sequence using Processor SDK RTOS bootloader are shown below:

Boot Sequence

1. Power on Reset
2. ROM Bootloader (RBL)
   • Platform configuration and initialization.
     • DPLL and clock settings for MPU, I2C, MMCSD, USB, SPI, QSPI, Ethernet etc.
   • Checks Sysboot pins and choose booting device
     • If no valid bootloader found on booting device, RBL checks for next booting device. The sequence depends on RBL execution flow and Sysboot pins.
   • RBL gets image size and load address by checking TI Image Header appended on bootloader binary(.bin). Check binary formats.
   • Loads the binary to internal OCMC memory at the Load address fetched from TI Image Header
   • Passes control to Secondary Bootloader(SBL)
3. Secondary Bootloader(SBL)
   • Configure PLL and Initialize DDR
   • Configure PRCM and PinMux  for Boot Peripherals
   • Copies application image to DDR
   • Passes execution control to Application
4. Application execution

Tools and Binary formats

TI Boot image

Binary format conversion procedure

Binary format conversion in Linux

1. To convert from .out -> .bin

TOOLCHAIN_PATH_<A8/A9>/bin/arm-none-eabi-objcopy -O binary <application>.out <application>.bin

2. Build tiimage.out. Go to starterware/tools/ti_image/

gcc tiimage.c –o tiimage.out

3. To convert from .bin -> _ti.bin

tiimage.out <Image Load Address> NONE <application>.bin <application>_ti.bin

Binary format conversion in Windows

1. To convert from .out -> .bin

TOOLCHAIN_PATH_<A8/A9>/bin/arm-none-eabi-objcopy -O binary <application>.out <application>.bin

2) To convert from .bin -> _ti.bin. tiimage.exe is provided as prebuilt binary in starterware/tools/ti_image.

tiimage.exe <Image Load Address> NONE <application>.bin <application>_ti.bin

Boot Modes supported

Following are the Boot Modes supported through AM335x/AM437x bootloader for the various EVMs.

Building the Bootloader

Pre-requisite: Setup SDK build environment as described in article

Setup_Environment

Normal Operation of Bootloader:

Bootloading an application from flash into DDR memory as in case of TI evaluation platforms is described as normal operation mode for the bootloader. This is the default behaviour of the bootloader and can be built using the following command in starterware.

gmake bootloader BUILDCFG=boot BOOTMODE=<BOOT_MODE> PLATFORM=<EVM> PROFILE=<BUILD_PROFILE> -s KW_BUILD=no

• BOOT_MODE: mcspi, nand, qspi, mmcsd, uart (Check supported boot modes for your evaluation platform)
• EVM: am335x-evm, am43xx-evm, amic110-ddrless
• BUILD_PROFILE: debug, release

Additional Build options (currently support only for AMIC110/AM335x ICE Users)

• DDR less Application boot setup

gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=debug -s KW_BUILD=no USE_DDR=no
gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=release -s KW_BUILD=no USE_DDR=no

This option builds an ultra light weight (<10 KB) bootloader for cost optimized application that don`t external DDR memory.

• PRU/ICSS Enable in SBL

gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=debug -s KW_BUILD=no ENABLE_PRU=yes
gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=release -s KW_BUILD=no ENABLE_PRU=yes

This feature is required in application that need to quick wake up of ICSS/PRU cores. The PRU cores can be woken up and loaded from the SBL by combining the ENABLE_PRU and BIN_LOAD arguments.

• Load additional binaries from flash

gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=debug -s KW_BUILD=no BIN_LOAD=yes
gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=release -s KW_BUILD=no BIN_LOAD=yes

The location of binaries in offset is configured using sbl_flash_offset_cfg.h in the bootloader source. Users are required to use TIIMAGE tool to append an header to the binary so that the bootloader knows the loction and size of the binary to be loaded.

Industrial DDRless Booting

The AMIC110 DDRLESS platform provides a superset flag to enable all the above features and build the bootloader . The superset build is invoked using BUILD_ICSS_DDRLESS_BOOT=yes as shown below:

gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=debug -s KW_BUILD=no BUILD_ICSS_DDRLESS_BOOT=yes
gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=release -s KW_BUILD=no BUILD_ICSS_DDRLESS_BOOT=yes

Prebuilt binaries inside the Processor SDK RTOS for AMIC110-DDRLESS will be configured using this option to allow for testing of cost optimized industrial use case.

Boot Mode settings

Boot Modes

Booting Via SD Card

Booting from SD Card involves two steps.

1. Preparing SD card.
2. Booting target.

Preparing SD card

1. To boot target the SD card should be bootable. Follow the steps at Creating bootable SD card in windows or Creating bootable SD card in Linux.
2. Delete the “MLO” and “app” in the bootable SD card which are created in the process of making the SD bootable.
3. Bootloader images with ti header (<mmcsd_bootloader>_ti.bin)should be renamed to “MLO”. Bootloader images are located at <PDK_INSTALL_DIRpackagestistarterwarestarterwarebinarybootloaderbin<TargetType>
4. Similarly the converted application binary image has to be renamed to “app” from “<app_name>_ti.bin“
5. Copy both the boot loader image “MLO” and the application image “app” to the SD card.
6. The SD card is ready for use on target.

Booting target

1. Insert SD card to the base board SD slot. Connect a UART cable to a host running a serial terminal application (teraterm/hyperterminal) with 115200 baud, 8bit, No parity and 1 STOP bit configuration.
2. Configure the board for SD Boot mode
   1. SD instance 0 (on base board) is available in all profiles.
   2. SD instance 0 boot mode needs to appropriately set. For SD boot to be selected first, SD boot should appear first in the boot device list in the boot mode. If any other boot mode is selected, even if a SD boot card is inserted, and does not appear first in the list, the first available sane boot image (like NAND or SPI etc) is booted and SD is not selected. Only if no sane boot image is found in the first devices, SD boot image will be selected.
3. Once SD boot image is chosen, the MLO is first detected and copied and executed from the OCMC0 RAM. The MLO then copies the application image (app) from the card to the SDRAM and passes the control to the application. If the process is succesful, messages identifying board and SoC will appear on the serial console.

After this the application will take control and execute.

NOTE: If board have BootMode selection pins choose proper Boot Selection pins from hardware reference manuals.

Booting Via QSPI

Booting from QSPI flash involves two steps-

1. Preparing Flash Device
2. Booting target.

Preparing Flash Device

1. Copy bootloader image(bootloader_boot_qspi_a9host_debug.bin rename) and app image(“<app_name>_ti.bin”) into the SD card. The file names have to be renamed in such a way that the length of name is less than 9 characters. Any file name less than 9 characters can be used. Rename the bootloader file to ‘boot’ and application image to ‘app’ with no extensions.
2. Copy the ‘config’ file into the SD card which will contain the names of the image to be flashed and the offset. A sample config file can be found at <PDK_INSTALL_DIRpackagestistarterwarestarterwaretoolsqspiconfig> directory. Do not change name of the config file. NOTE: “config” file can be used without any modifications if bootloader and application images are renamed to “boot” and “app”. NOTE: Do not rename bootloader to be copied to SD card as “MLO”, as MMCSD bootloader expects “MLO” and “app” to boot.
3. Now SD card contains 1)boot 2)app 3)config files. config file contains the address of boot image as 0x0 and app image as 0x80000. Insert it into the SD card slot.
4. Connect the board with CCS and load the prebuilt qspi flash writer application from <PDK_INSTALL_DIRpackagestistarterwarestarterwarebinaryqspi_app_flash_writerbinm43xx-evm>
5. Run the QSPI flash writer application. Following logs expected on console.

StarterWare QSPI Flash Writer!!
BOARDInit status [0x0]
SoC                   : [AM43XX]
Core                  : [A9]
Board Detected        : [IDKEVM]
Base Board Revision   : [UNKNOWN]
Daughter Card Revision: [UNKNOWN]
Copying boot to QSPI Flash
Copying app to QSPI Flash
Changing read to quad mode
Read mode has been changed to Quad mode
SUCCESS!!!
Flashing completed

Booting the target.

1. Connect UART cable to a host running serial terminal application (teraterm/hyperterminal) with 115200 baud, 8bit, No parity and 1 STOP bit configuration.
2. After flashing successfully remove SD card and reboot to see following logs

StarterWare Boot Loader
BOARDInit status [0x0]
SoC                   : [AM43XX]
Core                  : [A9]
Board Detected        : [IDKEVM]
Base Board Revision   : [UNKNOWN]
Daughter Card Revision: [UNKNOWN]
Copying Header of the application image
Copying image from flash to DDR
Jumping to StarterWare Application...

NOTE: Boot logs will appear approximately after 25 seconds on reset.

 NOTE:If there is no boot mode selection present on board, boot image will be loaded depending on ROM boot sequence
Example: If QSPI flash and MMCSD has valid bootloaders, on reset MMCSD boot image will be loaded following ROM Boot sequence.

Booting Via UART

1. Configure board for UART boot mode : UART boot need to be first in the boot device list. Note: In case if any other boot mode is selected, the first available boot image (eg:NAND or MMCSD etc) will override. In case of no valid images, UART boot will be selected.
   • Select View->Memory Browser through CCS.
   • Select address 0x44e10040.
   • Write 0x19 to last 2 bytes of this memory address.(UART boot)
   • Soft reset the board. This is a volatile bit which gets reset after power on.
2. ROM code will print “CC..” on UART console expecting Bootloader via XMODEM. File can be sent via xmodem through tera-term File-> Transfer -> XMODEM -> Send.
3. On transmitting bootloader image, bootloader_boot_uart_a9host_debug.bin via XMODEM, following message will be expected on serial console.

CCCCCCCCCCCCCCCCCCCCCCCCCCCC
StarterWare Boot Loader
BOARDInit status [0x0]
 SoC                   : [AM43XX]
 Core                  : [A9]
 Board Detected        : [IDKEVM]
 Base Board Revision   : [UNKNOWN]
 Daughter Card Revision: [UNKNOWN]
GPIO Instance number: 0
Pin number: 22
Please transfer file:
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

  4.  As  a next step application binary (without header) can be sent via XMODEM which will lead to application start executing.

Booting Via McSPI

Booting from McSPI involves two steps.

1. Preparing Flash Device
2. Booting the target.

Preparing Flash Device

• Set the appropriate bootmode if applicable for EVM.Refer Boot mode settings. Note: Most of the boards may not have switch settings.
• Add a required target configuration in CCS depending on emulator and board connected.
• Connect target to required core. Ex: A8.
• Load the flash writer from <PDK_INSTALL_DIRpackagestistarterwarestarterwaretoolsflash_writerspi_flash_writer_AM335X.out onto the EVM.
• Run the application and observe the logs on CCS console.

Starting SPIWriter.
Choose Operation:
Enter 1 ----> To FLASH an Image
Enter 2 ----> To ERASE Flash
Enter 3 ----> To EXIT

• When Flash option is chosen program prompts to enter file name.

Enter the File Name

• Provide the complete path of file bootloader_boot_mcspi_a8host_release_ti.bin at directory “binary/bootloader/bin/<PLATFORM>/<gcc/ccs>/” and hit Enter.

Enter the Offset in bytes (in HEX)

• Provide 0x00000 to flash bootloader.
• To flash application binary image <app_name>_a8host_ti.bin, provide 0x20000.
• Wait for few miniuits as flashing is a slower process.

Erasing flash at byte offset: xx, byte length: xxxx
SF: Successfully erased xxxx bytes @ xxxx
Writing flash at page offset: x, number of pages: xxxx
Flashing is in progress...
Verifying... Success.

• Once SPI flash writing completes disconnect target.

Booting the target

1. Connect a serial cable to a host running a serial terminal application (teraterm/hyperterminal) with 115200 baud, 8bit, No parity and 1 STOP bit configuration.
2. Configure the board for SPI boot mode.
3. On reset, ROM bootloder copies the bootloader from flash to internal memory. The bootloader then copies the application image from flash to DDR and passes the control to the application.

Booting Via NAND

Booting from NAND involves two steps.

1. Preparing Flash Device
2. Booting the target.

Preparing Flash Device

• Configure BOOT pins for NAND Boot mode settings
• Connect target with CCS.
• Load the <PDK_INSTALL_DIRpackagestistarterwarestarterwaretoolsflash_writernand_flash_writer_AM335X.out> to target and Run. Flash writer will output messages to CCS console. When it prompts for inputs, proper inputs shall be given via CCS console.
• When prompted for binary file name, update file with proper path.
• Select option for flashing.

Choose your operation
Enter 1 ---> To Flash an Image
Enter 2 ---> To ERASE the whole NAND
Enter 3 ---> To EXIT

• If Option 1 is selected, enter image path to flash when prompted as shown below.

Enter image file path

    Provide the complete path (e.g. <PDK_INSTALL_DIRpackagestistarterwarestarterwarebinarybootloaderbin<am335x/am437x-evm><compiler>bootloader_boot_nand_a8host_<debug/release>_ti.bin)

• Enter offset when prompted as shown below.

Enter offset (in hex):

1. Use hex format
2. If bootloader is to be flashed, provide 0x00000. For application binary, provide 0x80000.

• Select ECC for flashing.

Choose the ECC scheme from given options
Enter 1 ---> BCH 8 bit
Enter 2 ---> HAM
Enter 3 ---> T0 EXIT
Please enter ECC scheme type:

    Always select BCH8 for bootloader and application as ROM code and bootloader uses the BCH8 ECC scheme.

• Ensure that flash info displayed by tool matches NAND flash in EVM.
• After this tool should first erase the required region in flash and then start flashing new image.
• If flashing procedure is complete following message should be displayed.

Application is successfully flashed
NAND flashing successful!

• Once NAND flash writing completes, disconnect from CCS.

Booting the target

• Connect a UART cable to a host running a serial terminal application (teraterm/hyperterminal) with 115200 baud, 8bit, No parity and 1 STOP bit configuration.
• Configure the board for NAND boot mode. Refer  Boot mode settings
• On reset, ROM detects bootloader from NAND and copies it to internal memory. Bootloader then copies application image from the NAND to DDR and passes control to application. If the process is succesful, following messages appear in serial console.

   StarterWare Boot Loader
BOARDInit status [0x0]
SoC                   : [AM335X]
Core                  : [A8]
Board Detected        : [GPEVM]
Base Board Revision   : [1.5]
Daughter Card Revision: [UNKNOWN]
NAND flash is connected to GPMC on this board
Jumping to StarterWare Application...

Test Application

The section explains steps for building and booting a sample pdk application for am335x or am437x using MMCSD bootloader.

Test Application Image Creation

Follow below steps to generate the bootable application image.

1. Generate .out files using steps for Rebuilding PDK. Locate .out file in directory <PDK_INSTALL_PATH/MyExampleProjects/<ExampleProjectDirectory>/Debug>
2. Convert files to support MMCSD boot using steps as per Binary format conversion procedure.
3. Rename generated <Application>_ti.bin to “app”.

Loading Test application

Usage Notes

• Bootloader Memory map

The bootloader code runs from internal OCMC memory and occupies certain amount of OCMC memory that is not available for application to use during booting.

Refer to the map file for the boot loader to check for latest information on the memory utilization in the boot loader.

Location of linker command file:

BASE_DIR\binary\bootloader\bin\<platform>\gcc

After SBL execution is complete, this region can be used as per application requirement.

• Configuring entry point for SBL

The three files that help setup the entry point in the bootloader build are “PDK_INSTALL_PATHpackagestistarterwaresocarmv7agccsbl_init.S” and the linker command file “PDK_INSTALL_PATHpackagestistarterwareexamplesgcc<device>_boot.lds”. The global symbol Entry is used to provide the entry point to the bootloader. The Base address of the memory section OCMCRAM (starts at 1K offset in OCMC RAM as defined in TRM) is then used by the tiimage or GPHEader tool to provide RBL the guidance to find the entry point to pass control. After MLO is created check the TI image format file( _ti.bin) to confirm that the entry point matches the location of Entry symbol in the .map file.

• Boot image creation tools generates a large boot image if load sections are fragmented

Please note that when using objcopy the compiler generates a contiguous binary that gets loaded by the bootloader at the location specified in the header appended by TIIMAGE boot utility. IF you have some code sections in OCMC or SRAM and some section in DDR the compiler will generates a binary that spans across full memory range which would be in order of MB or even GB size so it is recommended that you create compact binaries that can be loaded into memory or implement a ELF parser to bootloader memory sections that may be fragmented in the address space. you can also load separate binaries for OCMC sections and DDR memory and load the sections separately

• Removing Heap section from application binary to speed up boot times

A common issue reported with the ARM GCC compiler is that it appends Heap section associated with the binary to the binary image used to boot. The Heap section is usually filled with zeros so can cause significant delay in boot times. Essentially the bootloader will be writing a bunch of zeros in memory so is inefficient. Following work around has been used to circumvent the issue

Option 1: Eliminate the heap by using the compiler option “–remove-section” as described in the E2E post below:

Refer: E2E post to configure Heap in ARM application binary by adding “–remove-section”

Example BIOS configuration:

var heap1 = HeapMem.create();
heap1.size = 256 * 1024 * 1024;
heap1.sectionName = ".stack";
Memory.defaultHeapInstance = heap1;

Compiler Setting : –remove-section=.stack

Option 2 Configure Segment type to be “NO LOAD” in .cfg and use excludeSections

SYSBIOS Memory map configurations allows user to specify the section name, length and type. by configuring the section type to “NOLOAD” and using excludeSection option the heap memory can be eliminated from the final binary.

Example BIOS configuration:

Program.sectMap[".biosheap"] = new Program.SectionSpec();
Program.sectMap[".biosheap"].runSegment = "DDR2"
Program.sectMap[".biosheap"].type = "NOLOAD";

Program.sectionsExclude = ".biosheap"

Alternate approach using linker command file:

.ddr3Heap (NOLOAD):
  {
      *(.ddr3Heap)
  } > HOST_DDR3

Debugging application boot

Steps to debug application boot using Processor SDK RTOS bootloader are discussed in the article `Common steps to debug application boot <https://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Boot#Common_steps_to_debug_application_boot>`__

4.5.2. AM57x¶

Overview

The Secondary Bootloader (SBL) for AM57xx device initializes the execution environment for multi-core application and this can be used to demonstrate an out-of-box experience.The section covers additional details including execution sequence, tools and additional flashing instructions.

Bootloader Execution Sequence

• Power On Reset
• ROM Bootloader (RBL)
  • Software pre-programmed in ROM memory starts executing
  • Checks Sysboot pins and choose booting device
  • If no valid bootloader found on booting device, RBL checks for next booting device.
  • Platform configuration and initialization.
  • Configures DPLL and clock settings for MPU, and boot media like I2C, MMCSD, SD/MMC, SPI, QSPI, Ethernet etc for reliable boot.
  • The sequence depends on RBL execution flow and Sysboot pins.
  • RBL gets image size and load address by checking TI Image Header appended on bootloader binary(.bin). Check binary formats.
  • Loads the binary to internal memory at the Load address fetched from TI Image Header
  • Passes control to Secondary Bootloader(SBL)

• Secondary bootloader(SBL)
  • User level secondary bootloader(SBL) begins execution from internal memory by running basic initialization routines like setting up Stack, BSS and then jumps to main() to begin Board Initialization.
  • Board Initialization is done by a call to Board_init() API.For additional details refer Processor SDK Board Support.
  • It includes setting up PLLs, enabling clocks to all interfaces and modules, performing pinmux and setting up UART console.
  • Once Board Initialization is complete, it enables clocks to the slave cores like C66x/DSP, IPU, etc and brings them out of reset.
  • Parses Multicore Application image located in memory device and copies it to DDR memory based on load address for different sections.
  • Once copy is successful it transfers control to application.
• Application then starts executing from DDR.

Directory structure

Makefiles:

• PDK_INSTALL_PATH/tibootsblboard<EVAL_BOARD>build: Makefile for bootloader that provides list of source files and library and compiler options to create bootloader binary.

Source Files:

• PDK_INSTALL_PATH/tibootsblboard<EVAL_BOARD>: Source to SBL main function that consolidates all features
• PDK_INSTALL_PATH/tibootsblsoc: Source to SOC specific initialization used in the SBL.
• PDK_INSTALL_PATH/tibootsblsrc: Source to boot media specific initialization used in the SBL.

Tools and Binary Formats

This section lists out the various tools and scripts used by SBL for different boot modes and those required to create a bootable application image.

SBL/MLO image format:

Application image format:

A bootable application image can be created by using the Am57xImageGen script provided under tools folder as part of sbl. It can be located at <PDK_INSTALL_DIR>packagestibootsbltoolsscripts folder.

The Am57xImageGen script uses out2rprc and multicoreImageGen format conversion tools to create the final application image. Graphical view of the multicore application image is provided below:

The script creates the bootable image in 2 steps

Step 1: Conversion to RPRC format conversion

• Firstly, application executable is converted from ELF/COFF format (.out) to custom TI Rprc binary image using out2rprc tool. This tool strips out the initialized sections from the executable file (i.e. *.out) and places them in a compact format that the SBL can understand. The output (bin) file is typically much smaller than the original executable (out) file.
• The rprc files are intermediate files in a format that is consumed by MulticoreImageGen tool that generates the final binary.

RPRC File Header Format

RPRC Section Header Format

• RPRC files for each cores is combined into a single multicore bootable application image.

Multicore boot image format

Meta Header Start

Meta Header per Core

Core ID and Device ID for specific devices can be located in the file sbl_slave_core_boot.h in the boot/sbl/soc/<SOC_NAME> folder

Refer section App Image Creation for more details on usage of this script and application image creation.

Flashing Tools

Building the SBL

Pre-requisites to Building

• Set your environment using pdksetupenv.bat or pdksetupenv.sh. Refer to the Processor SDK RTOS Building page for information on setting up your build environment
• The SBL has following dependencies and will need the following libraries built
  • Board
  • UART
  • I2C
  • SPI
  • CSL
  • OSAL
  • MMCSD
  • PM

Compiling the SBL Components

To build the SBL components:

1. cd <PDK>/packages/ti/board/diag
2. make all BOARD=<BOARD_NAME> SOC=<SOC_NAME> BOOTMODE=<BOOTMEDIA>

• BOARD_NAME : idkAM572x, idkAM571x, evmAM572x, idkAM574x
• SOC_NAME : AM572x, AM571x, AM574x

This will make the SBL for a specific $BOARD and $BOOT_MEDIA. Output files will be located in: <PDK>/packages/ti/boot/sbl/binary/<BOARD>

Building SBL using CCS project

The SBL build in the Processor SDK RTOS is designed to be built using Makefile. Users can also choose to create a CCS project for the bootloader if they prefer the IDE environment by converting the make file based build to CCS project by linking the appropriate source files to the project and using the same compiler options.

Example: The wiki article “Creating_a_CCS_Project_for_SBL_on_AM572x_GP_EVM” demonstrates creation of SBL in CCS for AM572x GP EVM.

Boot Modes

This Release of SBL supports MMCSD and QSPI Boot modes. The different boot modes supported for all the boards is tabulated in the table below.

Booting Via SD Card

1. Preparing the SD card.
2. Booting the target.

Preparing the SD card

1. To boot the target the SD card should be bootable. Follow the steps at Creating bootable SD card in windows or Creating bootable SD card in Linux.
2. Delete the “MLO” and “app” in the bootable SD card which are created in the process of making the SD bootable.
3. Copy the sbl binary(MLO) to the SD card.
4. Copy the Application image(app) generated using the Script to the SD card.

Booting the target

1. Insert micro SD card into the SD card slot of the board.
2. Open a serial communication terminal like TeraTerm, MiniCom on host PC and connect to the UART console port
3. Do a power reset of the board to boot the appliation from the SD card.

Booting Via QSPI

Booting from QSPI flash involves two steps-

1. Flashing bootloader and app image to QSPI flash.
2. Booting the target.

Preparing Flash Device

Use the CCS based qspi_flash_writer.out utility provided in <TI_PDK_INSTALL_DIR>packagestibootsbltoolsflashwriterqspi<Board>’ to flash the SBL image at offset 0 and application image at offset 0x80000 to the QSPI device.

QSPI device Memory Map:

The images can be flashed into QSPI flash by following steps given below.

1. Copy QSPI mode SBL image TI_PDK_INSTALL_DIRpackagestibootsblbinary<BoardName>qspibinMLO and application image(app) generated using the Script into the SD card. Rename the bootloader file to ‘boot’ and application image to ‘app’ with no extensions.
2. Copy ‘config’ file into the SD card, the config file should contain names of the image to be flashed and the offset. A sample config file can be found at TI_PDK_INSTALL_DIRpackagestibootsbltoolsflashWriterqspiconfig. Do not change the name of the config file. NOTE: “config” file can be used without any modifications if bootloader and application images are renamed to “boot” and “app”. NOTE: Do not rename the bootloader to be copied to SD card as “MLO”, as MMCSD bootloader expects “MLO” and “app” to boot.
3. Now SD card contains 3 files 1)boot 2)app 3)config files. config file contains the address of boot image as 0x0 and app image as 0x80000. Insert it into the SD card slot.
4. Connect the board with CCS and and load the prebuilt qspi flash writer application from $(TI_PDK_INSTALL_DIR)packagestibootsbltoolsflashWriterqspibin<BoardName>\
5. Run the QSPI flash writer application. You will see the following logs on the EVM’s UART console.
6. After the images have been flashed to the QSPI device disconnect from CCS and do a power reset to boot from the QSPI memory.

PDK QSPI Flash Writer!!
Copying boot to QSPI Flash
Copying app to QSPI Flash
Changing read to quad mode
Read mode has been changed to Quad mode
SUCCESS!!!
Flashing completed

Test Application

Master application sends wake-up message to the DSP slave cores & waits for acknowledgement message from the slave cores in an infinite loop.Each slave DSP core waits for wake-up message from the master core responds back with an acknowledgement message.

Application Image Creation

Application Image creation involves two steps.

1. Generating the .outs of applications for individual cores
2. Combining the .outs of individual cores to create a bootable multicore image

The steps to create the bootable image in Linux and Windows environment are listed below.

Linux Environment:

Command to build the test application.

Go to cd (TI_PDK_INSTALL_DIR)\packages\ti\boot\sbl

make example BOARD=<BOARD> SOC=<SOC> to build the application
make example_clean BOARD=<BOARD>

Example:

make example BOARD=idkAM572x SOC=AM572x

To create the final bootable application image use the AM57xImageGen script and follow these steps

1. Set the following environment variable in the shell.  BIN_PATH: Pointing to the path where the AppImage needs to be generated

Ex: export BIN_PATH=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary

2. Edit the script file to point to the application elf files by setting the input application variables.

export APP_MPU_CPU0=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/armv7/bin/sbl_app.out

export APP_DSP1=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/c66/dsp1/bin/sbl_app.xe66

export APP_DSP2=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/c66/dsp2/bin/sbl_app.xe663

export APP_IPU1_CPU0=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/m4/ipu1/bin/sbl_app.xem4

export APP_IPU1_CPU0=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/m4/ipu2/bin/sbl_app.xem4

3. If it is not required to load an application on specific core leave the variable blank.

4. Run the script file

5. An application image by name app is created in the path pointed by BIN_PATH variable

6. Copy the Bootlaoder image(MLO) and application(app) in the SD card to boot using MMCSD boot mode.

Windows environment:

Command to build the test application.

Go to cd (TI_PDK_INSTALL_DIR)\packages\ti\boot\sbl

gmake example BOARD=<BOARD> SOC=<SOC> to build the application
gmake example_clean BOARD=<BOARD>

Example:

gmake example BOARD=idkAM572x SOC=AM572x

To create the final bootable application image use the AM57xImageGen script and follow these steps

1. Set the following environment variable in windows command prompt

BIN_PATH: Pointing to the path where the AppImage needs to be generated

Ex:  set BIN_PATH=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary

2. Edit the batch file to point to the application elf files by setting the input application variables.

set App_MPU_CPU0=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\armv7\bin\sbl_app.out

set App_DSP1=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\c66\dsp1\bin\sbl_app.xe66

set App_DSP2=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\c66\dsp2\bin\sbl_app.xe66

set App_IPU1_CPU0=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\m4\ipu1\bin\sbl_app.xem4

set App_IPU2_CPU0=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\m4\ipu2\bin\sbl_app.xem4

3. If it is not required to load an application on specific core leave the variable blank.

4. Run the batch file

Setup Requirements

For information on board specific requirements like power supply, UART console port connections refer the Hardware User guide of the respective boards.

The configurations needed to setup UART console through a serial terminal application on host PC are listed in the next section.

UART Console Setup

PDK SBL prints messages on the UART Serial Console running on the host. Hence, a serial terminal application (like Tera Term/HyperTerminal/minicom) should be running on the host.

Loading the test application

Follow these steps to load the test application using a SD card on the target

copy the MLO to your SD card (located at %TI_PDK_INSTALL_DIR%packagestibootsblbinary[BOARD]mmcsd)

1. copy the example app located at path pointed to by BIN_PATH to your SD card
2. insert your SD card into your board and power on your board
3. open teraterm to connect to the board’s UART console
4. press the “Hard Reset” button on your board

On Successful bootup you should see the following logs on the UART console for a AM572x based board.

Application Integration

Memory Map

Table indicated below provides memory map details for SBL image in OCMC_RAM1.  For more details on pinmux and IO delay requirements refer this link Processor SDK Board Support

We recommend that users should refer to the linker command file and the map file for the boot loader to check for latest information on the memory utilization in the boot loader.

Location of linker command file: <PDK_INSTALL_PATH>packagestibootsblboard<BOARD>build

The SBL memory map is shown below

SBL Customization

Changing boot media offsets

The location at which SBL resides on the flash is predefined by the ROM bootloader spec and so these defaults can`t be changed. However the SBL is a user defined bootloader so many of the defaults can easily be modified to meet application requirements. For example the flash offset location from which the bootloader reads the application is configured in the source files located under PDK_INSTALL_PATHpackagestibootsblsrc<BOOT_MEDIA>

Examples of customization that can be changed:

• QSPI/SPI flash offsets: These offsets are configured in sbl_qspi.c and sbl_spi.c
• MMCSD: The name of the application is hard coded as app in function SBL_MMCBootImage in the sbl_mmcsd.c

The SBL for AM57xx devices uses LLD drivers to read and write from boot media supported. The SBL uses the default SOC configuration of the drivers and the speeds setup. For example, the SPI driver default SPI bitrate is 1 MHz (Refer PDK_INSTALL_PATHpackagestidrvspisrcSPI_drv.c) so if you wish to speed up boot you can update the SPI parameter in the SBL as shown below:

SPI_Params_init(&spiParams);
spiParams.bitRate = 24000000U;

The configuration of the driver is usually done in the boot/sbl/soc/<device>/sbl_soc.c file.

• For SD/MMC: You can configure higher speed and change bus width using MMCSD_v1_HwAttrs_s or MMCSD_v0_HwAttrs_s
• For QSPI: 2 pin and 4 pin mode, and input frequency is configured using QSPI_HwAttrs in the QSPI driver. Check driver for defaults.

Also, check to see if the CACHE and MMU settings for the ARM core are setup to enable fast boot.

Reducing size of SBL and application

Another way to optimize boot times is to reduce the size of the binary that needs to be loaded by the bootloader by building the app with optimization for code size using -Os (GNU GCC) and for -O<level> when using TI compilers.

Other than compiler based optimizations developers can actively shutdown non-essential modules and features to reduce code size. For example if UART logging is not required or DDR memory is not connected in the system, the initialization functions can be removed to reduce code size.

Usage Notes

• SBL AVS and ABB setup

AVS and ABB configuration is mandated for normal operation of AM57xx devices. All Processor SDK RTOS releases v3.3 and later contain SBL that sets up AVS and ABB configuration features using PM LLD APIs The complete details of PMIC configuration and AVS and ABB configuration required by the chip for different OPP has been implemented in the file:

PDK_INSTALL_PATHpackagestibootsblboardsrcsbl_avs_config.c If you are using the same PMIC as GP EVM or IDK platform then you can reuse the settings as is in SBL for your custom platform

• Configuring entry point for SBL

The two key files that help setup the entry point in the SBL build are “sbl/soc/<SOC_NAME>/sbl_init.S” and the linker command file “sbl/soc/<SOC_NAME>/linker.cmd”. The global symbol Entry is used to provide the entry point to the SBL. The Base address of the memory section SBL_MEM is then used by the tiimage and GP Header tool to provide RBL the guidance to find the entry point to pass control. After MLO is created check the TI image format file(MLO or _ti.bin) or the GP Header file to confirm that the entry point matches the location of Entry symbol in the sbl.map

Debugging application boot

Steps to debug application boot using Processor SDK RTOS bootloader are discussed in the article `Common steps to debug application boot <https://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Boot#Common_steps_to_debug_application_boot>`__

4.5.3. C66x¶

Overview

C66x SOCs use the Intermediate Boot-Loader (IBL) to initialize and setup the SOC for specific boot modes. The table below illustrates the supported bootmodes:

Note:

1. Support boot over I2C bus address 0x51
2. Support POST boot over I2C bus address 0x50
3. Only ELF and BBLOB images are supported for booting
4. IBL is using the first 128KB L2 local memory, any application booting from IBL should NOT use the first 128KB L2 memory, OR should only use the first 128KB L2 memory for uninitialized data section