[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH1PCMaRrw1zu41oKpBO+5DpDU2Ri69TQEQa+4tXkZJtEuQDHw@mail.gmail.com>
Date: Fri, 19 Dec 2025 06:43:52 +0800
From: Guodong Xu <guodong@...cstar.com>
To: Bo Gan <ganboing@...il.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
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
Hi, Bo
On Wed, Dec 17, 2025 at 5:06 PM Bo Gan <ganboing@...il.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@...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.
>
> 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@...000000 # starts from 4G
BR,
Guodong Xu
>
> Bo
>
> >
> > Thanks for the review.
> >
> > BR,
> > Guodong Xu
> >
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>> + };
> >>> +};
> >>> +
> >>> +&uart0 {
> >>> + status = "okay";
> >>> +};
> >>>
> >>
> >
Powered by blists - more mailing lists