Message-ID: <F93D26A6-60BE-4D50-A0BF-4BDF240149BE@gmx.de>
Date: Thu, 15 Jan 2026 07:19:05 +0100
From: Heinrich Schuchardt <xypron.glpk@....de>
To: Samuel Holland <samuel.holland@...ive.com>, Guodong Xu <guodong@...cstar.com>
CC: Paul Walmsley <paul.walmsley@...ive.com>, Conor Dooley <conor@...nel.org>,
 Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>,
 Andrew Jones <ajones@...tanamicro.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>, 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 v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC

Am 15. Januar 2026 00:57:04 MEZ schrieb Samuel Holland <samuel.holland@...ive.com>:
>Hi Guodong,
>
>On 2026-01-09 3:58 AM, Guodong Xu wrote:
>> Hi, Samuel
>> 
>> On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland <samuel.holland@...ive.com> wrote:
>>>
>>> On 2026-01-08 6:26 AM, 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@...cstar.com>
>>>> ---
>>>> v3: Remove "supm" from the riscv,isa-extensions list.
>>>> v2: Remove aliases from k3.dtsi, they should be in board DTS.
>>>>     Updated riscv,isa-extensions with new extensions from the extensions.yaml
>>>> ---
>>>>  arch/riscv/boot/dts/spacemit/k3.dtsi | 548 +++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 548 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..be9335fba32cb9e81915b2b91cf08c55a5e96809
>>>> --- /dev/null
>>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>>> [...]
>>>> +                     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@...04000 {
>>>> +                     compatible = "spacemit,k3-aplic", "riscv,aplic";
>>>> +                     reg = <0x0 0xe0804000 0x0 0x4000>;
>>>> +                     msi-parent = <&simsic>;
>>>> +                     #interrupt-cells = <2>;
>>>> +                     interrupt-controller;
>>>> +                     riscv,num-sources = <512>;
>>>> +             };
>>>
>>> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be
>>> represented in the devicetree as well, for M-mode firmware to access them, just
>>> like the CLINT below.
>> 
>> Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the
>> boot firmware (U-Boot) transfers information about these nodes to OpenSBI.
>> However, you are correct that they should be properly described in the DT.
>> 
>> In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic)
>> nodes to k3.dtsi, for topology representation and potential firmware usage.
>> I will set their status to "disabled" because exposing them as "okay" to Linux
>> causes access faults during driver probing.
>> 
>> Please let me know if this approach (adding them but keeping them disabled)
>> looks okay to you.
>
>I think this is a reasonable compromise.
>
>Personally, I think of the DTS files in the Linux repository as the "static"
>devicetree, which should describe a "complete" view of the hardware--that is, as
>seen from the highest privilege level. Then it is the responsibility of that
>highly-privileged software to modify the FDT as needed to provide a limited view
>of the hardware to lower-privileged software. And this modification is exactly
>what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree
>would not disable these M-mode-only devices.
>
>However, I recognize that people want to use the DTB files generated by the
>Linux build process with Linux directly, ignoring the firmware-provided FDT. In
>that cases the M-mode-only devices need to be disabled. And then you need a
>-u-boot.dtsi file to set `status = "okay"` for the firmware build. I think

U-Boot offers the EFI_DT_FIXUP_PROTOCOL (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) to adjust device-trees loaded by systemd-boot or GRUB.

The disabling should be done there to avoid having different device-trees in firmware and Linux code.

A pull request for providing the protocol in EDK II is pending.

Best regards

Heinrich

>that's a reasonable compromise to make the "static" devicetree as complete as
>possible while still being usable directly in S-mode in some cases. (It still
>breaks if some peripheral is assigned to a different supervisor domain, or some
>DRAM is reserved by M-mode, etc., which is why I really recommend using the
>firmware FDT and not a file.)
>
>Regards,
>Samuel
>

Powered by blists - more mailing lists