After powering on the EVM, the bootflow takes place mainly in two steps
ROM boot, in which the ROM bootloader boots a secondary bootloader or an SBL
SBL boot in which the secondary bootloader boots the application
This section details these steps and gives an overview of the bootloaders to understand the process better.
Bootflow
HIGH LEVEL BOOTFLOW
ROM Boot
As soon as the EVM is powered ON, the ROM bootloader or RBL starts running. The RBL is the primary bootloader.
Depending on which boot mode is selected on the EVM, the RBL will load the secondary bootloader or SBL from a boot media (OSPI flash, SD card or via UART).
Rest of the booting is done by the SBL.
The RBL expects the image it boots (SBL in our case) to be signed always. Refer Booting Tools for more information on signing scripts.
SBL Boot
The SBL is essentially an example application of the bootloader library.
We call it a secondary bootloader because it is booted by the RBL, which is the primary bootloader.
An SBL typically does a bunch of SOC specific initializations and proceeds to the application loading.
In case of AM64x EVM, the SBL loads the SYSFW to the Cortex M3 and sends the board cfg to the SYSFW once M3 is booted.
Depending on the type of SBL loaded, SBL looks for the multicore appimage (refer Booting Tools for more on multicore appimage) of the application binary at a specified location in a boot media.
If the appimage is found, the multicore appimage is parsed and split into RPRCs. These are optimized binaries which are then loaded into cores
Each RPRC will have information regarding the core on which it is to be loaded, entry points and multiple sections of that application binary
The SBL uses this information to initialize each core which has a valid RPRC. It then loads the RPRC according to the sections specified, sets the entry points and releases the core from reset. Now the core will start running
SBL BOOT
Bootloaders
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
The 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.
The 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 steps
To boot an application using the sbl_ospi, the application image needs to be flashed at a particular location in the OSPI flash memory.
This location or offset is specified in the SysConfig of the sbl_ospi application. Currently this is 0x80000. In most cases you wouldn't need to change this.
To flash an application (or any file in fact) to a location in the OSPI flash memory, follow the steps mentioned in Basic steps to flash files
SBL UART
The 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.
To boot an application using the sbl_uart, you can refer to UART Bootloader Python Script subsection. Detailed steps on the usage is mentioned in the same subsection.