[PATCH 7/8] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC

[Guodong Xu]

On Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 12/16/25 14:32, Guodong Xu wrote:
> > SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> > Add nodes of uarts, timer and interrupt-controllers.
> >
> > Signed-off-by: Guodong Xu <guodong at riscstar.com>
> > ---
> >   arch/riscv/boot/dts/spacemit/k3.dtsi | 529 +++++++++++++++++++++++++++++++++++
> >   1 file changed, 529 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..cb27b790716fdd6dc2bc89c28dd2588a596a5af9
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > @@ -0,0 +1,529 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
> > + * Copyright (c) 2025 Guodong Xu <guodong at riscstar.com>
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > +     #address-cells = <2>;
> > +     #size-cells = <2>;
> > +     model = "SpacemiT K3";
> > +     compatible = "spacemit,k3";
> > +
> > +     aliases {
> > +             serial0 = &uart0;
> > +             serial2 = &uart2;
> > +             serial3 = &uart3;
> > +             serial4 = &uart4;
> > +             serial5 = &uart5;
> > +             serial6 = &uart6;
> > +             serial7 = &uart7;
> > +             serial8 = &uart8;
> > +             serial9 = &uart9;
> > +             serial10 = &uart10;
> > +     };
> > +
> > +     cpus: cpus {
> > +             #address-cells = <1>;
> > +             #size-cells = <0>;
> > +             timebase-frequency = <24000000>;
> > +
> > +             cpu_0: cpu at 0 {
> > +                     compatible = "spacemit,x100", "riscv";
> > +                     device_type = "cpu";
> > +                     reg = <0>;
> > +                     riscv,isa-base = "rv64i";
> > +                     riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "h",
> > +                                            "smaia", "smstateen", "ssaia", "sscofpmf",
> > +                                            "ssnpm", "sstc", "svade", "svinval", "svnapot",
> > +                                            "svpbmt", "zawrs", "zba", "zbb", "zbc", "zbs",
> > +                                            "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > +                                            "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > +                                            "zicntr", "zicond", "zicsr", "zifencei",
> > +                                            "zihintntl", "zihintpause", "zihpm", "zimop",
> > +                                            "zkt", "zvbb", "zvbc", "zvfbfmin", "zvfbfwma",
> > +                                            "zvfh", "zvfhmin", "zvkb", "zvkg", "zvkn",
> > +                                            "zvknc", "zvkned", "zvkng", "zvknha",
> > +                                            "zvknhb", "zvks", "zvksc", "zvksed",
> > +                                            "zvksg", "zvksh", "zvkt";
>
> This not the description of an RVA23S64 cpu. It is not even RVA23U64,
> e.g. `supm` is missing.
>
> Is the description incomplete or is the CPU not compliant?

Hi Heinrich,

The SpacemiT K3 supports the mandatory extensions defined in the RVA23
Profile (ratified Oct 2024). The list appears incomplete here only because
I am restricting the entries to those currently supported by the Linux
kernel Device Tree bindings.

Specifically, I must adhere to
Documentation/devicetree/bindings/riscv/extensions.yaml (and cpus.yaml for
properties like 'riscv,sv39' which stands for the extension Sv39). If I
add extension strings that are not yet defined in these schemas, such as
supm, running 'make dtbs_check W=3' fails with: 'supm' is not one of
['i', 'm', 'a', ...], followed by "Unevaluated properties are not allowed."

Another angle, I found there are other reasons why Linux kernel chose to
'omit' some specific extension strings. For example, here are what I noticed
so far, including the 'supm' you mentioned:

supm: There is no binding string for this yet. However, in the kernel config
(refer to arch/riscv/Kconfig), RISCV_ISA_SUPM depends on the detection of the
underlying 'smnpm' or 'ssnpm' hardware extensions. Since 'ssnpm' is
present in my list, it can be considered as supported and the kernel
will enable pointer masking support automatically.

Other examples:
ssstateen: The kernel schema currently uses the smstateen string to
cover CSR access control in all modes (H/S/VS/U/VU). I have included
'smstateen' to satisfy this, as there is no separate 'ssstateen' binding
in the extensions.yaml.

ziccif: This extension is also absent from the bindings, despite being
implied by ftrace dynamic code work. Reference:
https://lore.kernel.org/all/20250407180838.42877-12-andybnac@gmail.com/
I intend to submit a separate patch series to formally add ziccif to
extensions.yaml.

Anyway, I have limited the x100 riscv,isa-extensions list to strictly
validate against the current kernel schema while exposing all features
the kernel is currently capable of parsing.

I hope this explanation clarifies the situation. Please let me know if you
agree with this approach.

Best Regards,
Guodong Xu

>
> Best regards
>
> Heinrich
>