[PATCH 0/8] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board

[PATCH 0/8] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board

[Guodong Xu]

This series introduces basic support for the SpacemiT K3 SoC and the
K3 Pico-ITX evaluation board.

The SpacemiT K3 is an SoC featuring 8 SpacemiT X100 RISC-V cores.
The X100 is a 4-issue, out-of-order core compliant with the RVA23
profile, targeting high-performance scenarios. [1]

The K3 Pico-ITX is an evaluation board built around the K3 SoC.

This series includes:
 - DT bindings for SpacemiT X100 core, K3 SoC, and Pico-ITX board.
 - DT bindings for K3 integrated peripherals: CLINT, APLIC, IMSIC, and UART.
 - Initial Device Tree for K3 SoC and Pico-ITX board.

From an RVA23 profile compliance perspective, the X100 supports all
mandatory extensions required by RVA23U64 and RVA23S64. Ideally, all
these extensions should be listed in the 'riscv,isa-extensions' string.
However, some mandatory extensions (e.g. "ziccif", "sstvecd")
are not yet supported (listed) by the upstream riscv/extensions.yaml
binding.

To avoid validation warnings (“Unevaluated properties are not allowed"
when make dtbs_check W=3) and to prevent the kernel from silently
dropping unrecognized strings, this series only declares the
isa-extensions that are currently supported by the kernel bindings.

Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
Guodong Xu (8):
      dt-bindings: riscv: add SpacemiT X100 CPU compatible
      dt-bindings: timer: add SpacemiT K3 CLINT
      dt-bindings: interrupt-controller: add SpacemiT K3 APLIC
      dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC
      dt-bindings: serial: 8250: add SpacemiT K3 UART compatible
      dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings
      riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
      riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

 .../bindings/interrupt-controller/riscv,aplic.yaml |   1 +
 .../interrupt-controller/riscv,imsics.yaml         |   1 +
 Documentation/devicetree/bindings/riscv/cpus.yaml  |   1 +
 .../devicetree/bindings/riscv/spacemit.yaml        |   6 +-
 Documentation/devicetree/bindings/serial/8250.yaml |   1 +
 .../devicetree/bindings/timer/sifive,clint.yaml    |   1 +
 arch/riscv/boot/dts/spacemit/Makefile              |   1 +
 arch/riscv/boot/dts/spacemit/k3-pico-itx.dts       |  25 +
 arch/riscv/boot/dts/spacemit/k3.dtsi               | 529 +++++++++++++++++++++
 9 files changed, 565 insertions(+), 1 deletion(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251216-k3-basic-dt-cd9540061989

Best regards,
-- 
Guodong Xu <guodong@riscstar.com>

[PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Guodong Xu]

Add compatible string for the SpacemiT X100 (RVA23 compliant) core.

Link: https://www.spacemit.com/en/spacemit-x100-core/

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index d733c0bd534fb63ed7c0eada97c42832431f1fc1..cce87092dc7749f49066154d9a256af6c7b6c19f 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -62,6 +62,7 @@ properties:
               - sifive,u74
               - sifive,u74-mc
               - spacemit,x60
+              - spacemit,x100
               - thead,c906
               - thead,c908
               - thead,c910

-- 
2.43.0

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Heinrich Schuchardt]

On 12/16/25 14:32, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> 
> Link: https://www.spacemit.com/en/spacemit-x100-core/
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>

LGTM

Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

> ---
>   Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index d733c0bd534fb63ed7c0eada97c42832431f1fc1..cce87092dc7749f49066154d9a256af6c7b6c19f 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -62,6 +62,7 @@ properties:
>                 - sifive,u74
>                 - sifive,u74-mc
>                 - spacemit,x60
> +              - spacemit,x100
>                 - thead,c906
>                 - thead,c908
>                 - thead,c910
> 

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Yixun Lan]

Hi Guodong,

On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> 
> Link: https://www.spacemit.com/en/spacemit-x100-core/
> 
no blank line here
> Signed-off-by: Guodong Xu <guodong@riscstar.com>

with that fixed
Reviewed-by: Yixun Lan <dlan@gentoo.org>

-- 
Yixun Lan (dlan)

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Guodong Xu]

On Tue, Dec 16, 2025 at 11:07 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>
> On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> > Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> >
> > Link: https://www.spacemit.com/en/spacemit-x100-core/
> >
> no blank line here

I will fix that.

> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
>
> with that fixed
> Reviewed-by: Yixun Lan <dlan@gentoo.org>

Thanks Yixun.

>
> --
> Yixun Lan (dlan)

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Yixun Lan]

Hi Guodong,

On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> 
> Link: https://www.spacemit.com/en/spacemit-x100-core/
it would be better if you can put more description into commit message
as I don't trust the link too much, it may vanish or change in the future?..

besides, if I remember correctly, there are still few optional
extensions that not supported by x100, it's worth to list here to
let community know..

> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index d733c0bd534fb63ed7c0eada97c42832431f1fc1..cce87092dc7749f49066154d9a256af6c7b6c19f 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -62,6 +62,7 @@ properties:
>                - sifive,u74
>                - sifive,u74-mc
>                - spacemit,x60
> +              - spacemit,x100
>                - thead,c906
>                - thead,c908
>                - thead,c910
> 
> -- 
> 2.43.0
> 

-- 
Yixun Lan (dlan)

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Guodong Xu]

On Tue, Dec 16, 2025 at 11:16 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>
> On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> > Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> >
> > Link: https://www.spacemit.com/en/spacemit-x100-core/
> it would be better if you can put more description into commit message
> as I don't trust the link too much, it may vanish or change in the future?..

Thanks Yixun for the feedback.
I understand your concerns. I will expand the commit message with more
information about X100 core features so we don't rely solely on the link.

>
> besides, if I remember correctly, there are still few optional
> extensions that not supported by x100, it's worth to list here to
> let community know..

I would prefer not to list the unsupported optional extensions explicitly.
Basically there are two reasons. Since the RISC-V specification includes a
vast number of optional extensions, and they are categorized in four groups
(localized options, develpment options, expansion options, and transitory
options), listing everything not supported would be quite lengthy IMHO.
Secondly, looking at previous commits for other RISC-V CPUs, it doesn't seem
to be the convention to list unsupported extensions.

I will expand the commit message to state X100 supports all _mandatory_
extensions per defined by the RVA23 profile.

I hope this approach is acceptable.

BR,
Guodong

>
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > index d733c0bd534fb63ed7c0eada97c42832431f1fc1..cce87092dc7749f49066154d9a256af6c7b6c19f 100644
> > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > @@ -62,6 +62,7 @@ properties:
> >                - sifive,u74
> >                - sifive,u74-mc
> >                - spacemit,x60
> > +              - spacemit,x100
> >                - thead,c906
> >                - thead,c908
> >                - thead,c910
> >
> > --
> > 2.43.0
> >
>
> --
> Yixun Lan (dlan)

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Krzysztof Kozlowski]

On 16/12/2025 14:32, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> 
> Link: https://www.spacemit.com/en/spacemit-x100-core/
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index d733c0bd534fb63ed7c0eada97c42832431f1fc1..cce87092dc7749f49066154d9a256af6c7b6c19f 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -62,6 +62,7 @@ properties:
>                - sifive,u74
>                - sifive,u74-mc
>                - spacemit,x60
> +              - spacemit,x100


Two reviews of this one-liner but no one pointed out that sorting is
broken... What is being exactly reviewed in this one-liner?

Best regards,
Krzysztof

Re: [PATCH 1/8] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Guodong Xu]

On Tue, Dec 16, 2025 at 11:33 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/12/2025 14:32, Guodong Xu wrote:
> > Add compatible string for the SpacemiT X100 (RVA23 compliant) core.
> >
> > Link: https://www.spacemit.com/en/spacemit-x100-core/
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > index d733c0bd534fb63ed7c0eada97c42832431f1fc1..cce87092dc7749f49066154d9a256af6c7b6c19f 100644
> > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > @@ -62,6 +62,7 @@ properties:
> >                - sifive,u74
> >                - sifive,u74-mc
> >                - spacemit,x60
> > +              - spacemit,x100
>
>
> Two reviews of this one-liner but no one pointed out that sorting is
> broken... What is being exactly reviewed in this one-liner?

Thanks Krzysztof. I will fix that, put x100 before x60.

BR,
Guodong

>
> Best regards,
> Krzysztof

[PATCH 2/8] dt-bindings: timer: add SpacemiT K3 CLINT

[Guodong Xu]

Add compatible string for SpacemiT K3 CLINT.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 0d3b8dc362ba7e8d0ca6d0cea692ceddc5e1f89e..3bab40500df9bc2ba4f7d6f1bf340c8cbc06f9de 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -33,6 +33,7 @@ properties:
               - eswin,eic7700-clint     # ESWIN EIC7700
               - sifive,fu540-c000-clint # SiFive FU540
               - spacemit,k1-clint       # SpacemiT K1
+              - spacemit,k3-clint       # SpacemiT K3
               - starfive,jh7100-clint   # StarFive JH7100
               - starfive,jh7110-clint   # StarFive JH7110
               - starfive,jh8100-clint   # StarFive JH8100

-- 
2.43.0

Re: [PATCH 2/8] dt-bindings: timer: add SpacemiT K3 CLINT

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 3/8] dt-bindings: interrupt-controller: add SpacemiT K3 APLIC

[Guodong Xu]

Add compatible string for SpacemiT K3 APLIC.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
index bef00521d5dacc002d24c50843ebe6380a7d5524..0718071444d29fbfa36283fc9666e8cecd6f77e7 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
@@ -28,6 +28,7 @@ properties:
     items:
       - enum:
           - qemu,aplic
+          - spacemit,k3-aplic
       - const: riscv,aplic
 
   reg:

-- 
2.43.0

Re: [PATCH 3/8] dt-bindings: interrupt-controller: add SpacemiT K3 APLIC

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

pw-bot: not-applicable
Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 4/8] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC

[Guodong Xu]

Add compatible string for SpacemiT K3 IMSIC.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
index c23b5c09fdb90baccece03708f4a381084b22049..152eff7335dd8457bf01d02497b7080f2a02ab65 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
@@ -47,6 +47,7 @@ properties:
   compatible:
     items:
       - enum:
+          - spacemit,k3-imsics
           - qemu,imsics
       - const: riscv,imsics
 

-- 
2.43.0

Re: [PATCH 4/8] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC

[Krzysztof Kozlowski]

On 16/12/2025 14:32, Guodong Xu wrote:
> Add compatible string for SpacemiT K3 IMSIC.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> index c23b5c09fdb90baccece03708f4a381084b22049..152eff7335dd8457bf01d02497b7080f2a02ab65 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> @@ -47,6 +47,7 @@ properties:
>    compatible:
>      items:
>        - enum:
> +          - spacemit,k3-imsics

Also not sorted. s > q.

Best regards,
Krzysztof

Re: [PATCH 4/8] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC

[Guodong Xu]

On Tue, Dec 16, 2025 at 11:34 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/12/2025 14:32, Guodong Xu wrote:
> > Add compatible string for SpacemiT K3 IMSIC.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> > index c23b5c09fdb90baccece03708f4a381084b22049..152eff7335dd8457bf01d02497b7080f2a02ab65 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> > @@ -47,6 +47,7 @@ properties:
> >    compatible:
> >      items:
> >        - enum:
> > +          - spacemit,k3-imsics
>
> Also not sorted. s > q.
>

Thanks, Krzysztof. I will fix this. q goes first.

BR,
Guodong Xu

> Best regards,
> Krzysztof

[PATCH 5/8] dt-bindings: serial: 8250: add SpacemiT K3 UART compatible

[Guodong Xu]

The SpacemiT K3 UART controller is compatible with the Intel XScale UART.
Add K3 UART binding and allow describing it with a fixed clock-frequency
for now.

The clocks and clock-names properties will be made mandatory in a future
patch, once the K3 clock driver and device tree are merged.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 167ddcbd880058b6dcea9ce33bd814ff8ba6b0f6..73851f19330d7f9fc254efcd32b5977feada0b07 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -160,6 +160,7 @@ properties:
           - enum:
               - mrvl,mmp-uart
               - spacemit,k1-uart
+              - spacemit,k3-uart
           - const: intel,xscale-uart
       - items:
           - enum:

-- 
2.43.0

Re: [PATCH 5/8] dt-bindings: serial: 8250: add SpacemiT K3 UART compatible

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 6/8] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings

[Guodong Xu]

Add DT binding documentation for the SpacemiT K3 SoC and the board Pico-ITX
which is a 2.5-inch single-board computer.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 Documentation/devicetree/bindings/riscv/spacemit.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
index 9c49482002f768cd0cc59be6db02659a43fa31ce..003b0bc1539b621e39172a0565dfea1274cbc8b8 100644
--- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -8,7 +8,8 @@ title: SpacemiT SoC-based boards
 
 maintainers:
   - Yangyu Chen <cyy@cyyself.name>
-  - Yixun Lan <dlan@gentoo.org>
+  - Yixun Lan   <dlan@gentoo.org>
+  - Guodong Xu  <guodong@riscstar.com>
 
 description:
   SpacemiT SoC-based boards
@@ -26,6 +27,9 @@ properties:
               - xunlong,orangepi-r2s
               - xunlong,orangepi-rv2
           - const: spacemit,k1
+      - items:
+          - const: spacemit,k3-pico-itx
+          - const: spacemit,k3
 
 additionalProperties: true
 

-- 
2.43.0

Re: [PATCH 6/8] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings

[Yixun Lan]

Hi Guodong,

On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> Add DT binding documentation for the SpacemiT K3 SoC and the board Pico-ITX
> which is a 2.5-inch single-board computer.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  Documentation/devicetree/bindings/riscv/spacemit.yaml | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
> index 9c49482002f768cd0cc59be6db02659a43fa31ce..003b0bc1539b621e39172a0565dfea1274cbc8b8 100644
> --- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
> +++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
> @@ -8,7 +8,8 @@ title: SpacemiT SoC-based boards
>  
>  maintainers:
>    - Yangyu Chen <cyy@cyyself.name>
> -  - Yixun Lan <dlan@gentoo.org>
> +  - Yixun Lan   <dlan@gentoo.org>
> +  - Guodong Xu  <guodong@riscstar.com>
please simply use "one blank space" here, it's more consistent,
trying to align them like this would result in even worse situation..
 
- only email addresses got aligned while not user names (first, second
  name?)
- adding another maintainer in future may break the alignment (if long
  name)

-- 
Yixun Lan (dlan)

Re: [PATCH 6/8] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Tue, Dec 16, 2025 at 11:05:30PM +0800, Yixun Lan wrote:
> Hi Guodong,
> 
> On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> > Add DT binding documentation for the SpacemiT K3 SoC and the board Pico-ITX
> > which is a 2.5-inch single-board computer.
> > 
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  Documentation/devicetree/bindings/riscv/spacemit.yaml | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
> > index 9c49482002f768cd0cc59be6db02659a43fa31ce..003b0bc1539b621e39172a0565dfea1274cbc8b8 100644
> > --- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
> > @@ -8,7 +8,8 @@ title: SpacemiT SoC-based boards
> >  
> >  maintainers:
> >    - Yangyu Chen <cyy@cyyself.name>
> > -  - Yixun Lan <dlan@gentoo.org>
> > +  - Yixun Lan   <dlan@gentoo.org>
> > +  - Guodong Xu  <guodong@riscstar.com>
> please simply use "one blank space" here, it's more consistent,
> trying to align them like this would result in even worse situation..
>  
> - only email addresses got aligned while not user names (first, second
>   name?)
> - adding another maintainer in future may break the alignment (if long
>   name)

Yeah, these are never aligned. Just do one space gap.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 6/8] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings

[Guodong Xu]

On Wed, Dec 17, 2025 at 12:33 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, Dec 16, 2025 at 11:05:30PM +0800, Yixun Lan wrote:
> > Hi Guodong,
> >
> > On 21:32 Tue 16 Dec     , Guodong Xu wrote:
> > > Add DT binding documentation for the SpacemiT K3 SoC and the board Pico-ITX
> > > which is a 2.5-inch single-board computer.
> > >
> > > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > > ---
> > >  Documentation/devicetree/bindings/riscv/spacemit.yaml | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
> > > index 9c49482002f768cd0cc59be6db02659a43fa31ce..003b0bc1539b621e39172a0565dfea1274cbc8b8 100644
> > > --- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
> > > @@ -8,7 +8,8 @@ title: SpacemiT SoC-based boards
> > >
> > >  maintainers:
> > >    - Yangyu Chen <cyy@cyyself.name>
> > > -  - Yixun Lan <dlan@gentoo.org>
> > > +  - Yixun Lan   <dlan@gentoo.org>
> > > +  - Guodong Xu  <guodong@riscstar.com>
> > please simply use "one blank space" here, it's more consistent,
> > trying to align them like this would result in even worse situation..
> >
> > - only email addresses got aligned while not user names (first, second
> >   name?)
> > - adding another maintainer in future may break the alignment (if long
> >   name)
>
> Yeah, these are never aligned. Just do one space gap.

Thanks Yixun, Conor. I will fix that.

-Guodong

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

[Guodong Xu]

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@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@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@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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache0>;
+			mmu-type = "riscv,sv39";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_1: cpu@1 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <1>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache0>;
+			mmu-type = "riscv,sv39";
+
+			cpu1_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_2: cpu@2 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <2>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache0>;
+			mmu-type = "riscv,sv39";
+
+			cpu2_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_3: cpu@3 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <3>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache0>;
+			mmu-type = "riscv,sv39";
+
+			cpu3_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_4: cpu@4 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <4>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache1>;
+			mmu-type = "riscv,sv39";
+
+			cpu4_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_5: cpu@5 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <5>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache1>;
+			mmu-type = "riscv,sv39";
+
+			cpu5_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_6: cpu@6 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <6>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache1>;
+			mmu-type = "riscv,sv39";
+
+			cpu6_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		cpu_7: cpu@7 {
+			compatible = "spacemit,x100", "riscv";
+			device_type = "cpu";
+			reg = <7>;
+			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";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			i-cache-block-size = <64>;
+			i-cache-size = <65536>;
+			i-cache-sets = <256>;
+			d-cache-block-size = <64>;
+			d-cache-size = <65536>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache1>;
+			mmu-type = "riscv,sv39";
+
+			cpu7_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				#interrupt-cells = <1>;
+				interrupt-controller;
+			};
+		};
+
+		l2_cache0: cache-controller-0 {
+			compatible = "cache";
+			cache-block-size = <64>;
+			cache-level = <2>;
+			cache-size = <4194304>;
+			cache-sets = <4096>;
+			cache-unified;
+		};
+
+		l2_cache1: cache-controller-1 {
+			compatible = "cache";
+			cache-block-size = <64>;
+			cache-level = <2>;
+			cache-size = <4194304>;
+			cache-sets = <4096>;
+			cache-unified;
+		};
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_0>;
+				};
+				core1 {
+					cpu = <&cpu_1>;
+				};
+				core2 {
+					cpu = <&cpu_2>;
+				};
+				core3 {
+					cpu = <&cpu_3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_4>;
+				};
+				core1 {
+					cpu = <&cpu_5>;
+				};
+				core2 {
+					cpu = <&cpu_6>;
+				};
+				core3 {
+					cpu = <&cpu_7>;
+				};
+			};
+		};
+	};
+
+	soc: soc {
+		compatible = "simple-bus";
+		interrupt-parent = <&saplic>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		dma-noncoherent;
+		ranges;
+
+		uart0: serial@d4017000 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017000 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart2: serial@d4017100 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017100 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart3: serial@d4017200 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017200 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart4: serial@d4017300 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017300 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart5: serial@d4017400 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017400 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart6: serial@d4017500 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017500 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart7: serial@d4017600 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017600 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart8: serial@d4017700 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017700 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart9: serial@d4017800 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd4017800 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart10: serial@d401f000 {
+			compatible = "spacemit,k3-uart", "intel,xscale-uart";
+			reg = <0x0 0xd401f000 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <14700000>;
+			interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		simsic: interrupt-controller@e0400000 {
+			compatible = "spacemit,k3-imsics","riscv,imsics";
+			reg = <0x0 0xe0400000 0x0 0x00200000>;
+			interrupt-controller;
+			#interrupt-cells = <0>;
+			msi-controller;
+			#msi-cells = <0>;
+			interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
+					      <&cpu2_intc 9>, <&cpu3_intc 9>,
+					      <&cpu4_intc 9>, <&cpu5_intc 9>,
+					      <&cpu6_intc 9>, <&cpu7_intc 9>;
+			riscv,num-ids = <511>;
+			riscv,num-guest-ids = <511>;
+			riscv,hart-index-bits = <4>;
+			riscv,guest-index-bits = <6>;
+		};
+
+		saplic: interrupt-controller@e0804000 {
+			compatible = "spacemit,k3-aplic", "riscv,aplic";
+			reg = <0x0 0xe0804000 0x0 0x4000>;
+			msi-parent = <&simsic>;
+			#interrupt-cells = <2>;
+			interrupt-controller;
+			riscv,num-sources = <512>;
+		};
+
+		clint: timer@e081c000 {
+			compatible = "spacemit,k3-clint", "sifive,clint0";
+			reg = <0x0 0xe081c000 0x0 0x0004000>;
+			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
+					      <&cpu1_intc 3>, <&cpu1_intc 7>,
+					      <&cpu2_intc 3>, <&cpu2_intc 7>,
+					      <&cpu3_intc 3>, <&cpu3_intc 7>,
+					      <&cpu4_intc 3>, <&cpu4_intc 7>,
+					      <&cpu5_intc 3>, <&cpu5_intc 7>,
+					      <&cpu6_intc 3>, <&cpu6_intc 7>,
+					      <&cpu7_intc 3>, <&cpu7_intc 7>;
+		};
+	};
+};

-- 
2.43.0

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

[Heinrich Schuchardt]

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@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@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@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?

Best regards

Heinrich

> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache0>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu0_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_1: cpu@1 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <1>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache0>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu1_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_2: cpu@2 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <2>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache0>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu2_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_3: cpu@3 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <3>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache0>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu3_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_4: cpu@4 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <4>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache1>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu4_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_5: cpu@5 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <5>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache1>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu5_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_6: cpu@6 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <6>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache1>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu6_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		cpu_7: cpu@7 {
> +			compatible = "spacemit,x100", "riscv";
> +			device_type = "cpu";
> +			reg = <7>;
> +			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";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			i-cache-block-size = <64>;
> +			i-cache-size = <65536>;
> +			i-cache-sets = <256>;
> +			d-cache-block-size = <64>;
> +			d-cache-size = <65536>;
> +			d-cache-sets = <256>;
> +			next-level-cache = <&l2_cache1>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu7_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				#interrupt-cells = <1>;
> +				interrupt-controller;
> +			};
> +		};
> +
> +		l2_cache0: cache-controller-0 {
> +			compatible = "cache";
> +			cache-block-size = <64>;
> +			cache-level = <2>;
> +			cache-size = <4194304>;
> +			cache-sets = <4096>;
> +			cache-unified;
> +		};
> +
> +		l2_cache1: cache-controller-1 {
> +			compatible = "cache";
> +			cache-block-size = <64>;
> +			cache-level = <2>;
> +			cache-size = <4194304>;
> +			cache-sets = <4096>;
> +			cache-unified;
> +		};
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu_0>;
> +				};
> +				core1 {
> +					cpu = <&cpu_1>;
> +				};
> +				core2 {
> +					cpu = <&cpu_2>;
> +				};
> +				core3 {
> +					cpu = <&cpu_3>;
> +				};
> +			};
> +
> +			cluster1 {
> +				core0 {
> +					cpu = <&cpu_4>;
> +				};
> +				core1 {
> +					cpu = <&cpu_5>;
> +				};
> +				core2 {
> +					cpu = <&cpu_6>;
> +				};
> +				core3 {
> +					cpu = <&cpu_7>;
> +				};
> +			};
> +		};
> +	};
> +
> +	soc: soc {
> +		compatible = "simple-bus";
> +		interrupt-parent = <&saplic>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		dma-noncoherent;
> +		ranges;
> +
> +		uart0: serial@d4017000 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017000 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart2: serial@d4017100 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017100 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart3: serial@d4017200 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017200 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart4: serial@d4017300 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017300 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart5: serial@d4017400 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017400 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart6: serial@d4017500 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017500 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart7: serial@d4017600 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017600 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart8: serial@d4017700 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017700 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart9: serial@d4017800 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd4017800 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		uart10: serial@d401f000 {
> +			compatible = "spacemit,k3-uart", "intel,xscale-uart";
> +			reg = <0x0 0xd401f000 0x0 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <14700000>;
> +			interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
> +
> +		simsic: interrupt-controller@e0400000 {
> +			compatible = "spacemit,k3-imsics","riscv,imsics";
> +			reg = <0x0 0xe0400000 0x0 0x00200000>;
> +			interrupt-controller;
> +			#interrupt-cells = <0>;
> +			msi-controller;
> +			#msi-cells = <0>;
> +			interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
> +					      <&cpu2_intc 9>, <&cpu3_intc 9>,
> +					      <&cpu4_intc 9>, <&cpu5_intc 9>,
> +					      <&cpu6_intc 9>, <&cpu7_intc 9>;
> +			riscv,num-ids = <511>;
> +			riscv,num-guest-ids = <511>;
> +			riscv,hart-index-bits = <4>;
> +			riscv,guest-index-bits = <6>;
> +		};
> +
> +		saplic: interrupt-controller@e0804000 {
> +			compatible = "spacemit,k3-aplic", "riscv,aplic";
> +			reg = <0x0 0xe0804000 0x0 0x4000>;
> +			msi-parent = <&simsic>;
> +			#interrupt-cells = <2>;
> +			interrupt-controller;
> +			riscv,num-sources = <512>;
> +		};
> +
> +		clint: timer@e081c000 {
> +			compatible = "spacemit,k3-clint", "sifive,clint0";
> +			reg = <0x0 0xe081c000 0x0 0x0004000>;
> +			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> +					      <&cpu1_intc 3>, <&cpu1_intc 7>,
> +					      <&cpu2_intc 3>, <&cpu2_intc 7>,
> +					      <&cpu3_intc 3>, <&cpu3_intc 7>,
> +					      <&cpu4_intc 3>, <&cpu4_intc 7>,
> +					      <&cpu5_intc 3>, <&cpu5_intc 7>,
> +					      <&cpu6_intc 3>, <&cpu6_intc 7>,
> +					      <&cpu7_intc 3>, <&cpu7_intc 7>;
> +		};
> +	};
> +};
> 

Re: [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@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@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@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@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
>

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

[Heinrich Schuchardt]

On 12/17/25 08:11, Guodong Xu wrote:
> On Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
> <heinrich.schuchardt@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@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@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@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."

If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete 
with respect to ratified extensions, I guess the right approach is to 
amend it and not to curtail the CPU description.

Best regards

Heinrich

> 
> 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
>>

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> On 12/17/25 08:11, Guodong Xu wrote:

> > 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."
> 
> If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> with respect to ratified extensions, I guess the right approach is to amend
> it and not to curtail the CPU description.

Absolutely. If the cpu supports something that is not documented, then
please document it rather than omit from the devicetree.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Guodong Xu]

Hi, Conor and Heinrich

On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> > On 12/17/25 08:11, Guodong Xu wrote:
>
> > > 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."
> >
> > If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> > with respect to ratified extensions, I guess the right approach is to amend
> > it and not to curtail the CPU description.
>
> Absolutely. If the cpu supports something that is not documented, then
> please document it rather than omit from the devicetree.

Thanks for the review. May I clarify one thing? Both of you mentioned
document them, given the amount of missing extensions, is it acceptable if
I submit a prerequisite patch that only documents these strings in
riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
usage of these extensions (named features) to the future patches.

To provide some context on why I ask: I've investigated the commits & lkml
history of RISC-V extensions since v6.5, and I summarized the current status
regarding the RVA23 profile here:
[1] status in v6.18 (inc. v6.19-rc1):
https://docularxu.github.io/rva23/linux-kernel-coverage.html
[2] support evolution since v6.5:
https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html

Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
requires adding these extensions that are currently missing from
the kernel bindings:
RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
          Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
they are not literally documented in yaml.

Is this approach acceptable to you? If so, I will proceed with submitting them.

Thank you very much.

Best regards,
Guodong Xu

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

[Heinrich Schuchardt]

On 12/19/25 03:03, Guodong Xu wrote:
> Hi, Conor and Heinrich
> 
> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
>>
>> On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
>>> On 12/17/25 08:11, Guodong Xu wrote:
>>
>>>> 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."
>>>
>>> If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
>>> with respect to ratified extensions, I guess the right approach is to amend
>>> it and not to curtail the CPU description.
>>
>> Absolutely. If the cpu supports something that is not documented, then
>> please document it rather than omit from the devicetree.
> 
> Thanks for the review. May I clarify one thing? Both of you mentioned
> document them, given the amount of missing extensions, is it acceptable if
> I submit a prerequisite patch that only documents these strings in
> riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
> usage of these extensions (named features) to the future patches.

Adding the missing extensions to
Documentation/devicetree/bindings/riscv/extensions.yaml
is what it takes to describe the K100 cores in the device-tree.

Discovering the new extensions as CPU features and exposing them via 
hwprobe is probably best handled in a separate patch series.

Best regards

Heinrich

> 
> To provide some context on why I ask: I've investigated the commits & lkml
> history of RISC-V extensions since v6.5, and I summarized the current status
> regarding the RVA23 profile here:
> [1] status in v6.18 (inc. v6.19-rc1):
> https://docularxu.github.io/rva23/linux-kernel-coverage.html
> [2] support evolution since v6.5:
> https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
> 
> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> requires adding these extensions that are currently missing from
> the kernel bindings:
> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
>            Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
> they are not literally documented in yaml.
> 
> Is this approach acceptable to you? If so, I will proceed with submitting them.
> 
> Thank you very much.
> 
> Best regards,
> Guodong Xu

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

[Yao Zi]

On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> Hi, Conor and Heinrich
> 
> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> > > On 12/17/25 08:11, Guodong Xu wrote:
> >
> > > > 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."
> > >
> > > If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> > > with respect to ratified extensions, I guess the right approach is to amend
> > > it and not to curtail the CPU description.
> >
> > Absolutely. If the cpu supports something that is not documented, then
> > please document it rather than omit from the devicetree.
> 

...

> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> requires adding these extensions that are currently missing from
> the kernel bindings:
> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
>           Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but

Please note B is just the abbreviation of "zba", "zbb", and "zbs", all
of them have been documented in extensions.yaml.

> they are not literally documented in yaml.
> 
> Is this approach acceptable to you? If so, I will proceed with submitting them.
> 
> Thank you very much.
> 
> Best regards,
> Guodong Xu
> 

Regards,
Yao Zi

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

[Guodong Xu]

On Sat, Dec 20, 2025 at 10:48 AM Yao Zi <me@ziyao.cc> wrote:
>
> On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> > Hi, Conor and Heinrich
> >
> > On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
> > >
> > > On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> > > > On 12/17/25 08:11, Guodong Xu wrote:
> > >
> > > > > 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."
> > > >
> > > > If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> > > > with respect to ratified extensions, I guess the right approach is to amend
> > > > it and not to curtail the CPU description.
> > >
> > > Absolutely. If the cpu supports something that is not documented, then
> > > please document it rather than omit from the devicetree.
> >
>
> ...
>
> > Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> > requires adding these extensions that are currently missing from
> > the kernel bindings:
> > RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> > RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
> >           Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> > Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
>
> Please note B is just the abbreviation of "zba", "zbb", and "zbs", all
> of them have been documented in extensions.yaml.
>

Yes, Yao Zi. I'll include 'B' in my next version, and add the schema check.
Thanks.

BR,
Guodong Xu

> > they are not literally documented in yaml.
> >
> > Is this approach acceptable to you? If so, I will proceed with submitting them.
> >
> > Thank you very much.
> >
> > Best regards,
> > Guodong Xu
> >
>
> Regards,
> Yao Zi

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> Hi, Conor and Heinrich
> 
> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> > > On 12/17/25 08:11, Guodong Xu wrote:
> >
> > > > 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."
> > >
> > > If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> > > with respect to ratified extensions, I guess the right approach is to amend
> > > it and not to curtail the CPU description.
> >
> > Absolutely. If the cpu supports something that is not documented, then
> > please document it rather than omit from the devicetree.
> 
> Thanks for the review. May I clarify one thing? Both of you mentioned
> document them, given the amount of missing extensions, is it acceptable if
> I submit a prerequisite patch that only documents these strings in
> riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
> usage of these extensions (named features) to the future patches.
> 
> To provide some context on why I ask: I've investigated the commits & lkml
> history of RISC-V extensions since v6.5, and I summarized the current status
> regarding the RVA23 profile here:
> [1] status in v6.18 (inc. v6.19-rc1):
> https://docularxu.github.io/rva23/linux-kernel-coverage.html
> [2] support evolution since v6.5:
> https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
> 
> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> requires adding these extensions that are currently missing from
> the kernel bindings:
> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
>           Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa


> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
> they are not literally documented in yaml.

I don't think Supm is suitable for devicetree, doesn't it describe
what the kernel/userspace are capable of rather than hardware?
Zic64b doesn't sound like hardware description (so not really suitable
for devicetree either) but block size information is already represented
by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml)
and duplicating that information is not really a great idea.

I'll admit that I do not really understand Sxstateen and how they work,
but my understanding was that knowing about Smstateen is sufficient and
implied Sstateen, but having Ssstateen defined seems harmless and
possible. I think kvm is the only user of this at the moment, so
probably worth CCing Anup and maybe Drew Jones on the patch adding
Ssstateen to make sure it makes sense.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Heinrich Schuchardt]

On 12/21/25 00:23, Conor Dooley wrote:
> On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
>> Hi, Conor and Heinrich
>>
>> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
>>>
>>> On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
>>>> On 12/17/25 08:11, Guodong Xu wrote:
>>>
>>>>> 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."
>>>>
>>>> If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
>>>> with respect to ratified extensions, I guess the right approach is to amend
>>>> it and not to curtail the CPU description.
>>>
>>> Absolutely. If the cpu supports something that is not documented, then
>>> please document it rather than omit from the devicetree.
>>
>> Thanks for the review. May I clarify one thing? Both of you mentioned
>> document them, given the amount of missing extensions, is it acceptable if
>> I submit a prerequisite patch that only documents these strings in
>> riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
>> usage of these extensions (named features) to the future patches.
>>
>> To provide some context on why I ask: I've investigated the commits & lkml
>> history of RISC-V extensions since v6.5, and I summarized the current status
>> regarding the RVA23 profile here:
>> [1] status in v6.18 (inc. v6.19-rc1):
>> https://docularxu.github.io/rva23/linux-kernel-coverage.html
>> [2] support evolution since v6.5:
>> https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
>>
>> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
>> requires adding these extensions that are currently missing from
>> the kernel bindings:
>> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
>> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
>>            Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> 
> 
>> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
>> they are not literally documented in yaml.
> 
> I don't think Supm is suitable for devicetree, doesn't it describe
> what the kernel/userspace are capable of rather than hardware?
> Zic64b doesn't sound like hardware description (so not really suitable
> for devicetree either) but block size information is already represented
> by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml)
> and duplicating that information is not really a great idea.
> 
> I'll admit that I do not really understand Sxstateen and how they work,
> but my understanding was that knowing about Smstateen is sufficient and
> implied Sstateen, but having Ssstateen defined seems harmless and
> possible. I think kvm is the only user of this at the moment, so
> probably worth CCing Anup and maybe Drew Jones on the patch adding
> Ssstateen to make sure it makes sense.

Supm is described in

RISC-V Pointer Masking
Version 1.0, 10/2024: Ratified
https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf

The interpretation taken by QEMU has been:

* Supm implies Ssnpm and Smnpm
* RVA23 capable machine models display it in the device-tree

If Supm is not shown in the device-tree, software might assume that the 
system does not support pointer masking in user mode and is not RVA23 
compliant.

Hence I would suggest:

If the X100 cores have Ssnpm and Smnpm, add Supm to the device-tree.

If the kernel does not support user space pointer masking, the kernel 
should filter out Supm and not announce it, neither in /proc/cpuinfo nor 
via hwprobe.

Best regards

Heinrich

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

[Guodong Xu]

Hi, Conor, Heinrich

On Sun, Dec 21, 2025 at 8:10 AM Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 12/21/25 00:23, Conor Dooley wrote:
> > On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> >> Hi, Conor and Heinrich
> >>
> >> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
> >>>
> >>> On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> >>>> On 12/17/25 08:11, Guodong Xu wrote:
> >>>
> >>>>> 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."
> >>>>
> >>>> If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> >>>> with respect to ratified extensions, I guess the right approach is to amend
> >>>> it and not to curtail the CPU description.
> >>>
> >>> Absolutely. If the cpu supports something that is not documented, then
> >>> please document it rather than omit from the devicetree.
> >>
> >> Thanks for the review. May I clarify one thing? Both of you mentioned
> >> document them, given the amount of missing extensions, is it acceptable if
> >> I submit a prerequisite patch that only documents these strings in
> >> riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
> >> usage of these extensions (named features) to the future patches.
> >>
> >> To provide some context on why I ask: I've investigated the commits & lkml
> >> history of RISC-V extensions since v6.5, and I summarized the current status
> >> regarding the RVA23 profile here:
> >> [1] status in v6.18 (inc. v6.19-rc1):
> >> https://docularxu.github.io/rva23/linux-kernel-coverage.html
> >> [2] support evolution since v6.5:
> >> https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
> >>
> >> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> >> requires adding these extensions that are currently missing from
> >> the kernel bindings:
> >> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> >> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
> >>            Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> >
> >
> >> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
> >> they are not literally documented in yaml.
> >
> > I don't think Supm is suitable for devicetree, doesn't it describe
> > what the kernel/userspace are capable of rather than hardware?

I see your point. While the Pointer Masking spec (v1.0) does distinguishes
Supm (and Sspm) as extensions describing an execution environment, it also
states these are intended to be used in profile specs.

With RVA23 ratification, Supm is formally included as a mandatory extension
in the RVA23S64 profile.

If riscv,isa-extensions property is the standard way (and I believe it is)
to describe a RISC-V CPU about its compliance with ratified profile, then I
believe Supm should be included in the YAML binding, alongside other
extensions.

> > Zic64b doesn't sound like hardware description (so not really suitable
> > for devicetree either) but block size information is already represented
> > by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml)
> > and duplicating that information is not really a great idea.

Yes. Thanks for clarifying this.

Even Zic64b can be add, then some kind of schema check should be implemented
to avoid the potential and possible mismatch, and ensure
riscv,cob*-block-size in cpus.yaml are 64 bytes. Duplication is not good.

> >
> > I'll admit that I do not really understand Sxstateen and how they work,
> > but my understanding was that knowing about Smstateen is sufficient and
> > implied Sstateen, but having Ssstateen defined seems harmless and
> > possible. I think kvm is the only user of this at the moment, so
> > probably worth CCing Anup and maybe Drew Jones on the patch adding
> > Ssstateen to make sure it makes sense.

I will Cc them. Thanks for your advice.

>
> Supm is described in
>
> RISC-V Pointer Masking
> Version 1.0, 10/2024: Ratified
> https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf
>
> The interpretation taken by QEMU has been:
>
> * Supm implies Ssnpm and Smnpm
> * RVA23 capable machine models display it in the device-tree
>
> If Supm is not shown in the device-tree, software might assume that the
> system does not support pointer masking in user mode and is not RVA23
> compliant.
>
> Hence I would suggest:
>
> If the X100 cores have Ssnpm and Smnpm, add Supm to the device-tree.

Thanks. Heinrich.
Let me add Supm in my next version.

BR,
Guodong

>
> If the kernel does not support user space pointer masking, the kernel
> should filter out Supm and not announce it, neither in /proc/cpuinfo nor
> via hwprobe.
>
> Best regards
>
> Heinrich

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5219 bytes --]

Heinrich, Samuel,

On Sun, Dec 21, 2025 at 01:10:15AM +0100, Heinrich Schuchardt wrote:
> On 12/21/25 00:23, Conor Dooley wrote:
> > On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> > > Hi, Conor and Heinrich
> > > 
> > > On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
> > > > 
> > > > On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> > > > > On 12/17/25 08:11, Guodong Xu wrote:
> > > > 
> > > > > > 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."
> > > > > 
> > > > > If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> > > > > with respect to ratified extensions, I guess the right approach is to amend
> > > > > it and not to curtail the CPU description.
> > > > 
> > > > Absolutely. If the cpu supports something that is not documented, then
> > > > please document it rather than omit from the devicetree.
> > > 
> > > Thanks for the review. May I clarify one thing? Both of you mentioned
> > > document them, given the amount of missing extensions, is it acceptable if
> > > I submit a prerequisite patch that only documents these strings in
> > > riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
> > > usage of these extensions (named features) to the future patches.
> > > 
> > > To provide some context on why I ask: I've investigated the commits & lkml
> > > history of RISC-V extensions since v6.5, and I summarized the current status
> > > regarding the RVA23 profile here:
> > > [1] status in v6.18 (inc. v6.19-rc1):
> > > https://docularxu.github.io/rva23/linux-kernel-coverage.html
> > > [2] support evolution since v6.5:
> > > https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
> > > 
> > > Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> > > requires adding these extensions that are currently missing from
> > > the kernel bindings:
> > > RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> > > RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
> > >            Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> > 
> > 
> > > Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
> > > they are not literally documented in yaml.
> > 
> > I don't think Supm is suitable for devicetree, doesn't it describe
> > what the kernel/userspace are capable of rather than hardware?
> > Zic64b doesn't sound like hardware description (so not really suitable
> > for devicetree either) but block size information is already represented
> > by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml)
> > and duplicating that information is not really a great idea.
> > 
> > I'll admit that I do not really understand Sxstateen and how they work,
> > but my understanding was that knowing about Smstateen is sufficient and
> > implied Sstateen, but having Ssstateen defined seems harmless and
> > possible. I think kvm is the only user of this at the moment, so
> > probably worth CCing Anup and maybe Drew Jones on the patch adding
> > Ssstateen to make sure it makes sense.
> 
> Supm is described in
> 
> RISC-V Pointer Masking
> Version 1.0, 10/2024: Ratified
> https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf
> 
> The interpretation taken by QEMU has been:
> 
> * Supm implies Ssnpm and Smnpm
> * RVA23 capable machine models display it in the device-tree
> 
> If Supm is not shown in the device-tree, software might assume that the
> system does not support pointer masking in user mode and is not RVA23
> compliant.
> 
> Hence I would suggest:
> 
> If the X100 cores have Ssnpm and Smnpm, add Supm to the device-tree.
> 
> If the kernel does not support user space pointer masking, the kernel should
> filter out Supm and not announce it, neither in /proc/cpuinfo nor via
> hwprobe.

Samuel seems to have some specific thoughts on how this works, given he
didn't blindly implement ssnpm and smnpm, but has made supm be mode
dependent and not permitted in dt, hopefully he sees this.

Personally I'm not convinced that putting supm in dt makes sense, but
instead the kernel should imply it if the sxnpm extension matching the
mode the kernel is operating in is present and RISCV_ISA_SUPM is set in
Kconfig. That's effectively how it works at present, except it'd involve
promoting RISCV_ISA_SUPM to a "real" extension instead of being a macro.
A validate callback should easily be able to handle checking the
mode and whether the Kconfig option is set.
That way it would get exposed to userspace using the actual mechanisms,
reading the devicetree itself from userspace is not a valid way of
checking what extensions are usable after all.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Guodong Xu]

On Tue, Dec 23, 2025 at 4:36 AM Conor Dooley <conor@kernel.org> wrote:
>
> Heinrich, Samuel,
>
> On Sun, Dec 21, 2025 at 01:10:15AM +0100, Heinrich Schuchardt wrote:
> > On 12/21/25 00:23, Conor Dooley wrote:
> > > On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> > > > Hi, Conor and Heinrich
> > > >
> > > > On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@kernel.org> wrote:
> > > > >
> > > > > On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> > > > > > On 12/17/25 08:11, Guodong Xu wrote:
> > > > >
> > > > > > > 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."
> > > > > >
> > > > > > If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> > > > > > with respect to ratified extensions, I guess the right approach is to amend
> > > > > > it and not to curtail the CPU description.
> > > > >
> > > > > Absolutely. If the cpu supports something that is not documented, then
> > > > > please document it rather than omit from the devicetree.
> > > >
> > > > Thanks for the review. May I clarify one thing? Both of you mentioned
> > > > document them, given the amount of missing extensions, is it acceptable if
> > > > I submit a prerequisite patch that only documents these strings in
> > > > riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
> > > > usage of these extensions (named features) to the future patches.
> > > >
> > > > To provide some context on why I ask: I've investigated the commits & lkml
> > > > history of RISC-V extensions since v6.5, and I summarized the current status
> > > > regarding the RVA23 profile here:
> > > > [1] status in v6.18 (inc. v6.19-rc1):
> > > > https://docularxu.github.io/rva23/linux-kernel-coverage.html
> > > > [2] support evolution since v6.5:
> > > > https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
> > > >
> > > > Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> > > > requires adding these extensions that are currently missing from
> > > > the kernel bindings:
> > > > RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> > > > RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
> > > >            Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> > >
> > >
> > > > Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
> > > > they are not literally documented in yaml.
> > >
> > > I don't think Supm is suitable for devicetree, doesn't it describe
> > > what the kernel/userspace are capable of rather than hardware?
> > > Zic64b doesn't sound like hardware description (so not really suitable
> > > for devicetree either) but block size information is already represented
> > > by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml)
> > > and duplicating that information is not really a great idea.
> > >
> > > I'll admit that I do not really understand Sxstateen and how they work,
> > > but my understanding was that knowing about Smstateen is sufficient and
> > > implied Sstateen, but having Ssstateen defined seems harmless and
> > > possible. I think kvm is the only user of this at the moment, so
> > > probably worth CCing Anup and maybe Drew Jones on the patch adding
> > > Ssstateen to make sure it makes sense.
> >
> > Supm is described in
> >
> > RISC-V Pointer Masking
> > Version 1.0, 10/2024: Ratified
> > https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf
> >
> > The interpretation taken by QEMU has been:
> >
> > * Supm implies Ssnpm and Smnpm
> > * RVA23 capable machine models display it in the device-tree
> >
> > If Supm is not shown in the device-tree, software might assume that the
> > system does not support pointer masking in user mode and is not RVA23
> > compliant.
> >
> > Hence I would suggest:
> >
> > If the X100 cores have Ssnpm and Smnpm, add Supm to the device-tree.
> >
> > If the kernel does not support user space pointer masking, the kernel should
> > filter out Supm and not announce it, neither in /proc/cpuinfo nor via
> > hwprobe.
>
> Samuel seems to have some specific thoughts on how this works, given he
> didn't blindly implement ssnpm and smnpm, but has made supm be mode
> dependent and not permitted in dt, hopefully he sees this.
>
> Personally I'm not convinced that putting supm in dt makes sense, but
> instead the kernel should imply it if the sxnpm extension matching the
> mode the kernel is operating in is present and RISCV_ISA_SUPM is set in
> Kconfig. That's effectively how it works at present, except it'd involve
> promoting RISCV_ISA_SUPM to a "real" extension instead of being a macro.
> A validate callback should easily be able to handle checking the
> mode and whether the Kconfig option is set.

Hi, Conor

As we wait for Samuel to share his opinion, maybe I can submit a patch in
(I already have it)
my next version or as in a different patchset to implement what you suggested.
 - Assign RISCV_ISA_EXT_SUPM a standalone ext number in hwcap.h
 - Implement a riscv_ext_supm_validate() and put it in the callback of both
    ssnpm and smnpm.
 - Kconfig will be kept as a top level gatekeeper, no change.
 - dt-binding entry for supm will not be added.

The only reason support me to add sump into to the dt binding
(extensions.yaml) is it's now a mandatory extension required by RVA23U64.
However, as you explained, that logic seems not strong enough.

Thank you.
Best regards,
Guodong Xu

> That way it would get exposed to userspace using the actual mechanisms,
> reading the devicetree itself from userspace is not a valid way of
> checking what extensions are usable after all.
>

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

[Krzysztof Kozlowski]

On 16/12/2025 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@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@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;

These are not properties of the soc, but the board DTS.

Best regards,
Krzysztof

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

[Guodong Xu]

On Tue, Dec 16, 2025 at 11:35 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/12/2025 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@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@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;
>
> These are not properties of the soc, but the board DTS.

Thank you Krzysztof, I will fix that in the next version.

Best regards,
Guodong Xu

>
> Best regards,
> Krzysztof

[PATCH 8/8] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

[Guodong Xu]

K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
K3 SoC.

This minimal device tree enables booting into a serial console with UART
output.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 arch/riscv/boot/dts/spacemit/Makefile        |  1 +
 arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 25 +++++++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 95889e7269d1bae679b28cd053e1b0a23ae6de68..7e2b877025718113a0e31917eadf7562f488d825 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
 dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
 dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
 dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
new file mode 100644
index 0000000000000000000000000000000000000000..0f9d04dd352f5331e82599285113b86af5b09ebe
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
+ * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
+ */
+
+#include "k3.dtsi"
+
+/ {
+	model = "SpacemiT K3 Pico-ITX";
+	compatible = "spacemit,k3-pico-itx", "spacemit,k3";
+
+	chosen {
+		stdout-path = "serial0";
+	};
+
+	memory@100200000 {
+		device_type = "memory";
+		reg = <0x1 0x00200000 0x3 0xffe00000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};

-- 
2.43.0

Re: [PATCH 8/8] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

[Heinrich Schuchardt]

On 12/16/25 14:32, Guodong Xu wrote:
> K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
> K3 SoC.
> 
> This minimal device tree enables booting into a serial console with UART
> output.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>   arch/riscv/boot/dts/spacemit/Makefile        |  1 +
>   arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 25 +++++++++++++++++++++++++
>   2 files changed, 26 insertions(+)
> 
> diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> index 95889e7269d1bae679b28cd053e1b0a23ae6de68..7e2b877025718113a0e31917eadf7562f488d825 100644
> --- a/arch/riscv/boot/dts/spacemit/Makefile
> +++ b/arch/riscv/boot/dts/spacemit/Makefile
> @@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
>   dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
>   dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
>   dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
> +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
> diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> new file mode 100644
> index 0000000000000000000000000000000000000000..0f9d04dd352f5331e82599285113b86af5b09ebe
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
> + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
> + */
> +
> +#include "k3.dtsi"
> +
> +/ {
> +	model = "SpacemiT K3 Pico-ITX";
> +	compatible = "spacemit,k3-pico-itx", "spacemit,k3";
> +
> +	chosen {
> +		stdout-path = "serial0";
> +	};
> +
> +	memory@100200000 {
> +		device_type = "memory";
> +		reg = <0x1 0x00200000 0x3 0xffe00000>;

Shouldn't the reserved memory be described as no-map /reserved-memory 
nodes instead?

I would assume that 0x1,0000,0000 is the location of OpenSBI.
What is at 0x3,ffe0,0000?

Best regards

Heinrich

> +	};
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> 

Re: [PATCH 8/8] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

[Guodong Xu]

On Tue, Dec 16, 2025 at 10:33 PM Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 12/16/25 14:32, Guodong Xu wrote:
> > K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
> > K3 SoC.
> >
> > This minimal device tree enables booting into a serial console with UART
> > output.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >   arch/riscv/boot/dts/spacemit/Makefile        |  1 +
> >   arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 25 +++++++++++++++++++++++++
> >   2 files changed, 26 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> > index 95889e7269d1bae679b28cd053e1b0a23ae6de68..7e2b877025718113a0e31917eadf7562f488d825 100644
> > --- a/arch/riscv/boot/dts/spacemit/Makefile
> > +++ b/arch/riscv/boot/dts/spacemit/Makefile
> > @@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
> >   dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
> >   dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
> >   dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
> > +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
> > diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..0f9d04dd352f5331e82599285113b86af5b09ebe
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> > @@ -0,0 +1,25 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
> > + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
> > + */
> > +
> > +#include "k3.dtsi"
> > +
> > +/ {
> > +     model = "SpacemiT K3 Pico-ITX";
> > +     compatible = "spacemit,k3-pico-itx", "spacemit,k3";
> > +
> > +     chosen {
> > +             stdout-path = "serial0";
> > +     };
> > +
> > +     memory@100200000 {
> > +             device_type = "memory";
> > +             reg = <0x1 0x00200000 0x3 0xffe00000>;
>
> Shouldn't the reserved memory be described as no-map /reserved-memory
> nodes instead?

Hi Heinrich,

Yes, you are right. Using a reserved-memory node with the no-map property is
the correct approach. I will update this in the next version to explicitly
reserve the first 2MB.

>
> I would assume that 0x1,0000,0000 is the location of OpenSBI.
> What is at 0x3,ffe0,0000?

Yes, confirmed, 0x100000000 is the start of OpenSBI. The size 0x3ffe00000 in
my original patch was the result of manually subtracting the 2MB OpenSBI
offset from the total 16GB memory.

I will correct this in v2 to show the actual memory and put the first 2MB in
reserved-memory {} for opensbi.

Thanks for the review.

BR,
Guodong Xu


>
> Best regards
>
> Heinrich
>
> > +     };
> > +};
> > +
> > +&uart0 {
> > +     status = "okay";
> > +};
> >
>

Re: [PATCH 8/8] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

[Bo Gan]

Hi Guodong,

On 12/16/25 23:13, Guodong Xu wrote:
> On Tue, Dec 16, 2025 at 10:33 PM Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> wrote:
>>
>> On 12/16/25 14:32, Guodong Xu wrote:
>>> K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
>>> K3 SoC.
>>>
>>> This minimal device tree enables booting into a serial console with UART
>>> output.
>>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>>    arch/riscv/boot/dts/spacemit/Makefile        |  1 +
>>>    arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 25 +++++++++++++++++++++++++
>>>    2 files changed, 26 insertions(+)
>>>
>>> diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
>>> index 95889e7269d1bae679b28cd053e1b0a23ae6de68..7e2b877025718113a0e31917eadf7562f488d825 100644
>>> --- a/arch/riscv/boot/dts/spacemit/Makefile
>>> +++ b/arch/riscv/boot/dts/spacemit/Makefile
>>> @@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
>>>    dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
>>>    dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
>>>    dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
>>> +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
>>> diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..0f9d04dd352f5331e82599285113b86af5b09ebe
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
>>> @@ -0,0 +1,25 @@
>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>> +/*
>>> + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
>>> + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
>>> + */
>>> +
>>> +#include "k3.dtsi"
>>> +
>>> +/ {
>>> +     model = "SpacemiT K3 Pico-ITX";
>>> +     compatible = "spacemit,k3-pico-itx", "spacemit,k3";
>>> +
>>> +     chosen {
>>> +             stdout-path = "serial0";
>>> +     };
>>> +
>>> +     memory@100200000 {
>>> +             device_type = "memory";
>>> +             reg = <0x1 0x00200000 0x3 0xffe00000>;
>>
>> Shouldn't the reserved memory be described as no-map /reserved-memory
>> nodes instead?
> 
> Hi Heinrich,
> 
> Yes, you are right. Using a reserved-memory node with the no-map property is
> the correct approach. I will update this in the next version to explicitly
> reserve the first 2MB.
> 
>>
>> I would assume that 0x1,0000,0000 is the location of OpenSBI.
>> What is at 0x3,ffe0,0000?
> 
> Yes, confirmed, 0x100000000 is the start of OpenSBI. The size 0x3ffe00000 in
> my original patch was the result of manually subtracting the 2MB OpenSBI
> offset from the total 16GB memory.
> 
> I will correct this in v2 to show the actual memory and put the first 2MB in
> reserved-memory {} for opensbi.

I don't think this is the right approach. The Linux kernel shouldn't care
about the size of the underlying SBI implementation. The size of OpenSBI
also depends on the version and features enabled. Thus, you should just
let the OpenSBI or whatever SBI fix up the device-tree for you. OpenSBI
already does that today. It inserts one or more reserved-memory node and
carves out the memory region of its own. If there's some bootloader in
between SBI <-> Linux, such as U-boot, then it's responsible for copying
over those reserved regions from OpenSBI into the device-tree Linux uses
(U-boot already does). Thus, there's no need to manually specify it.

Bo

> 
> Thanks for the review.
> 
> BR,
> Guodong Xu
> 
> 
>>
>> Best regards
>>
>> Heinrich
>>
>>> +     };
>>> +};
>>> +
>>> +&uart0 {
>>> +     status = "okay";
>>> +};
>>>
>>
>

Re: [PATCH 8/8] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

[Guodong Xu]

Hi, Bo

On Wed, Dec 17, 2025 at 5:06 PM Bo Gan <ganboing@gmail.com> wrote:
>
> Hi Guodong,
>
> On 12/16/25 23:13, Guodong Xu wrote:
> > On Tue, Dec 16, 2025 at 10:33 PM Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>
> >> On 12/16/25 14:32, Guodong Xu wrote:
> >>> K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
> >>> K3 SoC.
> >>>
> >>> This minimal device tree enables booting into a serial console with UART
> >>> output.
> >>>
> >>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> >>> ---
> >>>    arch/riscv/boot/dts/spacemit/Makefile        |  1 +
> >>>    arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 25 +++++++++++++++++++++++++
> >>>    2 files changed, 26 insertions(+)
> >>>
> >>> diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> >>> index 95889e7269d1bae679b28cd053e1b0a23ae6de68..7e2b877025718113a0e31917eadf7562f488d825 100644
> >>> --- a/arch/riscv/boot/dts/spacemit/Makefile
> >>> +++ b/arch/riscv/boot/dts/spacemit/Makefile
> >>> @@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
> >>>    dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
> >>>    dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
> >>>    dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
> >>> +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
> >>> diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> >>> new file mode 100644
> >>> index 0000000000000000000000000000000000000000..0f9d04dd352f5331e82599285113b86af5b09ebe
> >>> --- /dev/null
> >>> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> >>> @@ -0,0 +1,25 @@
> >>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>> +/*
> >>> + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
> >>> + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
> >>> + */
> >>> +
> >>> +#include "k3.dtsi"
> >>> +
> >>> +/ {
> >>> +     model = "SpacemiT K3 Pico-ITX";
> >>> +     compatible = "spacemit,k3-pico-itx", "spacemit,k3";
> >>> +
> >>> +     chosen {
> >>> +             stdout-path = "serial0";
> >>> +     };
> >>> +
> >>> +     memory@100200000 {
> >>> +             device_type = "memory";
> >>> +             reg = <0x1 0x00200000 0x3 0xffe00000>;
> >>
> >> Shouldn't the reserved memory be described as no-map /reserved-memory
> >> nodes instead?
> >
> > Hi Heinrich,
> >
> > Yes, you are right. Using a reserved-memory node with the no-map property is
> > the correct approach. I will update this in the next version to explicitly
> > reserve the first 2MB.
> >
> >>
> >> I would assume that 0x1,0000,0000 is the location of OpenSBI.
> >> What is at 0x3,ffe0,0000?
> >
> > Yes, confirmed, 0x100000000 is the start of OpenSBI. The size 0x3ffe00000 in
> > my original patch was the result of manually subtracting the 2MB OpenSBI
> > offset from the total 16GB memory.
> >
> > I will correct this in v2 to show the actual memory and put the first 2MB in
> > reserved-memory {} for opensbi.
>
> I don't think this is the right approach. The Linux kernel shouldn't care
> about the size of the underlying SBI implementation. The size of OpenSBI
> also depends on the version and features enabled. Thus, you should just

Thanks for the review. You are correct and I confirmed with the U-Boot
which we are currently using on the K3 Pico board can handle this memory
reservation situation. And it should, as you said. U-Boot
has first-hand information about where and what it wants to reserve.

> let the OpenSBI or whatever SBI fix up the device-tree for you. OpenSBI
> already does that today. It inserts one or more reserved-memory node and
> carves out the memory region of its own. If there's some bootloader in
> between SBI <-> Linux, such as U-boot, then it's responsible for copying
> over those reserved regions from OpenSBI into the device-tree Linux uses
> (U-boot already does). Thus, there's no need to manually specify it.

Agree. Back to the K3 Pico DTS, next version, I will describe memory layout
as what it is on the board.
memory@100000000 # starts from 4G

BR,
Guodong Xu

>
> Bo
>
> >
> > Thanks for the review.
> >
> > BR,
> > Guodong Xu
> >
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>> +     };
> >>> +};
> >>> +
> >>> +&uart0 {
> >>> +     status = "okay";
> >>> +};
> >>>
> >>
> >