[PATCH v3 0/5] platform: generic: spacemit: add K3 platform support

[Bo Gan]

Hi Valentin, Troy,

AFAIK, the ESOS runs on the two RT24 cores, not the A100 cores. While
testing v3 patchset, I also observed the rpmi-shmem-mbox at cac90c00 timeout
xmitting messages, and I lost the rpmi backed power-regulator, which then
caused some issues in Linux. I don't think this is caused by the A100 cores
but I suspect this might have something to do with clocks not configured in
vendor uboot SPL. Please check if there're other modification to vendor
uboot that needs to be done, apart from the dts changes, in order to adapt
to this patchset.

Regarding the core/cluster HSM, can SpacemiT publish the K3 TRM, at least
regarding this topic? As there're special power-up/down sequences that a
core needs to follow, it's impossible for outsiders like me to review and
verify if the sequence is correct or not. I was told there's even more
complicated sequences when powering-down a core, if it's the last one in
cluster to power-down (suppose that we may want to support HSM stop in the
future).

Publishing the TRM would also clarify the mysterious Audio buffer, and PMA
register format. What's the address of the Audio buffer, exactly? Is there
a CSR_PMAADDR0?

Bo

On 8/31/26 13:07, Valentin Haudiquet wrote:
> Hello,
> 
> I have tested this patchseries on my K3 board. I had to patch U-Boot
> SPL and EDK2 with the mentioned DTS changes.
> 
> Afterwards, booting the upstream 7.2 kernel with Spacemit patches
> (still in mailing list) works but the kernel hangs in initramfs.
> 
> I had to add 3 patches to make it work properly, see the series
> below.
> 
> I believe one of the issues is that the v3 HSM wakes A100 core 8 only
> when Linux onlines CPU 8. The vendor kernel onlines all 16 CPUs
> so ESOS starts and RPMI works. Mainline uses only the X100 complex
> (harts 0-7), so CPU 8 is never onlined, core 8 is never woken,
> ESOS never runs, and RPMI mailbox transactions time out.
> Patch 3/3 wakes core 8 in OpenSBI pre_init so ESOS is available
> regardless of which CPUs Linux uses.
> 
> For the other patches, I'm not sure why the issues are not encountered
> with the vendor kernel.
> 
> I have adapted those patches from the Spacemit OpenSBI 1.6 vendor tree
> logic, through a lot of trial and error. I'm not sure I deeply understand
> the hardware-specific details at play, so any comments would be appreciated.
> 
> Feel free to take this in as part of the patchseries and modify it if needed,
> or send review comments and I can also improve them.
> 
> Tested-by: Valentin Haudiquet <valentin.haudiquet at canonical.com>
>