4.6.3.1.1. Overview¶

Bootloader supports power-on-reset bootstraps for the board. It initializes board, loads application from the memory device to DDR and transfers control to application. Section provides additional details including flashing and booting instructions across different media.

4.6.3.1.2. Source Reference¶

< BASE_DIR = PDK_INSTALL_DIR\packages\ti\starterware>

4.6.3.1.3. 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:

4.6.3.1.4. Tools and Binary formats¶

TI Boot image

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

gcc tiimage.c –o tiimage.out

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

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

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

4.6.3.1.5. Boot Modes supported¶

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

4.6.3.1.6. 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.

4.6.3.1.7. Boot Mode settings¶

Boot mode settings for all supported AM335x and AM437x boards are here

4.6.3.1.8. Boot Modes¶

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

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.

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

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

Enter the File Name

Enter the Offset in bytes (in HEX)

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.

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

Enter image file path

Enter offset (in hex):

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

Application is successfully flashed
NAND flashing successful!

   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...

4.6.3.1.9. Test Application¶

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

4.6.3.1.10. 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

4.6.3.1.11. Debugging application boot¶

Steps to debug application boot using Processor SDK RTOS bootloader are discussed in the article `Common steps to debug application boot <index_Foundational_Components.html#common-steps-to-debug-application-boot>`__

4.6.3.2.1. 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.

4.6.3.2.2. 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.

4.6.3.2.3. Directory structure¶

Makefiles:

• PDK_INSTALL_PATH/ti/boot/sbl/board/<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/ti/boot/sbl/board/<EVAL_BOARD>: Source to SBL main function that consolidates all features
• PDK_INSTALL_PATH/ti/boot/sbl/soc: Source to SOC specific initialization used in the SBL.
• PDK_INSTALL_PATH/ti/boot/sbl/src: Source to boot media specific initialization used in the SBL.

4.6.3.2.4. 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: To generate the MLO, SBL uses tiImageGen tool to prepend the sbl.bin image with the TI header information. The image format has been described in detail in the Image Format Section of theAM57xx Technical Reference manual

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>/packages/ti/boot/sbl/tools/scripts 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

Step 2: Multicore Image file generation

• 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

SBL provides a CCS based qspi flash writer utility to flash image and multicore AppImage from a SD card to onboard QSPI device. It is located at <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/qspi

4.6.3.2.5. 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>

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.

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

4.6.3.2.6. Test Application¶

SBL provides a test application to demonstrate booting of multicore application image on A15 and DSP cores.The multicore sample application uses mailbox for inter-processor communication. It is used to validate the multi-core boot-up use case.

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.

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>

make example BOARD=idkAM572x SOC=AM572x

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

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

4.6.3.2.6.3. 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.

App_MPU_CPU0: Point to the path where the application .out for A15 MPU is located App_DSP1: Point to the path where the dsp core 1 application is located App_DSP2: Point to the path where the dsp core 2 application is located

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 AM57xImageGen found under the path $(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/tools/scripts

5. Follow the steps 4 to 6 listed above for Linux environment. | 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.

4.6.3.2.6.3.1. 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.

The host serial port must be configured at 115200 baud, no parity, 1 stop bit and no flow control. Please ensure that the local echo setting for the terminal is turned off.

4.6.3.2.6.3.2. 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.

Note

MPU Core 0 example does a sequential check of mailbox messages sent from the other cores. On rare occasions, the check happens before the message is sent - the “<core> boot-up Successful” message might not be displayed even though the core(s) were booted successfully.

4.6.3.2.7. Application Integration¶

4.6.3.2.7.1. 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

Note

• After the application boots and is running on the SOC, it is free to use the SBL_MEM region.
• The pinmux data from the board library and MMU Table are part of the SBL_MEM region indicated in the figure above. If pinmux data needs to be placed at a specific location then users can update the SBL linker command file to add the BOARD_IO_DELAY_CODE and BOARD_IO_DELAY_DATA as described in Application Integration of board library for AM5x

4.6.3.2.8. SBL Customization¶

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

4.6.3.2.9. Usage Notes¶

4.6.3.3.1. Overview¶

The Secondary Bootloader (SBL) for AM65xx device initializes the execution environment for multi-core application and this can be used to demonstrate a real world product experience.The section covers additional details including execution sequence, tools and additional flashing instructions.

The SBL is essentially a baremetal application, and it uses many components from the Processor SDK

• <PDK>/packages/ti/build : For build infrastructure
• <PDK>/packages/ti/csl : For initialization and SoC addresses
• <PDK>/packages/ti/board : For board and usecase specific initialization
• <PDK>/packages/ti/drv/spi : For reading applications from OSPI flashes
• <PDK>/packages/ti/drv/udma : For reading data from boot media using DMA
• <PDK>/packages/ti/drv/mmcsd : For reading applications from MMC/SD/eMMC
• <PDK>/packages/ti/fs/fatfs : For reading files from MMC/SD/eMMC
• <PDK>/packages/ti/drv/sciclient : For communicating with DMSC sub-system
• <PDK>/packages/ti/drv/uart : For log messages
• <PDK>/packages/ti/osal : Primitives required by ti/drv components

Bootloader Execution Sequence

• Power On Reset
• ROM Bootloader (RBL)
  • Software pre-programmed in AM65xx ROM memory starts executing
  • The RBL performs platform configuration and initialization.
  • It then checks sysboot pins and chooses booting device
  • The RBL then configures DPLL and clock settings for MPU, and boot media like eMMC, SD/MMC, OSPI, UART, PCIe, Ethernet etc for reliable boot.
  • If no valid bootloader found on booting device, the RBL checks for next booting device, based on sysboot pins
  • The gets image size and load address by checking the X.509 certificate that is part of the bootloader image.
  • The RBL then verifies, optionally decrypts and loads the binary to internal memory at the Load address fetched from X.509 certificate.
  • Finally it passes control to Secondary Bootloader(SBL) running on the R5.
• Secondary bootloader(SBL)
  • User level secondary bootloader(SBL) begins execution from internal memory. It enables ATCM, starts PMU timers for profiling, initializes the MCU, and sets up the stack, heap and globals. It then jumps to main().
  • Board Initialization is done by calls to Board_init() API.For additional details refer Processor SDK Board Support.
  • First the Pin MUX and UART console are setup by a calls to Board_init(). Then the system firmware (SYSFW) is loaded from the boot media into the DMSC subsystem.
  • Once the SYSFW is up and running, the rest of the initialization can be done.
  • This includes optionally using Board_init() to configure PLLs, LPSCs and DDR.
  • The SBL then parses application image(s) for each of the core(s) from boot media and loads it to memory.
  • Once the application is loaded, the SBL communicates with the system firmware to setup the clocks for the core and release it from reset.
  • The core then starts executing from application entry point.

4.6.3.3.2. Block Diagram¶

4.6.3.3.3. Memory Map¶

4.6.3.3.4. Directory structure¶

sbl
│
├── board
│   └── k3
│       └── sbl_main.c                                      <= define main() for SBL, board specific init
│
├── build
│   ├── makefile                                            <= makefile for the SBL component
│   ├── sbl_am65xx.sh                                       <= For legacy, called by Yocto build
│   ├── sbl_boot_test.mk                                    <= Builds SBL single core tests
│   ├── sbl_smp_test.mk                                     <= Builds example app for using SBL lib
│   ├── sbl_mcu0_boot_perf_test.mk                          <= Builds example app for SBL performance tuning
│   ├── sbl_img.mk                                          <= builds SBL image that is loaded and executed by ROM code
│   ├── sbl_lib.mk                                          <= Builds sbl library that other apps can link into
│   ├── sbl_multicore_smp.mk                                <= Builds multi-core image from SBL lib eg. test to demonstrate symmetric multiprocessor boot (SMP)
│   └── sbl_multicore_amp.mk                                <= Builds multi-core image from single core tests to demonstrate asymmetric multiprocessor boot (AMP)
│
├── example
│   └── k3MulticoreApp
│       ├── binary
│       │   └── am65xx
│       │       └── sbl_baremetal_*.appimage                <= SBL loadable board specific sample apps for testing SBL boot flow
│       ├── mcuAmplinker.lds                                <= Linker comamnd file when TI CGT is used for Asym. Multiproc. boot
│       ├── mpuAmplinker.lds                                <= GCC linker command file (for Cortex Axx cores) for Asym. Multiproc. boot
│       ├── mcuBootPerfLinker.lds                           <= TI CGT Linker comamnd file for SBL performance tuning example.
│       ├── mcuLockStepLinker.lds                           <= Linker comamnd file when TI CGT is used for R5 lock-step boot
│       ├── mpuSmplinker.lds                                <= GCC linker command file (for Cortex Axx cores) for SMP boot
│       ├── sbl_amp_multicore.c                             <= Simple SBL test that displays UART message
│       ├── sbl_amp_multicore_sections.h                    <= Allows same source to be loaded to different sections for different cores.
│       ├── sbl_mcu_0_boot_perf_benchmark.c                 <= SBL Test to tune boot performance.
│       ├── sbl_multicore_a53.asm                           <= Test case entry point  for Cortex-Axx cores
│       ├── sbl_multicore_r5.asm                            <= Test case entry point for Cortex-R5 cores
│       ├── sbl_multicore_r5_sections.inc                   <= Allows same source to be loaded to different sections for different MCUs.
│       ├── sbl_printf.c                                    <= Lightweight UART printf function for SBL testing
│       ├── sbl_smp_multicore.c                             <= Simple SBL SMP test that uses SBL lib to reset MPUs
│       └── sbl_smp_r5.asm                                  <= Provides dummy override function for __mpu_init for SMP testcase.
│
├── binary                                                  <= ROM bootable SBL images for each board/boot media
│   ├── am65xx_evm
│   │   ├── mmcsd
│   │   │   └── bin
│   │   │       └── sbl_mmcsd_img_mcu1_0_release.tiimage
│   │   └── ospi
│   │       └── bin
│   │           └── sbl_ospi_img_mcu1_0_release.tiimage
│   └── am65xx_idk
│       ├── mmcsd
│       │   └── bin
│       │       └── sbl_mmcsd_img_mcu1_0_release.tiimage
│       └── ospi
│           └── bin
│               └── sbl_ospi_img_mcu1_0_release.tiimage
│
├── lib                                                     <= SBL lib for each boot media/board supported
│   ├── mmcsd
│   │   ├── am65xx_evm
│   │   │   └── r5f
│   │   │       └── release
│   │   │           └── sbl_lib_mmcsd.aer5f
│   │   └── am65xx_idk
│   │       └── r5f
│   │           └── release
│   │               └── sbl_lib_mmcsd.aer5f
│   │
│   └── ospi
│       ├── am65xx_evm
│       │   └── r5f
│       │       └── release
│       │           └── sbl_lib_ospi.aer5f
│       └── am65xx_idk
│           └── r5f
│               └── release
│                   └── sbl_lib_ospi.aer5f
│
├── soc                                                     <= SOC specific SBL code
│   └── k3
│       ├── linker.cmd                                      <= Linker file used for generating ROM loadable SBL image.
│       ├── sbl_err_trap.h                                  <= Error loops for SBL
│       ├── sbl_init.asm                                    <= SBL Entry point
│       ├── sbl_misc.asm                                    <= SBL Assembly utility functions
│       ├── sbl_log.h                                       <= SBL logging framework
│       ├── sbl_sci_client.c                                <= Calls SYSFW on DMSC
│       ├── sbl_sci_client.h
│       ├── sbl_slave_core_boot.c                           <= Code that contains the sequence to release a core from reset
│       ├── sbl_slave_core_boot.h
│       ├── sbl_soc.c                                       <= Cache Ops, PMU init etc..
│       └── sbl_profile.h                                   <= SBL profiling framework
│
├── src                                                     <= Common drivers used across SOCs
│   ├── mmcsd
│   ├── ospi
│   ├── qspi
│   ├── rprc                                                <= RPRC image parser used by SBL
│   └── spi
│
└── tools
    ├── btoccs
    ├── byteswap
    ├── ccsutil
    ├── flashWriter                                         <= Unused for AM65xx. AM65xx uses Uniflash to program flashes.
    ├── multicoreImageGen                                   <= Stitches multiple RPRC images for different cores into a single image
    ├── omapl13x_boot_utils                                 <= Unused for AM65xx
    ├── omapl13x_sd_card_format                             <= Unused for AM65xx
    ├── out2rprc                                            <= Converts .out into .rprc files, so that SBL can load non-continuous memory sections
    ├── scripts                                             <= Scripts used by .out  generated by CCS projects into SBL loadable images
    │   ├── AM65xxImageGen.bat
    │   └── AM65xxImageGen.sh
    └── tiImageGen                                          <= Unused for AM65xx. Image generation is handled by PDK build framework (<prsdk_install_path>/pdk_*/packages/ti/build/)

4.6.3.3.5. Image Formats¶

SBL format:

To generate the a bootable image, the SBL build uses x509CertificateGen script to sign the sbl binary with so that the ROM Boot Loader (RBL) can parse it. The image format expected by the RBL has been described in detail in the Image Format Section of the AM65xx Technical Reference Manual

Application image format:

Two utilities - out2rprc and multicoreImageGen are used to convert an application elf image(s) into an image loadable by the SBL. The structure of a multicore application image is provided below:

RPRC File Header Format

RPRC Section Header Format

Multicore boot image format

Meta Header Start

Meta Header per Core

4.6.3.3.6. Building the SBL and its components¶

Pre-requisites to Building

• Set your environment using pdksetupenv.bat or pdksetupenv.sh. Refer to Processor SDK RTOS Building for information on setting up your build environment

openssl version

Compiling the SBL

To build all the SBL components:

cd <PDK>/packages/ti/boot/sbl/build
gmake BOOTMODE=<BOOTMEDIA> clean all (for windows)
make BOOTMODE=<BOOTMEDIA> clean all  (for Linux)
BOOTMEDIA : mmcsd, ospi

• SBL image files are be located at: <PDK>/packages/ti/boot/sbl/binary/
• SBL examples are located at <PDK>/packages/ti/boot/sbl/examples/k3MulticoreApp/binary
• SBL lib are located at <PDK>/packages/ti/boot/sbl/lib/

Compile time options for the SBL

The SBL supports several compile time options to tweak the SBL to satisfy requirements of ease of use, boot time and size. These can be enabled or disabled by editing sbl/sbl_component.mk

• SBL_LOG_LEVEL : Controls amount of SBL logs on the MCU UART. Varies from 0 (no logs) to 3 (all logs)
• SBL_DISPLAY_PROFILE_INFO : At the end of the boot process, displays a log of timestamps at which different SBL profile points are hit. This is useful to see how much time the SBL spends in different functions.
• SBL_ENABLE_PLL : Dials up all the PLLs calling Board_init(). Makes it easier for applications as they no longer have to initialize the PLLs. However, enabling this significantly increases boot time and power consumption. Requires system firmware to be loaded.
• SBL_ENABLE_CLOCKS : Enables all the module clocks by calling Board_init(). Makes it easier for applications as they no longer have to enable clocks.
• SBL_ENABLE_DDR : Initializes the DDR. At the cost of boot time, this enables applications to run from and use DDR. SBL_ENABLE_CLOCKS and SBL_ENABLE_PLL must also be enabed for this to work. Enabling this option increases the boot time.
• SBL_SKIP_MCU_RESET : Jumps to the MCU0 application entry point without resetting the core. Enables faster boot time. Will change the MCU’s mode (lock-step/split). Application also inherits the MCU state as the SBL left it in.

Compiling apps that can be loaded by SBL:

Memory Map Considerations

Applications that the SBL loads must comply with the am655x-sbl-memory-usage. In the application’s linker command file, care must be taken to not use the first 0x100 bytes of either MCU’s ATCM memory and SBL reserved memory from 0x41C00100 to 0x41C28000.

Converting ELF executables to SBL loadable image

Depending on the usecase, an ELF application executable can be converted into an image that can be loaded by SBL in many ways.

• Using CCS: Any project created using the pdkProjectCreate scripts will automatically generate a SBL loadable app, as part of a post-build step.
• Using makefiles: Add the following lines to the component’s .mk file

app_name_SBL_APPIMAGEGEN = yes
export app_name_SBL_APPIMAGEGEN

• Existing ELF executable: By calling the AM65xxImageGen script.

Linux Syntax: AM65xxImageGen.sh <CoreID> <.out>

Example:
cd  <prsdk_install_path>/pdk_*/packages/ti/boot/sbl/example/ampMulticoreApp/binary/am65xx_evm/
AM65xxImageGen.sh 4 sbl_baremetal_boot_test_am65xx_evm_mcu1_0TestApp_release.xer5f

Windows Syntax: AM65xxImageGen.bat "<CoreID> <.out>"

Example:
cd  <prsdk_install_path>\pdk_*\packages\ti\boot\sbl\example\ampMulticoreApp\binary\am65xx_evm\
AM65xxImageGen.bat "4 sbl_baremetal_boot_test_am65xx_evm_mcu1_0TestApp_release.xer5f"

• Multicore Images: Multicore images, as the name suggests, allows the SBL to load applications for multiple cores from a single image. Creating such images invloves three steps.

1. Generate the ELF application executables for individual cores
2. Convert the ELF executables into intermediate .rprc images
3. Combine the .rprc images of individual cores to create a single multicore image

To covert any .out into the intermediate .rprc format, execute the following commands

For Linux:
mono <PDK>/packages/ti/boot/sbl/tools/out2rprc/bin/out2rprc.exe input.out output.rprc

For Windows:
<PDK>\packages\ti\boot\sbl\tools\out2rprc\bin\out2rprc.exe input.out output.rprc

To stitch multiple .rprc images into a multicore image, execute the following command

For Linux:
<PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen LE 55 output.appimage  <core_id_1> core_1.rprc <core_id_2> core_2.rprc

For Windows:
<PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen.exe LE 55 output.appimage  <core_id_1> core_1.rprc <core_id_2> core_2.rprc

4.6.3.3.7. Testing the SBL¶

SBL provides a test applications to demonstrate booting the A53 and R5 cores in both symmetric/lock step & asymmetric/split-mode.The multicore sample application prints a message on the UART for each core. The functionality the different tests exercises are listed below.

• sbl_*_boot_test_*_all_coresTestApp_release: A single multicore boot test case that boots each core in the SoC with a separate app. Also tests DDR loading
• sbl_*_boot_test_*_xxxx_xTestApp_release.appimage: A simple testcase for booting core xxxx_x (eg. MCU1_0, MPU2_0 etc.)
• sbl_*_smp_test_*_all_coresTestApp_release.appimage: A single SMP boot test case that boots MCUs in lock step. The MCU app then uses the SBL lib to boot all the MPUs in SMP mode, ie, all the MPUs execute a single binary from the same address.
• sbl_baremetal_boot_perf_*_mcu1_0TestApp_release.appimage: A single MCU1_0 test case that can be used to measure the effect of enabling/disabling the perf. tuning knobs in the SBL for OSPI boot. The size of the test case can be easily modified by changing the value of SIZE_OF_PAD in sbl/example/k3MulticoreApp/ sbl_mcu_0_boot_perf_benchmark.c to profile for different app image sizes.

The test log for sbl_*_boot_test_*_all_coresTestApp_release is

SYSFW  ver 18.7.1-v2018.07a (Curious Crow) running
SBL Revision: 01.00.09.01 (Aug 29 2018 - 18:29:57)
MPU1_0 running
MPU1_1 running
MPU2_0 running
MPU2_1 running
MCU1_1 running
MCU1_0 running
MCU1_0 reports: All tests have passed

The test log for sbl_*_smp_test_*_all_coresTestApp_release.appimage is

SYSFW  ver 18.7.1-v2018.07a (Curious Crow) running
SBL Revision: 01.00.09.01 (Sep  7 2018 - 13:04:04)
Initlialzing DDR @333000000Hz..done
MPU AMP boot test
All MPUs will boot from 0x801007a0
Resetting all MPUs now...
No of MPU core(s) running: 1
No of MPU core(s) running: 2
No of MPU core(s) running: 3
No of MPU core(s) running: 4
All tests have passed

The test log for sbl_baremetal_boot_perf_*_mcu1_0TestApp_release.appimage, when the best boot time is reached is

Time elapsed since start of SBL: 39692us
fxn:boot_perf_test_main cycles: 15877177
MCU CLK @ 400000000Hz, cycles/usec = 400
Boot time is now optimised....
All tests have passed

4.6.3.3.8. Boot Modes¶

The SBL supports MMCSD and OSPI Boot modes. The different boot modes supported for all the am65xx boards is tabulated below.

Booting Via SD Card

1. Preparing the SD card.
2. Booting the testcase from SD card.

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. To update the SBL with a newer version, copy the sbl image (sbl_mmcsd_img_mcu1_0_release.tiimage) to the SD card. Rename it to tiboot3.bin
3. To update the SYSFW with a newer version, copy the system firmware image (sysfw.bin) to the SD card.
4. Copy the generated application image(*.appimage) to the SD card. Rename it to app

Booting the testcase from SD card

1. Insert SD card into the SD card slot of the board.
2. Refer Boot Modes section in the AM6x EVM Hardware Users Guide to setup EVM to boot from MMCSD.
3. Open a serial communication terminal like TeraTerm, MiniCom on host PC and connect to the MCU UART console port
4. Power cycle the board to boot the appliation from the SD card.
5. The test logs will be displayed on the MCU UART

Booting Via OSPI flash

1. Programming the OSPI flash
2. Booting the testcase from OSPI flash

Booting the testcase from OSPI flash

1. Refer Boot Modes section in the AM6x EVM Hardware Users Guide to setup EVM to boot from OSPI.
2. Open a serial communication terminal like TeraTerm, MiniCom on host PC and connect to the MCU UART console port
3. Power cycle the board to boot the appliation from the OSPI flash.
4. The test logs will be displayed on the MCU UART

4.6.3.3.9. EVM Setup for testing SBL¶

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.

• The host serial port must be configured at 115200 baud, no parity, 1 stop bit and no flow control.
• Please ensure that the local echo setting for the terminal is turned off.
• All SBL prints are routed to the MCU UART
• To verify setup is correct, setup the EVM to boot from UART as the Primary Boot Device(refer AM6x EVM Hardware Users Guide. Power cycle the EVM, and look for the string CCCCCCC on the UART.

4.6.3.4.1. 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:

Please refer to the boot mode dip switch settings for different boot modes on TMDSEVM6678L_EVM, and TMDSEVM6657L_EVM that IBL supports.

4.6.3.4.2. Flashing the Bootloader¶

IBL needs to be flashed into EEPROM address 0x51.

Refer to Processor SDK RTOS Flashing Bootable Images] for instructions on using the script, program_evm.js, to automatically flash your device.

4.6.3.4.3. Bootloader Execution Sequence¶

IBL is flashed into I2C EEPROM bus address 0x51. IBL provides a workaround for the PLL lockup issue (please refer to C6678 errata document, February 2011, advisory 8 for details on the PLL lockup issue). For ROM boot modes (EMAC,SRIO,PCIe,Hyperlink etc) and I2C boot mode with bus address 0x50, DSP will initially boot from I2C EEPROM bus address 0x51 which does the PLL reset workaround, updates the DEVSTAT for appropriate values based on the DIP switch settings (SW3 through SW6 settings) and then re enters the ROM to accomplish the desired boot mode. Please note that the re entry is done for all boot modes except for PCIe boot mode and I2C boot mode with bus address 0x51.

Below are the steps done in the IBL:

1. FPGA samples the bootmode pins
2. FPGA forces the DSP to boot via I2C bus address 0x51
3. PLL is initialized correctly by the IBL on the I2C.
4. IBL reads the sampled bootmode from an FPGA register.
5. IBL checks the bootmode, if it is not I2C boot or it is I2C boot but with bus address 0x50, IBL writes bootmode into the DEVSTAT register
6. IBL then checks if the bootmode is PCIE boot or not. If it is, it executes some PCIE workaround to configure the PCIE registers (mainly to accept spread spectrum clock) and stays inside IBL waiting for PCIe boot.
7. If it is not PCIE boot mode, IBL writes the Boot ROM entry address into the DSP Program Counter, DSP executes the desired internal ROM boot mode or boot from I2C bus address 0x50 as normal.

4.6.3.4.4. Compilation¶

The recommended rule-of-thumb to compiling projects in the Processor SDK RTOS package is to use the makefiles provided. The makefiles are usable after setting up your shell/terminal/command prompt environment with the setupenv.bat or setupenv.sh script located in

[SDK Install Path]/processor_sdk_rtos_<platform>_<version>

Refer to Processor SDK RTOS Building the SDK guide on how to setup your environment for building within any of the Processor SDK RTOS packages.

The IBL package can be found in:

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl

To build:

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make
make <IBL_BINARY_NAME> ENDIAN=<BINARY_ENDIANNESS> I2C_BUS_ADDR=0x51

<IBL_BINARY_NAME> can be of values: evm_c6657_i2c or evm_c6678_i2c. (For C6657 or C6678 platforms, respectively)

<BINARY_ENDIANNESS> can be of values: little or big

I2C_BUS_ADDR specifies the I2C bus address to use, and has to be 0x51 for C66x SOCs to access the EEPROM.

The resulting output will be in [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make/bin directory.

4.6.3.4.5. Flash Writers¶

There are three types of flash memory provided with the C66x SOCs: EEPROM, NOR, and NAND. Each of these flash memory can hold bootable application binaries. As such, respective flash writers are provided in:

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer/eeprom/<platform>/build
make all

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nor/<platform>/build
make all

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nand/<platform>/build
make all

4.6.3.4.6. Boot Modes¶

4.6.3.4.6.1. NAND Boot¶

NAND boot is a multi-stage process which is designed to boot an application from NAND flash after reset. Figure below illustrates the elements of the NAND boot process.

On reset the DSP starts execution with the bootrom which transfers execution to the secondary bootloader from EEPROM using the I2C slave bus address 0x51. The secondary bootloader loads the application program from NAND flash then transfers control to the application. To execute the NAND bootloader you must ensure the DIP switches for your platform are properly configured for I2C Master Boot and address 0x51, AND the boot parameter index dip switch should be set to 2 or 3.

NAND boot supports multiple images booting. Depending on the boot parameter index dip switch, maximum 2 boot images can be supported. By default NAND boot only supports a BBLOB image format, if the customer wants to boot an ELF image,  the IBL configuration table needs to be modified and re-programmed to EEPROM.

4.6.3.4.6.2. NOR Boot¶

NOR boot is a multi-stage process which is designed to boot an application from NOR flash after reset. Figure below illustrates the elements of the NOR boot process.

On reset the DSP starts execution with the bootrom which transfers execution to the secondary bootloader from EEPROM using the I2C slave address 0x51. The secondary bootloader loads the application program from NOR flash then transfers control to the application. To execute the NOR bootloader you must ensure the DIP switches for your platform are properly configured for I2C Master Boot and address 0x51, AND the boot parameter index switch should be set to 0 or 1.

NOR boot supports multiple images booting. Depending on the boot parameter index dip switch, maximum 2 boot images can be supported.

4.6.3.4.6.3. TFTP Boot¶

EMAC boot is a multi-stage process which is designed to boot an application from TFTP server after reset. Figure below illustrates the elements of the EMAC boot process.

On reset the DSP starts execution with the bootrom which transfers execution to the secondary bootloader from EEPROM using the I2C slave address 0x51. The secondary bootloader loads the application program from a remote TFTP server then transfers control to the application. To execute the EMAC bootloader you must ensure the DIP switches for your platform are properly configured for I2C Master Boot and address 0x51, AND the boot parameter index switch should be set to 4. By default EMAC boot only supports a BBLOB image format, if the customer wants to boot an ELF image, the IBL configuration table needs to be modified and re-programmed to EEPROM.

4.6.3.4.6.3.1. Updating the IBL Ethernet Configurations¶

There are two ways to update the IBL ethernet configurations for ethernet boot.

Using CCS

1. Turn on and connect to your EVM with the appropriate Target Configuration file.
2. Connect to Core 0.
3. Go to Run -> Load Program and select i2cparam_0x51_c667#_le_0x500.out located in [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make/bin
4. Go to Tools -> GEL Files and then right click on GEL Files window and Load the i2cConfig.gel GEL file, located in [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make/bin
5. Run the program. The following message will be printed on the CCS console: Run the GEL for the SOC to be configured, press return to program the I2C. DO NOT PRESS ENTER UNTIL STEP 6 IS DONE
6. Run the GEL script”Scripts -> EVM c6678 IBL” -> setConfig_c6678_main.
7. Now press “Enter” in the CCS console window, and the program will write the boot parameter table to the EEPROM. On success the message “I2c table write complete” will be printed on the CCS console.

Please note that the i2cConfig.gel file can be modified via a text editor before loading and running the script in CCS. Please note that this gel file contains configuration settings for multiple SOCs and multiple boot modes.

Using iblConfig Utility Program

The second way to update the IBL ethernet configurations is to use iblConfig.out. This utility program is located under:

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/util/iblConfig/build

In command line, use “make” with the given Makefile to generate iblConfig.out and input.txt. Please be sure to fill in the parameters for input.txt before running iblConfig.out; below is an example of input.txt:

file_name = ibl.bin
SOC = 6
offset = 0x500
ethBoot-doBootp = TRUE
ethBoot-bootFormat = ibl_BOOT_FORMAT_ELF
ethBoot-ipAddr = 192.168.1.3
ethBoot-serverIp = 192.168.1.2
ethBoot-gatewayIp = 192.168.1.1
ethBoot-netmask = 255.255.255.0
ethBoot-fileName =

The first 3 parameters must be filled in for iblConfig.out to work:

• file_name refers to the IBL binary file to update. This file must be in the same directory as iblConfig.out.
• SOC refers to the SOC being used. Please enter 6 for C6678, and 8 for C6657.
• offset refers to an offset space in the IBL. The value is 0x500 for C6678, and C6657

The ethernet parameters (the entries beginning with ethBoot) refer to specific ethernet configurations. If they are not specified, they will be defaulted to the values in the [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/util/iblConfig/src/SOC.h file. In the example above, the ethernet boot file name will be defaulted to c6678-le.bin when iblConfig.out is run.

After running iblConfig.out and updating the IBL binary, you must flash the modified IBL binary to your EVM. You can do this as part of program_evm (refer to Processor SDK Flashing Bootable Images) or you can flash it individually using eepromwriter (refer to “Flash Writers” section above).

Note

If you updated the IBL with iblConfig and flashed it with eepromwriter, you should NOT use i2cparam_0x51_c667#_le_0x500.out and iblConfig.gel - this would overwrite the changes you made to the IBL.

4.6.3.4.6.3.2. Compilation¶

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/i2c/tftp/<platform>/build
make all

4.6.3.4.6.3.3. Usage¶

After your IBL ethernet settings are configured correctly and flashed into EEPROM memory, follow these steps to continue the TFTP booting process:

1. Start a TFTP server on your local PC. Your local PC will be the one sending the image to be booted, so make sure your PC and EVM are connected to the same subnet via ethernet
2. Copy i2ctftpboot_<platform>.out (refer to compilation step above) to your base TFTP directory
3. Rename i2ctftpboot_<platform>.out to app.out
4. Set the IP address of the PC that is running the TFTP server to 192.168.2.101, since by default IBL will set the EVM IP address to 192.168.2.100 and the TFTP server IP address to 192.168.2.101
5. Set EVM to TFTP boot mode and power on the EVM

Your PC will send the application image to the EVM to boot. Open an UART terminal to view the output.

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post/<platform>/build
make all
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post/<platform>/bin
./post_romparse.sh

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writers/eeprom/<SOC>/bin

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/ethernet/Utilities
make all
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/ethernet/simple
make all

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/ethernet/Utilities
pcsendpkt simple.eth <EVM IP ADDRESS>

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_ddrinit/<platform>/build
make all
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_ddrinit/<platform>/bin
./srioboot_ddrinit_elf2HBin.sh
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_helloworld/<platform>/build
make all
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_helloworld/<platform>/bin
./helloworld_elf2HBin.sh
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_example/<platform>/build
make all

[C66xx_0] SRIO Boot Host Example Version 01.00.00.01
[C66xx_0]
[C66xx_0] Transfer DDR init code via SRIO successfully
[C66xx_0] Transfer boot code via SRIO successfully

SRIO Boot Hello World Example Version 01.00.00.01
Booting Hello World image on Core 0 from SRIO ...
Booting Hello World image on Core 1 from Core 0 ...
Booting Hello World image on Core 2 from Core 0 ...
Booting Hello World image on Core 3 from Core 0 ...
Booting Hello World image on Core 4 from Core 0 ...
Booting Hello World image on Core 5 from Core 0 ...
Booting Hello World image on Core 6 from Core 0 ...
Booting Hello World image on Core 7 from Core 0 ...

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_ddrinit/<platform>/build
make all
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_helloworld/<platform>/build
make all

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_interrupt/<platform>/build
make all
cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_localreset/<platform>/build
make all

local-ubuntu:~$ lspci -n
00:00.0 0600: 8086:2774
00:1b.0 0403: 8086:27d8 (rev 01)
….
00:1f.3 0c05: 8086:27da (rev 01)
01:00.0 0480: 104c:b005 (rev 01)
03:00.0 0200: 14e4:1677 (rev 01)
Similarly, one can type “lspci”,
local-ubuntu:~$ lspci
….
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev
01)
01:00.0 Multimedia controller: Texas Instruments Device b005 (rev 01)
....

#define BIG_ENDIAN 0
#define HELLO_WORLD_DEMO 1
#define POST_DEMO 0
#define EDMA_INTC_DEMO 0
#define EVMC6678L 1
#define EVMC6670L 0

4.6.3.5.1. Overview¶

The Secondary Bootloader (SBL) for K2G does basic hardware initialization for the board to load and run applications.

4.6.3.5.2. Bootloader Execution Sequence¶

• Power On Reset occurs
• ROM Bootloader (RBL) executes. It checks for bootmode and attempts to load+run the SBL from that bootmode.
• SBL begins execution from internal memory (MSMC RAM)
  • Board Initialization is done by a call to Board_init() API. For additional details refer to Processor SDK Board Support.
  • SBL setup includes configuring Pinmux, enable peripheral clocks, set up PLLs, and configure EMIF for DDR.
• SBL finishes setup and looks for “app” to execute next. This user-modifiable application may reside in SD card or QSPI memory depending on the bootmode chosen.
• Once located, app will be loaded into memory and execution will be branched to the application’s entry address

4.6.3.5.3. Tools and Binary Formats¶

4.6.3.5.4. Making Bootable SBL image (MLO)¶

RBL loads and runs “MLO”, which is a .out executable formatted by TI tools. To make a .out, such as SBL, bootable by ROM, you must follow these steps:

1. armhex [.out file] [.rmd file]
   • .out file is the file you want to boot, such as sbl.out
   • .rmd file is an input file to specify sections information. An example can be found in: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/board/evmK2G/build/sbl.rmd
   • armhex is a tool in TI ARM CGT compiler. This generates a [hex file], name of which is specified by the .rmd file
2. b2ccs [hex file] [ccs file]
   • hex file is the output from the previous step
   • ccs file can be name of your choosing
3. ccsAddGphdr -infile [ccs file] -outfile [gphdr file] -headerEndian BE
   • gphdr file can be the name of your choosing
4. ccsAddGptlr -infile [gphdr file] -outfile [gptlr file]
   • gptlr file can be the name of your choosing
5. byteswapccs [gptlr file] [MLO ccs file]
   • MLO ccs file can be the name of your choosing
6. ccs2bin -swap [MLO ccs file] MLO
   • MLO will be created after this step

Armhex is part of TI ARM CGT, in <CCS_INSTALL_DIR>/tools/compiler/ti-cgt-arm_x.x.x/bin. The rest of the tools can be found in: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools

4.6.3.5.5. Making Loadable User Application image (app)¶

For converting the compiled .out files to a format loadable by TI’s Secondary Boot Loader (SBL), you must follow these two steps:

1. out2rprc.exe [.out file] [rprc output]
2. MulticoreImageGen.exe LE 55 [output name] 0 [rprc output]

Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can be located in the <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools folder. “rprc output” can be any spare name of your choosing. “output name” can also be any name of your choosing.

The ‘0’ used in step 2 refers to the Core ID to boot. By default, ‘0’ is MPU (Cortex A15) core 0. You can input a different value to boot to other cores. Valid values are:

If MPU SMP is chosen, the same boot image and entry will be used for all MPU cores. SBL can also parse multiple boot images that are concatenated together. Simply use MulticoreImageGen as such:

MulticoreImageGen.exe LE 55 [output name] [Core ID a] [rprc output a] [Core ID b] [rprc output b] [Core ID c] [rprc output c] ...

4.6.3.5.6. Boot Modes¶

This release of SBL supports MMCSD and QSPI boot modes.

4.6.3.5.6.1. MMCSD Boot Mode¶

4.6.3.5.6.1.1. Preparing the SD card¶

1. To boot the target, the SD card needs to be bootable. Follow the steps at Creating bootable SD card in windows or Creating bootable SD card in Linux.
2. Copy “MLO” and “app” to your SD card.
   • MLO is the SBL formatted by the aforementioned tools. A pre-built MLO can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/evmK2G/mmcsd/bin
   • app is the target application to be booted and also formatted by the aforementioned tools. (Note that the tools for making the bootable MLO and the loadable app are different).

4.6.3.5.6.1.2. Booting via SD Card¶

1. Insert micro SD card into the SD card slot of the board
2. Set the board to MMC/SD bootmode by configuring the DIP switches to ‘0111’. Verify the bootmode on the LCD display on your board
3. Open a serial communication terminal (such as TeraTerm, MiniCom, etc.) on host PC and connect to the UART console port
4. Power on the board

Below is an example of K2G SBL successfully booting the diagnostic application:

*** PDK QSPI Flash Writer ***
Copying 'boot' to local memory
Begin flashing 'boot' into QSPI
Finished flashing 'boot' with size 20010 at offset 0
Copying 'app' to local memory
Begin flashing 'app' into QSPI
Finished flashing 'app' with size 19398 at offset 80000
Flashing completed!

4.6.3.5.7. Memory Usage¶

SBL uses the last 0x40000 memory from MSMC RAM memory.

The SBL memory map is shown below:

4.6.3.6.1. Overview¶

K2H/K2E/K2L EVMs uses the Secondary Boot Loader (SBL) to configure board-related settings and execute a user application. The user application can be single core or multicore, and execute on either DSP cores or ARM cores. The only restriction is that the load sections must not overlap the memory space that SBL uses.

The K2H/K2E/K2L SBL supports ARM master boot using SPI NOR. Please refer to the boot mode dip switch settings in the respective EVM hardware page (link) to configure your EVM for NOR boot.

4.6.3.6.2. Flashing the Bootloader¶

SBL and user application needs to be flashed into SPI NOR.

Refer to Program EVM Guide for instructions on using the script, program_evm.js, to automatically flash your device.

4.6.3.6.3. Usage¶

1. Flash the bootloader and user application. This can be done automatically with default files by using program_evm.js
2. Set the EVM to ARM SPI boot mode
3. Connect UART serial debug cable from EVM to your computer. Open a terminal such as HyperTerminal or TeraTerm to see console output
4. Power on the EVM

4.6.3.6.4. Compilation¶

The recommended rule-of-thumb to compiling projects in the Processor SDK RTOS package is to use the makefiles provided. The makefiles are usable after setting up your shell/terminal/command prompt environment with the setupenv.bat or setupenv.sh script located in

[SDK Install Path]/processor_sdk_rtos_<platform>_<version>

Refer to Building RTOS SDK page on how to setup your environment for building within any of the Processor SDK RTOS packages.

The SBL package can be found in:

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl

To build:

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl
make all BOOTMODE=spi BOARD=<EVM> SOC=<platform>

<EVM> can be of values: evmK2H, evmK2E, evmK2L, or evmK2K

<platform> can be of values: K2H, K2E, K2L, or K2K

The resulting output will be in [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/binary/<platform>/spi/bin directory.

4.6.3.6.5. Making Loadable User Application image (app)¶

For converting the compiled .out files to a format loadable by TI’s Secondary Boot Loader (SBL), you must follow these two steps:

1. out2rprc.exe [.out file] [rprc output]
2. MulticoreImageGen.exe LE 55 [output name] 0 [rprc output]

Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can be located in the <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools folder. “rprc output” can be any spare name of your choosing. “output name” can also be any name of your choosing.

The ‘0’ used in step 2 refers to the Core ID to boot. By default, ‘0’ is MPU (Cortex A15) core 0. You can input a different value to boot to other cores. Valid values are:

If MPU SMP is chosen, the same boot image and entry will be used for all MPU cores. SBL can also parse multiple boot images that are concatenated together. Simply use MulticoreImageGen as such:

MulticoreImageGen.exe LE 55 [output name] [Core ID a] [rprc output a] [Core ID b] [rprc output b] [Core ID c] [rprc output c] ...

4.6.3.6.6. Flash Writers¶

cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/
make spi_flashwriter BOARD=<EVM> SOC=<platform>

[SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/<platform>

4.6.3.6.7. Boot Example¶

Below is an example output of evmK2H booting after having images flashed in by program_evm.js:

**** PDK SBL ****
Boot succesful!
Begin parsing user application
Jumping to user application...


TMDXEVM6636K2H POST Version 01.00.00.08
------------------------------------------
SOC Information

BMC Version: 0000
EFUSE MAC ID is: B4 99 4C B6 E2 5B
SA is enabled on this board.
PLL Reset Type Status Register: 0x00000001
Platform init return code: 0x00000000

Power On Self Test

POST running in progress ...
POST I2C EEPROM read test started!
POST I2C EEPROM read test passed!
POST SPI NOR read test started!
POST SPI NOR read test passed!
POST EMIF16 NAND read test started!
POST EMIF16 NAND read test passed!
POST external memory test started!
POST external memory test passed!
POST done successfully!

POST result: PASS

4.6.3.7.1. Overview¶

The Secondary Bootloader (SBL) for OMAPL137/OMAPL138/C6748 does basic hardware initialization for the board to load and run applications. Processor SDK boot support for each of these SoC is shown below

4.6.3.7.2. Bootloader Execution Sequence¶

• Power On Reset occurs
• ROM Bootloader (RBL) executes. It checks for bootmode and attempts to load+run the SBL from that bootmode.
• SBL begins execution from internal memory (Shared RAM)
  • Board Initialization is done by a call to Board_init() API. For additional details refer to Processor SDK Board Support.
  • SBL setup includes configuring Pinmux, enable peripheral clocks, set up PLLs, and configure EMIF for SDRAM/DDR.
• SBL finishes setup and looks for “app” to execute next. This user-modifiable application shall reside on the boot media.
• Once located, app will be loaded into memory and execution will be branched to the application’s entry address

4.6.3.7.3. Tools and Binary Formats¶

4.6.3.7.4. Boot Modes¶

This release of SBL supports SPI and MMCSD boot modes.

4.6.3.7.4.1. SPI Boot Mode¶

4.6.3.7.4.1.1. Preparing SPI Flash¶

MLO and app needs to be flashed into SPI memory so that they can be booted. MLO will reside at offset 0 and app will reside at offset 0x80000. SPI flash memory map:

Offset 0x0	MLO
Offset 0x80000	app

The images can be flashed into SPI flash by following steps given below:

1. Copy MLO and app to SPI flash writer binary folder - <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/evmOMAPL137. Make sure config file also present in the SPI flash writer binary folder.
   • MLO is the SBL formatted by the aforementioned tools. A pre-built MLO can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/evmOMAPL137/spi/bin
   • app is the target application to be booted and also formatted by the aforementioned tools. (Note that the tools for making the bootable MLO and the loadable app are different).
   • config helps specify the memory map. The default config file can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/evmOMAPL137. This config file may be altered to custom user settings if needed.
2. Connect the DB9 port of the EVM to host PC. Open serial communication applications like TeraTerm, MiniCom, etc and configure for ‘115200 8N1’.
3. Connect to the board with CCS. Launch target configuration and connect to the DSP C674x core. GEL file will run on-connect and do basic board-level initialization
4. Load the flash writer, spi_flash_writer.out, to the connected core
   • A pre-built spi_flash_writer.out can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/evmOMAPL137
5. Run the SPI flash writer application. You will see the following logs on the EVM’s UART console:

 *** PDK SPI Flash Writer ***
Opening SPI handle...
SPI handle opened!
Parsing config file and flashing content to SPI NOR...
Parsed config line, received parameters: filename = MLO, address = 0x0
       Size of MLO is 0xc81c
       Loading binary to memory ...
       Finished loading binary to memory!
       Flashed MLO to offset 0x0!
       Read flash memory at 0x0, checking flashed content...
       Verified flash data equal expected data!
Parsed config line, received parameters: filename = app, address = 0x80000
       Size of app is 0x16144
       Loading binary to memory ...
       Finished loading binary to memory!
       Flashed app to offset 0x80000!
       Read flash memory at 0x80000, checking flashed content...
       Verified flash data equal expected data!
Successfully flashed memory content!

Note

This application will flash the image at required offset without taking into consideration any overwriting to previously flashed image.

4.6.3.7.4.1.2. Booting via SPI¶

1. Set the OMAPL137 EVM to SPI bootmode by configuring the SW2 DIP switches 1-4 to ‘OFF ON OFF ON’. Other switch positions on SW2 are don’t care for SPI boot.
2. Connect the DB9 port of the EVM to host PC. Open serial communication applications like TeraTerm, MiniCom, etc and configure for ‘115200 8N1’
3. Power on the board

Below is an example of OMAPL137 SBL successfully booting the GPIO LED blink application

4.6.3.7.4.2. MMCSD Boot Mode¶

OMAPL138/C6848 RBL does not support reading the boot images as files from SD card. Secondary Boot loader image should be written to SD card as raw data. Special formatting is needed for SD card to create un-formatted area at the beginning of the card to store SBL.

4.6.3.7.4.2.1. Formatting the SD Card¶

SD card for booting OMAPL138/C6748 needs to be formatted from Linux PC due to un-formatted area requirement. Formatting the SD card from Windows PC is not supported in this release.

Connect the SD card to Linux PC and use below command to format the SD card

sudo sh create-sdcard-omapl13x.sh <Drive Name>

• <Drive Name> is name of the drive on which SD card is mounted. Be cautious while selecting the drive name. Running the script with system drive name will corrupt the file system.
• create-sdcard-omapl13x.sh script is available at <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/omapl13x_sd_card_format

4.6.3.7.4.2.2. Preparing the SD Card¶

For both OMAPL138 and C6748, MLO needs to be flashed onto SD card un-formatted area and app should be copied onto SD card.

MLO can be flashed into SD card un-formatted area by following steps given below:

1. Build the MMCSD flash writer using below commands
   • cd <PDK_INSTALL_DIR>/packages/ti/boot/sbl
   • gmake mmcsd_flashwriter SOC=OMAPL138 BOARD=lcdkOMAPL138 BOOTMODE=mmcsd
2. Copy ‘app’ to SD card and insert the card into MMCSD slot of the board
3. Copy MLO to MMCSD flash writer binary folder - <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/mmcsd/bin/lcdkOMAPL138. Make sure config file also present in the MMCSD flash writer binary folder.
   • MLO is the SBL formatted by the aforementioned tools. A pre-built MLO can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/lcdkOMAPL138/mmcsd/bin
   • app is the target application to be booted and also formatted by the aforementioned tools. (Note that the tools for making the bootable MLO and the loadable app are different).
   • config helps specify the memory map. The default config file can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/mmcsd/bin/lcdkOMAPL138. This config file may be altered to custom user settings if needed.
4. Connect the USB serial port of the EVM to host PC. Open serial communication applications like TeraTerm, MiniCom, etc and configure for ‘115200 8N1’.
5. Connect to the board with CCS. Launch target configuration, connect to ARM core first (not needed for C6748) and then connect to the DSP C674x core. GEL file will run on-connect and do basic board-level initialization
6. Load the flash writer, mmcsd_flash_writer.out, to the connected core
   • mmcsd_flash_writer.out can be found at: <PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/mmcsd/bin/lcdkOMAPL138
7. Run the MMCSD flash writer application. You will see the following logs on the EVM’s UART console:

Opening MMCSD handle...
MMCSD handle opened!
Parsing config file and flashing content to MMCSD...
Parsed config line, received parameters: filename = MLO, address = 0x200
       Size of MLO is 0xb9b8
       Loading binary to memory ...
       Finished loading binary to memory!
       Flashed MLO to offset 0x200!
       Read flash memory at 0x200, checking flashed content...
       Verified flash data equal expected data!
Successfully flashed memory content!

Procedure to flash the MLO described above is applicable to C6748 also. Use C6748 for OMAPL138 and lcdkC6748 for lcdkOMAPL138 in all the paths mentioned above.

MLO offset in config file is set to 200 by default which indicates that MLO will be written to second sector of the SD card. MLO offset can be any non-
zero value which is multiple of 512 and should be within first 2Mbytes of SD card memory. DO NOT set the MLO offset to '0' which will corrupt the file
system on the card.

Note

This application will flash the image at required offset without taking into consideration any overwriting to previously flashed image.

4.6.3.7.4.2.3. Booting via MMCSD¶

1. Set the OMAPL138/C6748 LCDK to MMCSD bootmode by configuring the SW1 DIP switches 1-4 to ‘OFF OFF OFF ON’. Other switch positions on SW1 are don’t care for MMCSD boot.
2. Connect the USB serial port of the EVM to host PC. Open serial communication applications like TeraTerm, MiniCom, etc and configure for ‘115200 8N1’
3. Power on the board

Below is an example of OMAPL138 SBL successfully booting the GPIO LED blink application

4.6.3.7.5. Memory Usage¶

SBL uses 0x20000 bytes from shared RAM (0x80000000 to 0x8001FFFF).

4.6.3.7.6. Additional Details¶

Use below commands to clean and build the SBL and associated tools.

Examples:
Cleaning & Building OMAPL137 SBL
gmake clean SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi
gmake SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi

Cleaning & Building OMAPL137 flash writer
gmake spi_flashwriter_clean SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi
gmake spi_flashwriter SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi

4.6.4.1.1. Hardware Debug Steps¶

4.6.4.1.2. Software Debug Steps¶

volatile int exitSpinLock = 0;
void Debug_spinLock(void)
{
    while (exitSpinLock == 0) { }
}

printf("Hit enter to continue:");
getchar();

4.6.5.1. Overview¶

UART AppLoader is a standalone application used to download application image over UART from the host PC. Host PC uses the serial console utility to transfer application image to apploader.

The Apploader application loads and executes the application binary to be tested, over UART on the target platform.

4.6.5.2. Supported Platforms¶

4.6.5.3. Apploader Load Address¶

4.6.5.4. Pre-Requisites¶

1. Download and install the Processor-SDK RTOS package. See the software product page for your device to get the latest version of this software:

• Processor SDK for AM335x

• Processor SDK for AM437x

• Processor SDK for AM57xx

• Processor SDK for AMIC110

• Processor SDK RTOS for C6747/OMAP-L17

• Processor SDK RTOS for C6748/OMAP-L138

• Processor SDK RTOS for K2G

  From the appropriate software product page, go to the download page by clicking “Get Software” for the RTOS package.

2. The Uart Apploader binaries are found under <pdk_install_path>/packages/ti/board/utils/uartAppLoader/bin/<board_name>/sd/apploader_Test

Serial Connection

Launch the serial console utility with the following configurations:

• Baud Rate: 115200
• Data : 8 bits
• Parity : None
• Stop : 1 bit
• Flow Control : None

4.6.5.5. AppLoader Usage¶

1. Set the sysboot pins to the relevant boot mode(SPI / MMCSD).
2. Make sure UART connection is established between Target platform and Host PC.
3. Power cycle the board.
4. Check the below output on the serial console. The application starts sending character ‘C’

**** PDK SBL ****
SBL Revision: 01.00.09.00 (May 10 2018 - 15:48:57)
Begin parsing user application

SD Boot - file open completed successfully
Jumping to user application...
********* PDK UART Apploader ********
version 0.1 (May 14 2018 - 21:40:11)

Please transfer file with XMODEM protocol...
CCCC

5. Now transfer the application binary to be tested over UART using serial console utility.

6. Upon success, the apploader loads and executes the application.
7. Following is the sample output (using UART Diagnostic application), on the serial console.

Xmodem received 46848 bytes

Copying application image from UART to RAM is done
Begin parsing user application
Jumping to user application...

*********************************************
*                 UART Test                 *
*********************************************

Testing UART print to console at 115.2k baud rate
Press 'y' to verify pass: y
Received: y

Test PASSED!

4.6.5.6. Rebuilding AppLoader¶

Apploader pre-built binaries are currently not available for OMAPL137/L138 platforms. Binaries needs to be manually built for these platforms.

Refer Rebuilding Board-utils section to build Apploader.

4.10.1.1. Introduction¶

CC-Link is an open-architecture network that was originally developed by the Mitsubishi Electric Corporation.It have been widely used in Process control, building automation etc. CLPA (CC-Link Partner Association) maintains the network technology and support many manufacturer supporting the application. CC-Link is available in multiple flavours i.e. CC-Link, CC-Link LT, CC-Link Safety, CC-Link IE (Industrial Ethernet) - Control and CC-Link IE Field. For further details regarding CCLink and its flavours please refer the CLPA website.[1]

4.10.1.2. Protocol Overview¶

The implementation will demonstrate how to create, run and test CC-Link IE Field Network Basic examples on TI platforms. The following shows the CC-Link IE Field Network Basic Overview:

• 1 Gbit/s Ethernet based network
• Ethernet physical layer (Cat5e cable & RJ45 connectors)
• 254 stations per network
• 100 meters between stations
• Completely deterministic without using switches

4.10.1.3. Code Organization¶

The Directory structure for CC-Link IE Field Network Basic source code and examples for both NIMU and NIMU_ICSS is shown in the following table.

4.10.1.4. Building the Examples¶

Use pdkProjectCreate.sh for Linux environment or pdkProjectCreate.bat for Windows. This can be found under the <PDK>/packages folder. The only modification to these scripts, if any, is to update the CCS_INSTALL_PATH variable to point to CCS location if its not in the c:ticcsv6 directory . Please refer to Rebuilding PDK for details of example project creation and how to run the example projects using CCS.

4.10.1.4.2. Running CC-Link IE Field Network Basic example¶

The following is the test setup needed to run the example for CCLink demonstration on TI platform. Connect the tested eth port of the evm to a switch for master station. Do the same connection for slave station to same switch.

Once the connection is done, load master and slave station code on both evm and run them simultaneously. You would see following output on uart port of master station.

You would see following output on uart port of slave station.

4.10.2.1. NDK Overview¶

The Network Development Kit (NDK) is a platform for development and demonstration of network enabled RTOS applications on TI processors and includes demonstration software showcasing capabilities across a range of network enabled applications. The NDK serves as a rapid prototype platform for the development of network and packet processing applications, or to add network connectivity to existing applications for communications, configuration, and control. Using the components provided in the NDK, developers can quickly move from development concepts to working implementations attached to the network.

The NDK provides an IPv6 and IPv4 compliant TCP/IP stack working with the TI-RTOS Kernel real-time operating system. Its primary focus is on providing the core Layer 3 and Layer 4 stack services along with additional higher-level network applications such as HTTP server and DHCP.

The NDK itself does not include any platform or device specific software. The NDK interfaces through well-defined transport interface, Network Interface Management UNIT(NIMU) to the PDK and platform software elements needed for operation. NIMU support. NIMU provides an interface between the stack and the device drivers through which the stack can talk to multiple instances of a single or various device drivers concurrently.

4.10.2.2. NIMU Transport¶

The NDK transport component of the PDK currently provided 2 implementations for the NIMU layer as described in the sections below. The following diagram is a high level depiction of the NDK/NIMU architecture with reference to the NIMU implementations. For details for the NDK/NIMU architecture, please refer to NDK Programmer’s Reference Guide [2]

4.10.2.3. NIMU for CPSW¶

NIMU for CPSW provides a common CPSW interface library for NDK to communicate with when network stack is being implemented in the TI’s Common Platform Ethernet Switch for ethernet packet processing. The library uses the CSL-R based API interfaces to provide NIMU interface for NDK. This package has NDK unit test examples for all supported EVMS as indicated in the table above.

4.10.2.4. NIMU for ICSS¶

NIMU for ICSS (PRU-ICSS is Programmable Real-Time Unit Industrial Communications Subsystem) provides a common PRU-ICSS interface library for NDK to communicate with when network stack is being implemented in the PRU-ICSS subsytem for ethernet packet processing (firmware based switch running on PRU’s which are part of the ICSS). The library used the ICSS_EMAC LLD to provide NIMU interface for NDK. This package has NDK unit test examples for all supported Devices as indicated in the table above. For details of the PRU-ICSS, please refer to ICCS-EMAC.

4.10.2.5. Examples¶

TaskCreate( NS_BootTask, "ConfigBoot", OS_TASKPRINORM, 4096,(UINT32)hCfg, 0, 0 );

4.10.2.6. CCLink Example¶

Refer Processor_SDK_RTOS_CCLINK for details on steps for running cclink master and slave examples on NDK.

4.10.2.7. FAQ¶

4.10.2.8. Additional Documentation References¶

Introduction

Driver Features

• Initialization of NetCP low level driver resources
• Initialization of Packet DMA related resources associated with NetCP
• Classification of incoming packets based on L2: MAC header fields
• Classification of incoming packets based on L3: IPv4/IPv6 header fields
• Routing of packets to host based on L4: UDP/TCP/GTP-U
• Unidirectional IPSec SA creation and deletion
• In band offload of IPSec encryption/decryption for the outgoing packets
• Access to SA data mode acceleration for data plane applications.
• Supports offload of the following features to NETCP Hardware during transmission of packets:
  • IPv4 checksum/L4:TCP/UDP checksum/IPSec Encryption
  • Redirection of packets through a specific MAC port
  • Software Insertion of L2/L3/L4 header
• Upon reception of packet, module provides additional meta data details including:
  • Status of IP checksum/UDP/TCP checksum results
  • Offset to L2/L3/L4 protocol offsets. Appropriate layer offset will be valid only if classification or routing is enabled at NETCP
  • Ingress MAC port information

Modes of Operation

Following modes of operations are supported by NWAL when sending control configuration request to configure NetCP firmware. BLOCKING Mode: In this mode, status of API request used to configure NetCP is returned back in API call context.

Non-BLOCKING Mode: In this mode, application can invoke a separate poll routine to retrieve status response result.

Driver Configuration

The driver configures the NWAL subsystem using the nwalGlobCfg_t structure.

This structure must be initialized before the nwal_create() function API is called and cannot be changed afterwards. For details regarding individual fields of this structure, see the Doxygen help by opening PDK_INSTALL_DIRpackagestidrvnwaldocsdoxygenhtmlindex.html.

APIs

API reference for application can be found in below file:

#include <ti/drv/nwal/nwal.h>

Example

Additional References

4.11.1.1. Overview¶

#include <ti/transport/timeSync/icss_timeSync.h>

...
Board_init(boardCfg);
timeSync_example_configureInterrupts(EMAC_PORT_NUM, &emacCfg);
ICSS_EmacSocSetInitCfg(instance, emacBaseAddr);
ICSS_EmacInit();
/* Assumption: firmware is downloaded and ICSS_EMAC driver is initialized */
TimeSync_drvInit(timeSyncHandle);
TimeSync_drvEnable(timeSyncHandle);
TimeSync_enableMaster();
While(1)
{
    Delay();
}

...
Board_init(boardCfg);
timeSync_example_configureInterrupts(EMAC_PORT_NUM, &emacCfg);
ICSS_EmacSocSetInitCfg(instance, emacBaseAddr);
ICSS_EmacInit();
/* Assumption: firmware is downloaded and ICSS_EMAC driver is initialized */
TimeSync_drvInit(timeSyncHandle);
TimeSync_drvEnable(timeSyncHandle);
TimeSync_disableMaster();
While(1)
{
    Delay();
}

4.11.1.2. Additional References¶