[PATCH 0/3] platform: generic: spacemit: k3: follow-up fixes

Wed Sep 2 04:42:44 PDT 2026

Hi Troy, Bo,

Thanks all for the clarifications. Sorry I misunderstood the
architecture and thought ESOS was using A100, I now understand that
this is not the case and that it should not be needed for the upstream
kernel boot.

Troy,
I agree that the vendor path not being part of this series makes
sense. However, you said in cover letter:

> U-Boot and Linux 6.18.3 started, Linux detected SBI v3.0 and the HSM extension, and all 16 CPUs came online.

The "Linux 6.18.3" made me think this was the vendor kernel. The
upstream kernel patches are based on 7.2/7.3 (or at least I thought?).
Thanks for confirming that you tested an upstream-based tree as well
(with backporting of the patches, then?). Also, the upstream kernel
only sees the 8 X100 cores AFAIK, so how did the 16 cores (i.e.
including the A100?) came online?
This is the reason why I assumed you were testing the vendor kernel.

I'm still debugging the issues I have with the upstream 7.2 kernel. I
believe that is the main difference between our tests: you must have
used U-Boot DTB where I used the upstream DTB (force-fed to the kernel
using Grub `devicetree` or an EFI stub), which only describe the 8
X100 cores.

It seems I was mistaken with the ESOS explanation, but I now have a
new theory :)

Here's what I believe is happening:

The v3 pre_init enables CCI-550 snoop and DVM requests for all seven
slave interfaces, including interfaces 3-6 (clusters 2-3, the A100
clusters). The CCI-550
broadcasts every snoop to all enabled slave interfaces. It doesn't
matter that only X100
CPUs are running; every coherent memory access from any X100 core
triggers a snoop to the A100 clusters interfaces.

With the upstream kernel DTB (8 X100 CPUs, clusters 0-1), the kernel
never onlines harts
8-15, so the HSM hart_start is never called for clusters 2-3. Those
clusters stay
unpowered. But the CCI is already snooping their interfaces from
pre_init. Snoops to an
unpowered cluster stall the issuing CPU in a memory instruction: a hard lockup.

I tested this by applying the patches incrementally:

1. v3 unmodified: hard lockup during udev coldplug. The clusters are
still voted for
power-down; the CCI snoop to a fully-dead interconnect can't respond at all.
2. De-vote all clusters + pin cold boot to hart 0: the hang moves
later but still occurs.
A soft hang at basic.target that changes location between reboots.
3. Wake core 8 in pre_init (without the A100 perf CSRs): boots
reliably. Waking core 8
powers up cluster 2, CCI snoops to interfaces 3-4 complete reliably.
(I believe cluster 3 does not need powering up as its L2 was never
touched, and empty L2 returns clean immediately on snoop).

If you used U-Boot DTB, with 16 CPUs, then the kernel onlines all
harts and HSM de-votes
and powers clusters 2-3 before doing coherent memory operations. With
upstream kernel DTB, HSM path never runs.

I'm still trying to figure out all the hardware details and fully
grasp the issues.

I guess I see two paths forward:
- Make the platform X100-only: enable CCI snoop/DVM for interfaces 0-2
(AIDMA + clusters 0-1 only), and drop the A100 HSM support. This
matches the upstream kernel DTB and avoids the stall, but limits the
platform to 8 harts.
- Keep the full 16-hart support, but power all clusters before
enabling CCI snoop. De-vote all clusters and wake core 8 in pre_init
so the interconnects are alive before the CCI starts snooping them.
This is my modified patches 1 and 3 (de-vote all clusters + wake core
8, without the A100 perf CSRs).

Does that make sense? What do you think?

Thanks for the comments and the patience while I try to figure out how
the internals of the K3 platform work.

--
Valentin Haudiquet

On Wed, 2 Sept 2026 at 11:38, Troy Mitchell
<troy.mitchell at linux.spacemit.com> wrote:
>
> On Wed, Sep 2, 2026 at 01:41:16AM -0700, Bo Gan wrote:
> > Hi Troy,
> >
> > I missed this one earlier. So basically I need the latest upstream kernel
> > to be able to test this patchset,
>
> Yes, that is correct. I have only tested this series with the upstream
> kernel, not the vendor kernel. Sorry for not pointing this out in the
> cover letter.
>
> >
> > because all the rpmi backed devices in
> > vendor kernel device-tree just won't work. Perhaps this should be called
> > out in the cover letter, so I don't have to waste time debugging vendor
> > stuff. IMO, leaving the rpmi stuff out is the right approach for initial
> > work. I feel that path needs to be properly reviewed and make sure it
> > fully conforms to the standard.
>
> I will state this explicitly in the next cover letter. This series
> only provides the basic K3 platform initialization and start-only HSM
> support needed to bring up the X100 and A100 harts. It does not include
> the vendor-specific OpenSBI RPMI support required by the vendor kernel
> and DT.
>
> The relevant public documentation is available here:
>
>   CCI and PMA [1]
>   HSM-related power management [2]
>   Clock and reset [3]
>   SoC address map [4]
>
> We do not currently plan to publish additional K3 hardware details.
> Before doing so, we would need to reorganize the documentation and review
> which parts can be made public. This is a substantial amount of work and
> is not currently scheduled.
>
> Link: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/08_cpu.md [1]
> Link: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/16_peripherals/power_management.md [2]
> Link: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/17_clock_reset.md [3]
> Link: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/06_address_map.md [4]
>
>                                             - Troy