Once application image is loaded into memory, it needs to be run on the respective cores.
Bootloaders are responsible for this. It is a software that runs as soon as an SoC is powered on. It performs SOC initializations, configures clocks, registers. It then communicates with an external media to receive the application.
In MCU+SDK, multistage bootloading is done where first the ROM bootloader boots a secondary bootloader, and the secondary bootloader, or SBL boots up the application.
The ROM bootloader is stored in RAM. It expects a x509 signed image of the SBL.
Then the SBL needs to be placed at 0x70020000 in RAM, and the application offset needs to be specified to the SBL.
The SBL then reads this application, parses it, loads to respective CPUs, releases core from reset. The application starts running now.
For detailed information on bootloaders and bootflow, refer Understanding the bootflow and bootloaders
SBL | Reference |
---|---|
SBL NULL | |
SBL OSPI | |
SBL UART | SBL UART |
SBL CAN | SBL CAN |
SBL SD | SBL SD |
The SBL is like any other example of the SDK. They use the bootloader library APIs to carry out the bootloading process.
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. Here are some details regarding those.
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_null
is an alternative to this process.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 0x81000. This offset is chosen under the assumption that the sbl_ospi
application takes at max 512 KB from the start of the flash. If a custom bootloader is used, make sure that this offset is chosen in such a way that it is greater than the size of the bootloader which is being flashed and also aligns with the block size of the flash.sbl_uart
is a secondary bootloader which receives the multicore application 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_can
is a secondary bootloader which needs to be flashed in QSPI Flash.sbl_can
receives the multicore application via CAN, stores it in memory and then does the parsing, core initialization etc.sbl_can
, you can refer to CAN Bootloader Python Script subsection.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"sbl_sd
reads the full application file into an MSRAM buffer and then parses the multicore application. Because of this reason application images higher than ~512 KB in size can't be booted by sbl_sd
as of now.sbl_sd
, you can refer to SBL SD subsection.For non secure boot, the SBL just reads the application image from a boot media, parses it, and boots it.
In secure boot, the SBL reads the signed application image from a boot media, authenticates it, decrypts it, and boots it.
For detailed information refer Enabling Secure Boot
For information on various debugging tools and techniques, refer Debugging Sitara AM2x Microcontrollers