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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH1PCMbzv_uggyZ3JLPyWXSwbe2dJAh7jVT64xpM6SLG77VZqQ@mail.gmail.com>
Date: Wed, 17 Dec 2025 15:13:50 +0800
From: Guodong Xu <guodong@...cstar.com>
To: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>, Conor Dooley <conor@...nel.org>, 
	Heinrich Schuchardt <xypron.glpk@....de>, Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>, 
	devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, spacemit@...ts.linux.dev, 
	linux-serial@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Paul Walmsley <pjw@...nel.org>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	Alexandre Ghiti <alex@...ti.fr>, Yixun Lan <dlan@...too.org>, 
	Daniel Lezcano <daniel.lezcano@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Samuel Holland <samuel.holland@...ive.com>, Anup Patel <anup@...infault.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Lubomir Rintel <lkundrak@...sk>, Yangyu Chen <cyy@...self.name>
Subject: Re: [PATCH 8/8] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board
 device tree

On Tue, Dec 16, 2025 at 10:33 PM Heinrich Schuchardt
<heinrich.schuchardt@...onical.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@...cstar.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@...cstar.com>
> > + */
> > +
> > +#include "k3.dtsi"
> > +
> > +/ {
> > +     model = "SpacemiT K3 Pico-ITX";
> > +     compatible = "spacemit,k3-pico-itx", "spacemit,k3";
> > +
> > +     chosen {
> > +             stdout-path = "serial0";
> > +     };
> > +
> > +     memory@...200000 {
> > +             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";
> > +};
> >
>