[PATCH v4 10/10] cmd: riscv: Add 'startharts' command to start multiple harts

[Yao Zi]

On Tue, Aug 19, 2025 at 10:34:39AM +0000, Uros Stajic wrote:
> From: Chao-ying Fu <cfu at mips.com>
> 
> Introduce the 'startharts' command for RISC-V targets, which prints
> or executes commands to power up and reset all harts and jump to
> 0x80000000. The command supports optional cluster/core count and
> immediate execution via the 'g' argument.
> 
> Signed-off-by: Chao-ying Fu <cfu at mips.com>
> Signed-off-by: Uros Stajic <uros.stajic at htecgroup.com>

I noticed in OpenSBI, P8700 already implements HSM extension[1], which
means it's usually unnecessary to take care of SMP stuff in U-Boot. Do
you still want the new startharts command?

In summary, there are two possible solutions to support SMP for RISC-V
systems with U-Boot and OpenSBI with minimal effort, where SPL runs in M
mode and proper U-Boot runs in S mode,

1. Release all the HARTs in SPL stage. With SMP enabled in U-Boot SPL, a
   core is randomly picked to run the main part of U-Boot SPL, and the
   others simply spin and wait.

   When all the initialization and load are finished, an IPI message is
   sent to each spinning HART, releasing them to the next-level
   firmware's entry (OpenSBI here), see smp_call_function called in
   spl_opensbi.c.

   This is usually more appropriate when your platform releases all
   HARTs when powered up, in which case you could omit the code of
   releasing all HARTs to U-Boot SPL. This requires a proper
   implementation of IPI, and proper description of all HARTs in
   devicetree.

2. Implement SMP bring-up code totally in OpenSBI. U-Boot itself is
   expected to run in single thread, so it's unnecessary to bring up any
   cores in U-Boot.

   RISC-V SBI defines a HART-State-Management extension (HSM). You could
   implement HART bring-up code in OpenSBI, and expecting kernel (maybe
   Linux) brings up the rest HARTs through the extension.

Looking through the startharts command, P8700 does require manual steps
to release non-boot cores, which makes option 1 less appropriate since
it introduces more platform-specific code to U-Boot, while it has been
already implemented in OpenSBI, becoming some duplicated code.

I suggest moving to HSM extension entirely and avoiding introducing any
SMP code in U-Boot for your port. Or, if you still prefer to implement
it in U-Boot, please re-use the existing framework of bring up HARTs
(smp_call_function, proper IPI, etc.). This could definitely helps
code review and future maintenance.

Best regards,
Yao Zi

[1]: https://github.com/riscv-software-src/opensbi/commit/66ab965e54017292d530033ffaae127389c45458