OpenSBI Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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