Disabling remote cores in Linux#
A remote core should be disabled in Linux: 1) If the remote core does not exist or is not being used; 2) If the remote core is running, but it is not initialized by Linux, and it does not use Linux IPC.
This section will focus on disabling unused remote cores. For information about disabling
A53 cores on AM62Ax devices that have fewer than the maximum number of cores, reference the Linux academy section Porting CPU.
When should a remote core be disabled in Linux?#
The remote core does not exist, or is not used#
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.
Note that if SBL boot is used to initialize the system, any remote cores that do not exist or are not being used must also be disabled in SBL. For more information about the SBL boot flow, refer to Boot flows: SPL vs SBL. For more information about disabling cores in SBL, refer to Disabling remote cores in SBL.
The remote core is not initialized by Linux, and does not use Linux IPC#
If the remote core was initialized before Linux boot, and the remote core does NOT interact with Linux through RPMsg IPC, then the remote core should be disabled in the Linux devicetree.
HOWEVER, if the remote core DOES interact with Linux through RPMsg IPC, then the remote core should be enabled in the Linux devicetree file. Refer to section Methods to initialize remote cores for more information.
Linux does not actively shut off devicetree nodes that are marked as “disabled”. Instead, Linux simply ignores those devicetree nodes, and assumes that they are not running. Thus, marking a remote core as “disabled” will NOT turn the remote core off if the remote core was initialized by SBL or U-Boot.
Keep in mind that the remote core’s memory should still be reserved in the Linux devicetree file to prevent Linux from overwriting the memory. For more details, refer to section Memory allocation when the remote core does not interact with Linux.
Use the Linux devicetree to disable a remote core in Linux#
You use the Linux devicetree to disable the
MCU_R5F, C7x.
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 often enabled by default. That means if you want a particular core disabled, you need to verify that the device tree node is actually set 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.
Note
Linux cannot disable the device management subsystem R5F (WKUP_R5F)!
The DM R5F core must keep running, because the DM R5F runs the resource manager for all the other cores. The processor would stop working if the device management R5F stopped running.
Even if Linux does not communicate with the DM R5F over RPMsg, the DDR memory allocations of the DM R5F must be reserved in the Linux devicetree. Reserving the DM R5F’s DDR allocation ensures that Linux does not crash the DM R5F by overwriting the DM R5F’s DDR memory.
For more information about DM R5F development, refer to section Developing on the DM R5F.
Example device tree changes to disable remote cores#
For example, to disable the MCU R5F core on the AM62Ax Starter Kit EVM, we change k3-am62a7-sk.dts like in the attached patch:
AM62Ax-disable-MCU-R5F-core.patch
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.