Booting and disabling processor cores#
Boot flow: SPL and SBL#
There are 2 main kinds of boot flow supported on the AM62x processors: SPL boot, and SBL boot.
In general, the Linux SDK was developed and tested with SPL boot. SPL boot is the default boot mode for the Linux SDK filesystem images. For more information about the SPL boot flow, reference the Linux SDK docs, section Boot flow.
The MCU+ SDK was mostly developed and tested with SBL boot. For more information about the SBL boot flow, reference the MCU+ SDK docs, section Secondary Bootloader (SBL).
Note
SBL that does not include Linux in the title will NOT load Linux onto the A53 cores.
Initializing remote cores#
With SPL boot, Linux initializes all remote cores other than the DM R5F cores with the Linux remoteproc driver.
However, there are additional options with SBL boot. One option is that the SBL core initializes all remote cores. In this case, the core running the SBL initializes the remote cores before the Linux kernel has booted. No changes are needed to the Linux devicetree file: The Linux remoteproc driver will detect that the remote cores have already been initialized, and it will simply initialize the resource table information. For more information about the resource table, reference section How to create remote core firmware that can be initialized by Linux.
On the other hand, if the customer wants to use SBL boot, but still wants the remoteproc driver to initialize the remote cores instead of the SBL, then the remote cores must be separately disabled in the SBL.
Disabling remote cores#
Disabling unused cores in Linux#
Cores can be disabled in the Linux devicetree. This section will focus on disabling unused remote cores. For information about disabling
the GPU core, or
A53 cores on AM62x devices that have fewer than the maximum number of cores, reference the Linux academy section Porting CPU.
Note that if SBL boot is used to initialize the system, the remote cores must also be disabled in SBL.
Cores should be disabled if:
The application does not use the remote cores that are on the processor. Disabling a core allows us to free up system resources (like memory) for usage by other cores.
You use the Linux devicetree to disable the cores
M4F.
If the device node for a remote core is disabled, then the Linux kernel never uses RemoteProc to initialize the core.
Note
Linux device tree nodes are enabled by default. That means if you want a particular core disabled, you need to set the device tree node to status = “disabled”.
Note
Cores should typically be disabled in your top level board dts file instead of one of the dtsi files.
Settings made in a .dtsi file can be overwritten by .dts files that include the .dtsi file. That means that changes to a .dtsi file may be overwritten by another file.
However, if the top-level board .dts file is not included by any other .dts files, you can guarantee that your changes to the board .dts file will NOT be overwritten.
Warning
Do NOT disable the device management subsystem R5F (WKUP_R5F)!
This R5F core runs the resource manager for all the other cores. The processor will not work if the device management R5F is disabled.
Device tree changes to disable remote cores#
For example, to disable the M4F core on the AM62x Starter Kit EVM, we change k3-am62x-sk-common.dtsi like in the attached patch. Since we are modifying a .dtsi file that could be overwritten by a later .dts file, you should make sure to check every .dts file that includes this .dtsi file to ensure that the changes are not overwritten.
The “memory-region”s will still get allocated if they are left in the Linux devicetree, but they will be unused after Linux allocates them. Remember to free up unused memory by removing the associated DDR “memory-regions” from the reserved-memory node.
For an example of how to apply a .patch file, refer to section How to apply a git patch.