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

[Bo Gan <ganboing@gmail.com>]

On 9/1/26 15:41, Bo Gan wrote:
> 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@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.

I found the problem myself. There're many SpacemiT hacks in the vendor tree.
E.g., https://github.com/spacemit-com/opensbi/commits/k3-br-v1.0.y/lib/utils/mailbox/fdt_mailbox_rpmi_shmem.c

Without those, ESOS/rpmi simply won't work. SpacemiT, please don't mislead
folks on this part. I was under the impression that this patch would just
work with the shipped ESOS, but it's clearly not the case.

> 
> 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@canonical.com>
>>
> 

Bo


-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi