[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 at 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 at 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 at 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 at riscstar.com>
> >>> + */
> >>> +
> >>> +#include "k3.dtsi"
> >>> +
> >>> +/ {
> >>> +     model = "SpacemiT K3 Pico-ITX";
> >>> +     compatible = "spacemit,k3-pico-itx", "spacemit,k3";
> >>> +
> >>> +     chosen {
> >>> +             stdout-path = "serial0";
> >>> +     };
> >>> +
> >>> +     memory at 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 at 100000000 # starts from 4G

BR,
Guodong Xu

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