From: "Troy Mitchell" <troy.mitchell@linux.spacemit.com>
To: "Heinrich Schuchardt" <heinrich.schuchardt@canonical.com>,
"Troy Mitchell" <troy.mitchell@linux.spacemit.com>
Cc: "Xianbin Zhu" <xianbin.zhu@linux.spacemit.com>,
"Anup Patel" <anup@brainfault.org>, "Bo Gan" <ganboing@gmail.com>,
<opensbi@lists.infradead.org>
Subject: Re: [PATCH v2 0/5] platform: generic: spacemit: add K3 platform support
Date: Thu, 27 Aug 2026 10:50:54 +0800 [thread overview]
Message-ID: <DKZDVFC52TYA.1IO9RZU933V60@linux.spacemit.com> (raw)
In-Reply-To: <81df96b6-8c0e-4a02-8139-33305393c9ce@canonical.com>
[-- Attachment #1.1: Type: text/plain, Size: 4710 bytes --]
On Fri Aug 21, 2026 at 10:33 PM +08, Heinrich Schuchardt wrote:
> On 8/18/26 03:14, Troy Mitchell wrote:
>> Add initial OpenSBI platform support for the SpacemiT K3 SoC. K3 has
>> 16 harts split across four clusters: eight X100 harts in C0/C1 and
>> eight A100 harts in C2/C3.
>>
>> The main upstream integration constraint is that K3 is heterogeneous at
>> the ISA level. The CPU device tree used for testing exposes the same
>> non-H standard extensions for X100 and A100. X100 additionally exposes H
>> and the related Sha, Shcounterenw, Shgatpa, Shtvala, Shvsatpa,
>> Shvstvala, and Shvstvecd extensions. X100 has a 256-bit VLEN, while
>> A100 has a 1024-bit VLEN. A100 also implements the vendor-specific
>> SpacemiT IME and FP8 AI extensions, which OpenSBI does not inspect or
>> use.
>>
>> At the base of this series, OpenSBI selects the expected-trap handler
>> once from the cold-boot hart and reuses it globally. An X100 cold-boot
>> hart would therefore make an A100 hart use the H-aware handler, which
>> accesses mtval2 and mtinst even though A100 does not implement H. Select
>> the handler from the current hart instead. An audit of the remaining
>> extension-dependent paths found that ISA extensions and detected CSR
>> features are stored per-hart, the generic FDT parser visits every hart,
>> and vector code reads the current hart's VLENB. The K3 CPU device tree
>> also exposes the same counter and timer extensions on both core types.
>> No other cold-boot-hart-derived ISA selection was found.
>>
>> K1 and K3 share vendor cache-control CSRs, PMU idle fields, cluster
>> sizing, and the CCI-550 programming sequence, but their CCI topology,
>> boot flow, and HSM support differ. Factor only the common definitions and
>> CCI helper so K3 does not depend on K1 and the K1 encoded values and
>> behavior remain unchanged. Run per-hart register setup from
>> nascent_init() rather than the policy-only cold_boot_allowed() hook.
>>
>> On K3, the cold-boot hart programs the four cluster warm-boot vectors,
>> enables CCI snoop and DVM requests, prevents WFI from powering down cores
>> or clusters, and wakes the secondary harts. A bounded wait prevents a
>> non-responsive secondary hart from stalling boot indefinitely. Each hart
>> programs its own PMA, cache, snooping, and prefetch state, with X100 harts
>> also enabling H. The warm-boot entry establishes cache coherency before
>> entering common code so secondary harts can observe state published by
>> the cold-boot hart.
>>
>> Runtime validation used the SpacemiT K3 SDK. The UART at 115200 baud
>> showed OpenSBI and U-Boot starting successfully, followed by Linux
>> bringing all 16 harts online. The series has also been build-tested with:
>>
>> - the generic default configuration
>> - a K1 configuration with K3 disabled and the SpacemiT HSM driver
>> - a K3 configuration with K1 and the SpacemiT HSM driver disabled
>>
>> To reproduce the runtime test, build this OpenSBI tree at the address
>> where the SDK loads it, then copy the resulting firmware into the SDK
>> output directory:
>>
>> K3_SDK_DIR=/path/to/k3-sdk
>> make O=build-k3 CROSS_COMPILE=riscv64-linux-gnu- PLATFORM=generic \
>> FW_TEXT_START=0x100000000
>> cp build-k3/platform/generic/firmware/fw_dynamic.bin \
>> "$K3_SDK_DIR/output/fw_dynamic.bin"
>>
>> Before rebuilding U-Boot, update the UART0 node in the K3 board DT
>> selected by SPL and passed to OpenSBI. The SDK describes it only as
>> "ns16550", so upstream OpenSBI initializes it without UART_CAP_UUE and
>> writes 0x00 to UART_IER. The K3 UART requires UART_IER_UUE (bit 6).
>> Change the node in uboot-2022.10/arch/riscv/dts/k3.dtsi to:
>>
>> uart0: uart@d4017000 {
>> ...
>> compatible = "spacemit,k1-uart", "intel,xscale-uart",
>> "ns16550";
>> ...
>> };
>>
>> The compatible order is significant. Upstream OpenSBI skips the vendor
>> string, then matches "intel,xscale-uart", which selects UART_CAP_UUE and
>> writes 0x40 to UART_IER. The final "ns16550" remains a generic fallback.
>> This is the DT used for the successful boot test.
>>
>> With output/fw_dynamic.bin already present, rebuild U-Boot. The SDK
>> preserves that OpenSBI binary and packages it with U-Boot:
>>
>> make -C "$K3_SDK_DIR" uboot
>
> The SpacemiT firmware is developing fast. Please, indicate the exact
> version by commit hash and repo url for buildroot, U-Boot, esos, EDK II,
> Linux or any other repos that are needed for testing.
Will add the exact commit hashes in the next revision.
--
Troy Mitchell
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 248 bytes --]
[-- Attachment #2: Type: text/plain, Size: 105 bytes --]
--
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi
prev parent reply other threads:[~2026-08-27 2:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 1:14 [PATCH v2 0/5] platform: generic: spacemit: add K3 platform support Troy Mitchell
2026-08-18 1:14 ` [PATCH v2 1/5] lib: sbi: select expected trap handler per hart Troy Mitchell
2026-08-20 8:40 ` Bo Gan
2026-08-18 1:14 ` [PATCH v2 2/5] platform: generic: spacemit: k1: rename cache flush operation Troy Mitchell
2026-08-18 1:14 ` [PATCH v2 3/5] platform: generic: spacemit: k1: move hart init to nascent hook Troy Mitchell
2026-08-20 8:42 ` Bo Gan
2026-08-18 1:14 ` [PATCH v2 4/5] platform: generic: spacemit: k1: refactor platform support Troy Mitchell
2026-08-18 1:14 ` [PATCH v2 5/5] platform: generic: spacemit: k3: add " Troy Mitchell
2026-08-20 9:18 ` Bo Gan
2026-08-27 3:21 ` Troy Mitchell
2026-08-20 14:25 ` Samuel Holland
2026-08-21 1:55 ` Troy Mitchell
2026-08-21 13:28 ` Heinrich Schuchardt
2026-08-27 2:53 ` Troy Mitchell
2026-08-20 9:26 ` [PATCH v2 0/5] platform: generic: spacemit: add K3 " Bo Gan
2026-08-21 1:18 ` Troy Mitchell
2026-08-21 14:33 ` Heinrich Schuchardt
2026-08-27 2:50 ` Troy Mitchell [this message]
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=DKZDVFC52TYA.1IO9RZU933V60@linux.spacemit.com \
--to=troy.mitchell@linux.spacemit.com \
--cc=anup@brainfault.org \
--cc=ganboing@gmail.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=opensbi@lists.infradead.org \
--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