From: Bo Gan <ganboing@gmail.com>
To: Valentin Haudiquet <valentin.haudiquet@canonical.com>,
opensbi@lists.infradead.org
Cc: troy.mitchell@linux.spacemit.com, xianbin.zhu@linux.spacemit.com,
anup@brainfault.org, ganboing@gmail.com,
samuel.holland@sifive.com, heinrich.schuchardt@canonical.com
Subject: Re: [PATCH v3 0/5] platform: generic: spacemit: add K3 platform support
Date: Tue, 1 Sep 2026 15:41:07 -0700 [thread overview]
Message-ID: <2c3672f5-dcfe-489b-be0d-5c1d2a50840c@gmail.com> (raw)
In-Reply-To: <20260831200832.404000-1-valentin.haudiquet@canonical.com>
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.
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>
>
--
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi
next prev parent reply other threads:[~2026-09-01 22:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 9:19 [PATCH v3 0/5] platform: generic: spacemit: add K3 platform support Troy Mitchell
2026-08-27 9:19 ` [PATCH v3 1/5] lib: sbi: select expected trap handler per hart Troy Mitchell
2026-08-31 2:21 ` Alvin Chang
2026-09-01 5:45 ` Troy Mitchell
2026-08-27 9:19 ` [PATCH v3 2/5] platform: generic: spacemit: k1: rename cache flush operation Troy Mitchell
2026-08-27 9:19 ` [PATCH v3 3/5] platform: generic: spacemit: k1: move hart init to nascent hook Troy Mitchell
2026-08-27 9:19 ` [PATCH v3 4/5] platform: generic: spacemit: k1: refactor platform support Troy Mitchell
2026-08-27 9:19 ` [PATCH v3 5/5] platform: generic: spacemit: k3: add " Troy Mitchell
[not found] ` <20260831200832.404000-1-valentin.haudiquet@canonical.com>
2026-08-31 20:07 ` [PATCH 1/3] platform: generic: spacemit: k3: de-vote cluster power-downs and ungate DMASYS before CCI enable Valentin Haudiquet
2026-09-01 2:25 ` Troy Mitchell
2026-08-31 20:07 ` [PATCH 2/3] platform: generic: spacemit: k3: override cold_boot_allowed for hart 0 only Valentin Haudiquet
2026-09-01 5:45 ` Troy Mitchell
2026-08-31 20:07 ` [PATCH 3/3] platform: generic: spacemit: k3: wake A100 core 8 for ESOS/RPMI services Valentin Haudiquet
2026-09-01 2:25 ` Troy Mitchell
2026-09-01 5:48 ` [PATCH 0/3] platform: generic: spacemit: k3: follow-up fixes Troy Mitchell
2026-09-02 8:41 ` Bo Gan
2026-09-02 9:38 ` Troy Mitchell
2026-09-02 11:42 ` Valentin Haudiquet
2026-09-01 22:41 ` Bo Gan [this message]
2026-09-02 5:51 ` [PATCH v3 0/5] platform: generic: spacemit: add K3 platform support Bo Gan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c3672f5-dcfe-489b-be0d-5c1d2a50840c@gmail.com \
--to=ganboing@gmail.com \
--cc=anup@brainfault.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=opensbi@lists.infradead.org \
--cc=samuel.holland@sifive.com \
--cc=troy.mitchell@linux.spacemit.com \
--cc=valentin.haudiquet@canonical.com \
--cc=xianbin.zhu@linux.spacemit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox