[PATCH v4 0/6] platform: generic: spacemit: add K3 platform support

[Anirudh Srinivasan]

Hi Troy,

On Thu, Sep 10, 2026 at 10:00:01PM +0800, Troy Mitchell wrote:
> This series adds basic K3 platform initialization and start-only HSM
> support. Secondary harts are started directly through the SoC PMU. RPMI
> support for the vendor kernel is outside the scope of this series; the
> upstream Linux boot path does not depend on ESOS.
> 
> K3 has eight X100 harts and eight A100 harts across four clusters. X100
> implements H with a 256-bit VLEN; A100 has no H and a 1024-bit VLEN. The
> existing expected-trap handler is chosen by the cold-boot hart, which
> fails if that hart implements H and another does not. Store the handler
> per hart in scratch space and load it directly, avoiding an accessor call
> in CSR probes. Other extension and vector state is already maintained or
> queried per hart.
> 
> Only hart 0 is powered at reset. The HSM backend clears the requested
> hart's core and cluster power-down votes and wakes it on demand. PMA,
> cache and X100 H-extension setup precede the common warm-boot entry.
> Cold boot programs the cluster reset vectors and enables CCI-550 snoop
> and DVM requests before secondary harts start.

I was hoping you could clarify a couple of details about how the non
boot HARTs are brought out of reset. There seem to be some differences
between this OpenSBI series and the vendoer opensbi tree.

The vendor OpenSBI tree relies on a "riscv,rpmi-hsm" node in the DT to
probe a HSM driver. This calls spacemit_wakeup_core [1] which does the
writes to the registers that is done by spacemit_k3_hart_start in this
patch series.

However, I am noticing that the probe for the riscv,rpmi-hsm device
fails on my board with the Vendor OpenSBI. OpenSBI logs are here [2].
This would result in OpenSBI falling back to simple IPIs to wake the
remaining harts up, and that shouldn't work if the harts are still in
reset.

Is my understanding of this correct? How does the vendor OpenSBI wake
the other harts up? Does the ESOS firmware play a role here? Are
incoming IPIs translated to a reset-desassert for the core?

[1] https://github.com/spacemit-com/opensbi/blob/k3-br-v1.0.y/lib/utils/hsm/fdt_hsm_rpmi.c#L382
[2] https://gist.github.com/asrinivasanTT/2ddc73b05f4b290fb6618408fd5bd2d2

Regards
Anirudh Srinivasan