Booting user defined applications on a SOC involves multiples steps as listed below,
This section details these steps and gives an overview of the bootloaders to understand the process better.
This section also describes the steps to enable XIP (eXecute In Place) for your applications.
See also these additional pages for more details and examples about the boot flow,
makefile_ccs_bootimage_gen
that is included in every example and secondary bootloader (SBL) CCS project.makefile
in the example folder.Shown below are the different steps that are done to convert the compiler+linker generated application .out
into a format suitable for flashing and booting
out2rpc
is used to convert the ELF .out to a binary file containing only the loadable sections. This is called a RPRC file.xipGen
is used to split this RPRC file into two RPRC files.multiCoreGen
is then used to combine all the non-XIP RPRC files per CPU into a single .appimage
file which is a concatenation of the individual CPU specific RPRC files.multiCoreGen
is used again to combine all the XIP RPRC files per CPU into a single .appimage_xip
file which is a concatenation of the individual CPU specific RPRC XIP files..appimage
and .appimage_xip
is then flash to the EVM
.appimage
and .appimage_xip
) are created one needs to copy or flash these to a supported boot media so that the application can start executing once the SOC is powered ONAfter a SBL and application image is flashed, shown below is the high level boot flow, after the SOC is powered on.
SBL BOOT
Depending on the boot media from which we load the application binary, we have multiple SBLs like sbl_ospi
,sbl_uart
etc. A bare minimum SBL called the sbl_null
is also included which aids the users to load their applications via CCS.
sbl_null
is a secondary bootloader which doesn't load any application binary, but just does the SOC initialization and puts all the cores in WFI (Wait For Interrupt) mode.sbl_sd
is a secondary bootloader which reads the application image file from the SD card and then moves on to core initialization and other stepssbl_sd
, the application image needs to be copied to the SD card as a file named "app". Make sure that the SD card is formatted to have a FAT partition. To know more about the SD card partitioning please refer SOC Initialization Using SD BOOTsbl_sd
binary and the application image binary has to be present as files in the SD card. You have to rename the sbl_sd
appimage as 'tiboot3.bin'. copy file to SD card => ${SDK_INSTALL_PATH}/tools/boot/sbl_prebuilt/am64x-evm/sbl_sd.release.tiimage rename in SD card as => tiboot3.bin
sbl_sd
reads the full appimage file into an MSRAM buffer and then parses the multicore appimage. Because of this reason appimages higher than ~380 KB in size can't be booted by sbl_sd
as of now.sbl_ospi
is a secondary bootloader which reads and parses the application image from a location in the OSPI flash and then moves on to core initialization and other stepssbl_ospi
, the application image needs to be flashed at a particular location in the OSPI flash memory.sbl_ospi
application. Currently this is 0x80000. In most cases you wouldn't need to change this.sbl_uart
is a secondary bootloader which receives the multicore appimage via UART, stores it in memory and then does the parsing, core initialization etc.sbl_uart
, you can refer to UART Bootloader Python Script subsection. Detailed steps on the usage is mentioned in the same subsection.sbl_ospi_linux
is a secondary bootloader which boots Linux on A53 core and RTOS/NORTOS application on R5, M4 cores.sbl_ospi_linux
, the Linux appimage (see Linux Appimage Generator Tool) and the RTOS/NORTOS application images needs to be flashed at a particular location in the OSPI flash memory.sbl_ospi_linux
application. Currently this is 0x80000 for RTOS/NORTOS images and 0x300000 for Linux application image. In most cases you wouldn't need to change this.sbl_emmc_linux
is a secondary bootloader which boots Linux on A53 core and RTOS/NORTOS application on R5, M4 cores from eMMC.sbl_emmc_linux
, the Linux appimage (see Linux Appimage Generator Tool) and the RTOS/NORTOS application images needs to be flashed at a particular location in the eMMC.sbl_emmc_linux
application. Currently this is 0x800000 for RTOS/NORTOS images and 0xA00000 for Linux application image. In most cases you wouldn't need to change this.The SBL is like any other application, created using the same compiler and linker toolchain. However the steps to convert the application .out
into a bootable image are different for SBL as listed below
wfi
loop. This is done by specifying a different entry point -e_vectors_sbl
in the linker command file for the SBL application. In _vectors_sbl
the very first thing it does is detect the core and continue execution for Core0, while if the core is Core1 then it enters wfi
loop.main()
, make sure to call Bootloader_socLoadSysFw
to load the SYSFW to DMSC M3 and setup a "board config"0x70000000
and this is the entry point for the SBL.0x70000000
to 0x70080000
should be used by SBL code, data, stack etc.out
file is first converted to a binary format .bin
using the GCC objcopy
tool.objcopy
fills the gaps with 0xFF
..bin
file is then signed using the Signing Scripts to create the final .tiimage
bootable image..tiimage
file can then be flashed or copied to a boot image using the Flashing Tools