Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
module which is powered by T-HEAD's TH1520 SoC. Add minimal device
tree files for the core module and the development board.
Support basic uart/gpio/dmac drivers, so supports booting to a basic
shell.
NOTE: the thead cpu reset dt-binding and DT node are removed in v3. This
makes secondary CPUs unable to be online. However, minimal th1520
support is better than nothing. And the community has been working on
and will work on the cpu reset dt-binding, for example, Conor, Guo and
Jessica are discussing about it, I have seen valuable comments and
inputs from them. I believe we can add back cpu reset in next
development window.
Thanks
Since v2:
- remove thead cpu-rst dt-binding doc and its DT node from th1520.dtsi
- collect Reviewed-by and Acked-by tags
- update uart reg size as suggested by Yixun
- Add Guo Ren and Fu Wei as THEAD SoCs Maintainers
Since v1:
- add missing plic, clint, th1520 itself dt-bindings
- use c900-plic
- s/light/th1520
- add dt-binding for T-HEAD CPU reset
- enable ARCH_THEAD in defconfig
- fix all dtbs_check error/warning except the CPU RESET, see above.
Jisheng Zhang (8):
dt-bindings: interrupt-controller: Add T-HEAD's TH1520 PLIC
dt-bindings: timer: Add T-HEAD TH1520 clint
dt-bindings: riscv: Add T-HEAD TH1520 board compatibles
riscv: Add the T-HEAD SoC family Kconfig option
riscv: dts: add initial T-HEAD TH1520 SoC device tree
riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
MAINTAINERS: add entry for T-HEAD RISC-V SoC
riscv: defconfig: enable T-HEAD SoC
.../sifive,plic-1.0.0.yaml | 1 +
.../devicetree/bindings/riscv/thead.yaml | 29 ++
.../bindings/timer/sifive,clint.yaml | 1 +
MAINTAINERS | 8 +
arch/riscv/Kconfig.socs | 6 +
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/thead/Makefile | 2 +
.../dts/thead/th1520-lichee-module-4a.dtsi | 38 ++
.../boot/dts/thead/th1520-lichee-pi-4a.dts | 32 ++
arch/riscv/boot/dts/thead/th1520.dtsi | 422 ++++++++++++++++++
arch/riscv/configs/defconfig | 1 +
11 files changed, 541 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/thead.yaml
create mode 100644 arch/riscv/boot/dts/thead/Makefile
create mode 100644 arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi
create mode 100644 arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
create mode 100644 arch/riscv/boot/dts/thead/th1520.dtsi
--
2.40.0
Add compatible string for the T-HEAD TH1520 clint.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
---
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 94bef9424df1..388d3385d7eb 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -37,6 +37,7 @@ properties:
- items:
- enum:
- allwinner,sun20i-d1-clint
+ - thead,th1520-clint
- const: thead,c900-clint
- items:
- const: sifive,clint0
--
2.40.0
Add initial device tree for the TH1520 RISC-V SoC by T-HEAD.
Signed-off-by: Jisheng Zhang <[email protected]>
---
arch/riscv/boot/dts/thead/th1520.dtsi | 422 ++++++++++++++++++++++++++
1 file changed, 422 insertions(+)
create mode 100644 arch/riscv/boot/dts/thead/th1520.dtsi
diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi b/arch/riscv/boot/dts/thead/th1520.dtsi
new file mode 100644
index 000000000000..56a73134b49e
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/th1520.dtsi
@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Alibaba Group Holding Limited.
+ * Copyright (C) 2023 Jisheng Zhang <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "thead,th1520";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <3000000>;
+
+ c910_0: cpu@0 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <0>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu0_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ c910_1: cpu@1 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <1>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu1_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ c910_2: cpu@2 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <2>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu2_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ c910_3: cpu@3 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <3>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu3_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ l2_cache: l2-cache {
+ compatible = "cache";
+ cache-block-size = <64>;
+ cache-level = <2>;
+ cache-size = <1048576>;
+ cache-sets = <1024>;
+ cache-unified;
+ };
+ };
+
+ osc: oscillator {
+ compatible = "fixed-clock";
+ clock-output-names = "osc_24m";
+ #clock-cells = <0>;
+ };
+
+ osc_32k: 32k-oscillator {
+ compatible = "fixed-clock";
+ clock-output-names = "osc_32k";
+ #clock-cells = <0>;
+ };
+
+ apb_clk: apb-clk-clock {
+ compatible = "fixed-clock";
+ clock-output-names = "apb_clk";
+ #clock-cells = <0>;
+ };
+
+ uart_sclk: uart-sclk-clock {
+ compatible = "fixed-clock";
+ clock-output-names = "uart_sclk";
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&plic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ plic: interrupt-controller@ffd8000000 {
+ compatible = "thead,th1520-plic", "thead,c900-plic";
+ reg = <0xff 0xd8000000 0x0 0x01000000>;
+ interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
+ <&cpu1_intc 11>, <&cpu1_intc 9>,
+ <&cpu2_intc 11>, <&cpu2_intc 9>,
+ <&cpu3_intc 11>, <&cpu3_intc 9>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ riscv,ndev = <240>;
+ };
+
+ clint: timer@ffdc000000 {
+ compatible = "thead,th1520-clint", "thead,c900-clint";
+ reg = <0xff 0xdc000000 0x0 0x00010000>;
+ 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>;
+ };
+
+ uart0: serial@ffe7014000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xe7014000 0x0 0x100>;
+ interrupts = <36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_sclk>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart1: serial@ffe7f00000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xe7f00000 0x0 0x100>;
+ interrupts = <37 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_sclk>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart3: serial@ffe7f04000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xe7f04000 0x0 0x100>;
+ interrupts = <39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_sclk>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ gpio2: gpio@ffe7f34000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xe7f34000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portc: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <58 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ gpio3: gpio@ffe7f38000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xe7f38000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portd: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <59 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ gpio0: gpio@ffec005000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xec005000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ porta: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <56 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ gpio1: gpio@ffec006000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xec006000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portb: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <57 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ uart2: serial@ffec010000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xec010000 0x0 0x4000>;
+ interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_sclk>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ dmac0: dma-controller@ffefc00000 {
+ compatible = "snps,axi-dma-1.01a";
+ reg = <0xff 0xefc00000 0x0 0x1000>;
+ interrupts = <27 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&apb_clk>, <&apb_clk>;
+ clock-names = "core-clk", "cfgr-clk";
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ snps,block-size = <65536 65536 65536 65536>;
+ snps,priority = <0 1 2 3>;
+ snps,dma-masters = <1>;
+ snps,data-width = <4>;
+ snps,axi-max-burst-len = <16>;
+ status = "disabled";
+ };
+
+ timer0: timer@ffefc32000 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc32000 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer1: timer@ffefc32014 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc32014 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer2: timer@ffefc32028 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc32028 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer3: timer@ffefc3203c {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc3203c 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart4: serial@fff7f08000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xf7f08000 0x0 0x4000>;
+ interrupts = <40 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_sclk>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart5: serial@fff7f0c000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xf7f0c000 0x0 0x4000>;
+ interrupts = <41 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_sclk>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ timer4: timer@ffffc33000 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc33000 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer5: timer@ffffc33014 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc33014 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer6: timer@ffffc33028 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc33028 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ timer7: timer@ffffc3303c {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc3303c 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ ao_gpio0: gpio@fffff41000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xfff41000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ porte: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <76 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ ao_gpio1: gpio@fffff52000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xfff52000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portf: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+ };
+};
--
2.40.0
Add compatible string for T-HEAD TH1520 plic.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Reviewed-by: Guo Ren <[email protected]>
---
.../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index f75736a061af..0fa9b862e4a5 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -65,6 +65,7 @@ properties:
- items:
- enum:
- allwinner,sun20i-d1-plic
+ - thead,th1520-plic
- const: thead,c900-plic
- items:
- const: sifive,plic-1.0.0
--
2.40.0
Currently, I would like to maintain the T-HEAD RISC-V SoC support.
Signed-off-by: Jisheng Zhang <[email protected]>
Acked-by: Conor Dooley <[email protected]>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e0ad886d3163..68805b09654f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18162,6 +18162,14 @@ F: drivers/perf/riscv_pmu.c
F: drivers/perf/riscv_pmu_legacy.c
F: drivers/perf/riscv_pmu_sbi.c
+RISC-V THEAD SoC SUPPORT
+M: Jisheng Zhang <[email protected]>
+M: Guo Ren <[email protected]>
+M: Fu Wei <[email protected]>
+L: [email protected]
+S: Maintained
+F: arch/riscv/boot/dts/thead/
+
RNBD BLOCK DRIVERS
M: Md. Haris Iqbal <[email protected]>
M: Jack Wang <[email protected]>
--
2.40.0
The first SoC in the T-HEAD series is TH1520, containing quad T-HEAD
C910 cores.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
---
arch/riscv/Kconfig.socs | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 1cf69f958f10..ce10a38dff37 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -41,6 +41,12 @@ config ARCH_SUNXI
This enables support for Allwinner sun20i platform hardware,
including boards based on the D1 and D1s SoCs.
+config ARCH_THEAD
+ bool "T-HEAD RISC-V SoCs"
+ select ERRATA_THEAD
+ help
+ This enables support for the RISC-V based T-HEAD SoCs.
+
config ARCH_VIRT
def_bool SOC_VIRT
--
2.40.0
Enable T-HEAD SoC config in defconfig to allow the default
upstream kernel to boot on Sipeed Lichee Pi 4A board.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Acked-by: Guo Ren <[email protected]>
---
arch/riscv/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index d98d6e90b2b8..109e4b5b003c 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -27,6 +27,7 @@ CONFIG_EXPERT=y
CONFIG_PROFILING=y
CONFIG_SOC_MICROCHIP_POLARFIRE=y
CONFIG_ARCH_RENESAS=y
+CONFIG_ARCH_THEAD=y
CONFIG_SOC_SIFIVE=y
CONFIG_SOC_STARFIVE=y
CONFIG_ARCH_SUNXI=y
--
2.40.0
Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
module which is powered by T-HEAD's TH1520 SoC. Add minimal device
tree files for the core module and the development board.
Support basic uart/gpio/dmac drivers, so supports booting to a basic
shell.
Signed-off-by: Jisheng Zhang <[email protected]>
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/thead/Makefile | 2 +
.../dts/thead/th1520-lichee-module-4a.dtsi | 38 +++++++++++++++++++
.../boot/dts/thead/th1520-lichee-pi-4a.dts | 32 ++++++++++++++++
4 files changed, 73 insertions(+)
create mode 100644 arch/riscv/boot/dts/thead/Makefile
create mode 100644 arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi
create mode 100644 arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index f0d9f89054f8..1e884868ccba 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -2,6 +2,7 @@
subdir-y += allwinner
subdir-y += sifive
subdir-y += starfive
+subdir-y += thead
subdir-y += canaan
subdir-y += microchip
subdir-y += renesas
diff --git a/arch/riscv/boot/dts/thead/Makefile b/arch/riscv/boot/dts/thead/Makefile
new file mode 100644
index 000000000000..e311fc9a5939
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_THEAD) += th1520-lichee-pi-4a.dtb
diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi
new file mode 100644
index 000000000000..4b0249ac710f
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "th1520.dtsi"
+
+/ {
+ model = "Sipeed Lichee Module 4A";
+ compatible = "sipeed,lichee-module-4a", "thead,th1520";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x00000000 0x2 0x00000000>;
+ };
+};
+
+&osc {
+ clock-frequency = <24000000>;
+};
+
+&osc_32k {
+ clock-frequency = <32768>;
+};
+
+&apb_clk {
+ clock-frequency = <62500000>;
+};
+
+&uart_sclk {
+ clock-frequency = <100000000>;
+};
+
+&dmac0 {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts b/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
new file mode 100644
index 000000000000..a1248b2ee3a3
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Jisheng Zhang <[email protected]>
+ */
+
+#include "th1520-lichee-module-4a.dtsi"
+
+/ {
+ model = "Sipeed Lichee Pi 4A";
+ compatible = "sipeed,lichee-pi-4a", "sipeed,lichee-module-4a", "thead,th1520";
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ gpio2 = &gpio2;
+ gpio3 = &gpio3;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ serial5 = &uart5;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.40.0
Several SoMs and boards are available that feature the T-HEAD TH1520
SoC. Document the compatible strings.
Signed-off-by: Jisheng Zhang <[email protected]>
---
.../devicetree/bindings/riscv/thead.yaml | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/thead.yaml
diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml
new file mode 100644
index 000000000000..e62f6821372e
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/thead.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/thead.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD SoC-based boards
+
+maintainers:
+ - Jisheng Zhang <[email protected]>
+
+description:
+ T-HEAD SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Sipeed Lichee Pi 4A board for the Sipeed Lichee Module 4A
+ items:
+ - enum:
+ - sipeed,lichee-pi-4a
+ - const: sipeed,lichee-module-4a
+ - const: thead,th1520
+
+additionalProperties: true
+
+...
--
2.40.0
Hey Jisheng,
On Sun, Jun 18, 2023 at 12:15:21AM +0800, Jisheng Zhang wrote:
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> tree files for the core module and the development board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
>
> NOTE: the thead cpu reset dt-binding and DT node are removed in v3. This
> makes secondary CPUs unable to be online.
The kernel doesn't do anything with that node though, so if you were to
load a fitImage in U-Boot containing this DT, having booted with
whatever the factory provided OpenSBI has, that limitation doesn't
apply, right?
> However, minimal th1520
> support is better than nothing. And the community has been working on
> and will work on the cpu reset dt-binding, for example, Conor, Guo and
> Jessica are discussing about it, I have seen valuable comments and
> inputs from them. I believe we can add back cpu reset in next
> development window.
I'll go take a look through this, if it's good I'll apply it and send it
on to Arnd for 6.5? Although I assume it is fine since v2 was nearly
fine!
Cheers,
Conor.
From: Conor Dooley <[email protected]>
On Sun, 18 Jun 2023 00:15:21 +0800, Jisheng Zhang wrote:
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> tree files for the core module and the development board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
>
> [...]
Applied to riscv-dt-for-next, thanks!
[1/8] dt-bindings: interrupt-controller: Add T-HEAD's TH1520 PLIC
https://git.kernel.org/conor/c/a04cc7391d88
[2/8] dt-bindings: timer: Add T-HEAD TH1520 clint
https://git.kernel.org/conor/c/413c24b03f4e
[3/8] dt-bindings: riscv: Add T-HEAD TH1520 board compatibles
https://git.kernel.org/conor/c/89b0186ab532
[4/8] riscv: Add the T-HEAD SoC family Kconfig option
https://git.kernel.org/conor/c/da47ce003963
[5/8] riscv: dts: add initial T-HEAD TH1520 SoC device tree
https://git.kernel.org/conor/c/8e396880a864
[6/8] riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
https://git.kernel.org/conor/c/5af4cb0c42c5
[7/8] MAINTAINERS: add entry for T-HEAD RISC-V SoC
https://git.kernel.org/conor/c/1203f584fe66
[8/8] riscv: defconfig: enable T-HEAD SoC
https://git.kernel.org/conor/c/318afa081204
I'll send it to Arnd as a "RISC-V Devicetrees for v6.5 Part 2" once it
has been in linux-next for a day or two.
Going forward, who is going to pick up the patches and send the PRs to
Arnd? I wrote a document that should be in v6.5 about SoC tree
submaintainer stuff that is worth reading:
https://lore.kernel.org/all/20230606-escapable-stuffed-7ca5033e7741@wendy/
I'll do it if nobody else is willing to, but I don't want to be
responsible for applying patches for all the platforms that pop up,
especially for ones that I don't even have the hardware for ;)
Thanks,
Conor.
On Sat, Jun 17, 2023 at 06:02:20PM +0100, Conor Dooley wrote:
> Hey Jisheng,
Hi Conor,
>
> On Sun, Jun 18, 2023 at 12:15:21AM +0800, Jisheng Zhang wrote:
> > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > tree files for the core module and the development board.
> >
> > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > shell.
> >
> > NOTE: the thead cpu reset dt-binding and DT node are removed in v3. This
> > makes secondary CPUs unable to be online.
>
> The kernel doesn't do anything with that node though, so if you were to
> load a fitImage in U-Boot containing this DT, having booted with
> whatever the factory provided OpenSBI has, that limitation doesn't
> apply, right?
The cpu reset DT node is for opensbi, linux kernel doesn't need it.
So you are right: if the u-boot contains the DT node(no matter how
the DT node is added, statically added or dynamically added with
uboot cmd), the limitation doesn't apply.
>
> > However, minimal th1520
> > support is better than nothing. And the community has been working on
> > and will work on the cpu reset dt-binding, for example, Conor, Guo and
> > Jessica are discussing about it, I have seen valuable comments and
> > inputs from them. I believe we can add back cpu reset in next
> > development window.
>
> I'll go take a look through this, if it's good I'll apply it and send it
> on to Arnd for 6.5? Although I assume it is fine since v2 was nearly
Thank you for helping to send out this Pull request!
> fine!
>
> Cheers,
> Conor.
On Sat, Jun 17, 2023 at 07:20:43PM +0100, Conor Dooley wrote:
> From: Conor Dooley <[email protected]>
>
> On Sun, 18 Jun 2023 00:15:21 +0800, Jisheng Zhang wrote:
> > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > tree files for the core module and the development board.
> >
> > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > shell.
> >
> > [...]
>
> Applied to riscv-dt-for-next, thanks!
>
> [1/8] dt-bindings: interrupt-controller: Add T-HEAD's TH1520 PLIC
> https://git.kernel.org/conor/c/a04cc7391d88
> [2/8] dt-bindings: timer: Add T-HEAD TH1520 clint
> https://git.kernel.org/conor/c/413c24b03f4e
> [3/8] dt-bindings: riscv: Add T-HEAD TH1520 board compatibles
> https://git.kernel.org/conor/c/89b0186ab532
> [4/8] riscv: Add the T-HEAD SoC family Kconfig option
> https://git.kernel.org/conor/c/da47ce003963
> [5/8] riscv: dts: add initial T-HEAD TH1520 SoC device tree
> https://git.kernel.org/conor/c/8e396880a864
> [6/8] riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
> https://git.kernel.org/conor/c/5af4cb0c42c5
> [7/8] MAINTAINERS: add entry for T-HEAD RISC-V SoC
> https://git.kernel.org/conor/c/1203f584fe66
> [8/8] riscv: defconfig: enable T-HEAD SoC
> https://git.kernel.org/conor/c/318afa081204
>
> I'll send it to Arnd as a "RISC-V Devicetrees for v6.5 Part 2" once it
> has been in linux-next for a day or two.
Thank you so much for helping the PR this time.
>
> Going forward, who is going to pick up the patches and send the PRs to
> Arnd? I wrote a document that should be in v6.5 about SoC tree
Here is what I thought:
From next development window,
If we see a heavy development window, IOW, the patches size is big, I
will take the job of picking up patches and sending out PRs.
Once the development calms down, the patches size is trivial, I will
explictly send request to you by repling the patches to ask your help
to directly take the patches and send PRs.
Any comments are appreciated.
Thanks
> submaintainer stuff that is worth reading:
> https://lore.kernel.org/all/20230606-escapable-stuffed-7ca5033e7741@wendy/
The handbook is a wonderful document, thank you!
>
> I'll do it if nobody else is willing to, but I don't want to be
> responsible for applying patches for all the platforms that pop up,
> especially for ones that I don't even have the hardware for ;)
>
> Thanks,
> Conor.
On Mon, Jun 19, 2023 at 12:25:54AM +0800, Jisheng Zhang wrote:
> On Sat, Jun 17, 2023 at 07:20:43PM +0100, Conor Dooley wrote:
> > Going forward, who is going to pick up the patches and send the PRs to
> > Arnd? I wrote a document that should be in v6.5 about SoC tree
>
> Here is what I thought:
> From next development window,
>
> If we see a heavy development window, IOW, the patches size is big, I
> will take the job of picking up patches and sending out PRs.
>
> Once the development calms down, the patches size is trivial, I will
> explictly send request to you by repling the patches to ask your help
> to directly take the patches and send PRs.
The thing with this, is you don't really know in advance if the window
is going to be busy or not - you could end up getting a bunch of trivial
stuff pop up at a later -rc etc. I'd rather patches that ready to be
picked up didn't end up sitting un-applied on the list, until you figure
whether there has been enough to justify a PR or not.
If there is only one or two, you can always send the PR as a series of
patches, rather than creating a tag etc.
> Any comments are appreciated.
Could you please add a git tree to the MAINTAINERS entry & get it added
to linux-next? You should probably add another X: line to the MISC SOC
SUPPORT entry in the same patch.
Also, RISC-V is give-or-take clean for dtbs_check w/ W=1, please keep it
that way! I do keep an eye on it in linux-next, so if your tree is added
there, I'll at least see if changes in other parts of the kernel cause
warnings to spring up.
> > submaintainer stuff that is worth reading:
> > https://lore.kernel.org/all/20230606-escapable-stuffed-7ca5033e7741@wendy/
>
> The handbook is a wonderful document, thank you!
:)
On Mon, Jun 19, 2023 at 12:25:54AM +0800, Jisheng Zhang wrote:
> On Sat, Jun 17, 2023 at 07:20:43PM +0100, Conor Dooley wrote:
> > From: Conor Dooley <[email protected]>
> > I'll send it to Arnd as a "RISC-V Devicetrees for v6.5 Part 2" once it
> > has been in linux-next for a day or two.
>
> Thank you so much for helping the PR this time.
Just FYI, since I think only I get the notif emails, Arnd has merged it:
https://git.kernel.org/soc/soc/c/c9a5aa0e53d0
Cheers,
Conor.
On Tue, Jun 20, 2023 at 11:52:46PM +0100, Conor Dooley wrote:
> On Mon, Jun 19, 2023 at 12:25:54AM +0800, Jisheng Zhang wrote:
> > On Sat, Jun 17, 2023 at 07:20:43PM +0100, Conor Dooley wrote:
> > > From: Conor Dooley <[email protected]>
>
> > > I'll send it to Arnd as a "RISC-V Devicetrees for v6.5 Part 2" once it
> > > has been in linux-next for a day or two.
> >
> > Thank you so much for helping the PR this time.
>
> Just FYI, since I think only I get the notif emails, Arnd has merged it:
> https://git.kernel.org/soc/soc/c/c9a5aa0e53d0
Bah, wrong link - that's the one that pw bot told me it was, but I guess
it got confused by the fact that I had sent 2 PRs. Correct commit is:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=soc/dt&id=d8ece8b832276756d32c310fdd76835f8046071a
>
> Cheers,
> Conor.
Hey,
On Tue, Jul 25, 2023 at 03:38:58PM +0800, Xi Ruoyao wrote:
> Hi Jisheng,
>
> On Sun, 2023-06-18 at 00:15 +0800, Jisheng Zhang wrote:
> > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > tree files for the core module and the development board.
> >
> > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > shell.
>
> Thanks for the excellent work, but when I tried to boot Linux 6.5.0-rc3
> on my Lichee Pi 4A it fails with:
>
> ## Flattened Device Tree blob at 01f00000
> Booting using the fdt blob at 0x1f00000
> Using Device Tree in place at 0000000001f00000, end 0000000001f050c4
>
> Starting kernel ...
>
> [ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
> [ 0.000000] Machine model: Sipeed Lichee Pi 4A
> [ 0.000000] SBI specification v0.3 detected
> [ 0.000000] SBI implementation ID=0x1 Version=0x9
> [ 0.000000] SBI TIME extension detected
> [ 0.000000] SBI IPI extension detected
> [ 0.000000] SBI RFENCE extension detected
> [ 0.000000] earlycon: uart0 at MMIO32 0x000000ffe7014000 (options '115200n8')
> [ 0.000000] printk: bootconsole [uart0] enabled
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] OF: reserved mem: 0x0000000000000000..0x000000000003ffff (256 KiB) nomap non-reusable mmode_resv0@0
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
> [ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x000000000003ffff]
> [ 0.000000] node 0: [mem 0x0000000000040000-0x00000001ffffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
> [ 0.000000] SBI HSM extension detected
> [ 0.000000] riscv: base ISA extensions acdfim
> [ 0.000000] riscv: ELF capabilities acdfim
> [ 0.000000] percpu: Embedded 17 pages/cpu s38184 r0 d31448 u69632
> [ 0.000000] Kernel command line: console=ttyS0,115200 earlycon loglevel=7
> [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2064384
> [ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> [ 0.000000] software IO TLB: area num 4.
> [ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
> [ 0.000000] Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] rcu: RCU event tracing is enabled.
> [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
> [ 0.000000] Trampoline variant of Tasks RCU enabled.
> [ 0.000000] Tracing variant of Tasks RCU enabled.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> [ 0.000000] riscv-intc: 64 local interrupts mapped
> [ 0.000000] Oops - load access fault [#1]
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
> [ 0.000000] Hardware name: Sipeed Lichee Pi 4A (DT)
> [ 0.000000] epc : __plic_toggle+0x5a/0x62
> [ 0.000000] ra : __plic_init.isra.0+0x2d0/0x462
> [ 0.000000] epc : ffffffff802ce8ec ra : ffffffff80618816 sp : ffffffff80e03c90
> [ 0.000000] gp : ffffffff80ec5bb8 tp : ffffffff80e10d40 t0 : ffffffd900045940
> [ 0.000000] t1 : 0000000000000002 t2 : ffffffd90004a10c s0 : ffffffd9fef6ed68
> [ 0.000000] s1 : ffffffd900045680 a0 : ffffffc801002080 a1 : 0000000000000002
> [ 0.000000] a2 : 0000000000000000 a3 : 00000000000000f4 a4 : 0000000000000001
> [ 0.000000] a5 : 0000000000000000 a6 : 0000000000000b40 a7 : ffffffd900045940
> [ 0.000000] s2 : ffffffd9fef6ed78 s3 : ffffffff80ef9630 s4 : 0000000000000001
> [ 0.000000] s5 : ffffffd9ffff5af8 s6 : 0000000000000001 s7 : ffffffff80815d68
> [ 0.000000] s8 : 0000000000000008 s9 : 0000000000000000 s10: ffffffff80815d68
> [ 0.000000] s11: ffffffff80b1b1b8 t3 : ffffffff80c003d0 t4 : 0000000000000001
> [ 0.000000] t5 : 0000000000000003 t6 : 0000000000000001
> [ 0.000000] status: 8000000201800100 badaddr: 000000ffd8002080 cause: 0000000000000005
> [ 0.000000] [<ffffffff802ce8ec>] __plic_toggle+0x5a/0x62
> [ 0.000000] [<ffffffff8061ffc8>] of_irq_init+0x14a/0x248
> [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> [ 0.000000] [<ffffffff806034f6>] init_IRQ+0xc6/0x100
> [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> [ 0.000000] Code: 0007 c319 9123 00e7 8082 000f 0140 411c 000f 0820 (c593) fff5
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Kernel panic - not syncing: Fatal exception in interrupt
>
> I guess I'm either using some unsupported configuration or making some
> stupid mistakes, but I cannot find any documentation about how to
> configure the mainline kernel for Lichee Pi 4A properly. Could you give
> some pointers?
Are you using the vendor OpenSBI? IIRC, and the lads can probably
correct me here, you need to have an OpenSBI that contains
https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
which the vendor supplied OpenSBI does not have.
> And this line
>
> Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
>
> does not match my hardware (my board is a 16 GB DRAM variant). So in
> the future we'll need multiple DTs for all the variants?
A bootloader stage would ideally patch the DT that the kernel ends up
getting. If you're loading your own dtb, you can do it easily in U-Boot
after you extract it from your FIT image or whatever. I have no idea
what the vendor U-Boot does.
Thanks,
Conor.
Hi Jisheng,
On Sun, 2023-06-18 at 00:15 +0800, Jisheng Zhang wrote:
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> tree files for the core module and the development board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
Thanks for the excellent work, but when I tried to boot Linux 6.5.0-rc3
on my Lichee Pi 4A it fails with:
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Using Device Tree in place at 0000000001f00000, end 0000000001f050c4
Starting kernel ...
[ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
[ 0.000000] Machine model: Sipeed Lichee Pi 4A
[ 0.000000] SBI specification v0.3 detected
[ 0.000000] SBI implementation ID=0x1 Version=0x9
[ 0.000000] SBI TIME extension detected
[ 0.000000] SBI IPI extension detected
[ 0.000000] SBI RFENCE extension detected
[ 0.000000] earlycon: uart0 at MMIO32 0x000000ffe7014000 (options '115200n8')
[ 0.000000] printk: bootconsole [uart0] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] OF: reserved mem: 0x0000000000000000..0x000000000003ffff (256 KiB) nomap non-reusable mmode_resv0@0
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000000003ffff]
[ 0.000000] node 0: [mem 0x0000000000040000-0x00000001ffffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
[ 0.000000] SBI HSM extension detected
[ 0.000000] riscv: base ISA extensions acdfim
[ 0.000000] riscv: ELF capabilities acdfim
[ 0.000000] percpu: Embedded 17 pages/cpu s38184 r0 d31448 u69632
[ 0.000000] Kernel command line: console=ttyS0,115200 earlycon loglevel=7
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2064384
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] software IO TLB: area num 4.
[ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
[ 0.000000] Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] riscv-intc: 64 local interrupts mapped
[ 0.000000] Oops - load access fault [#1]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
[ 0.000000] Hardware name: Sipeed Lichee Pi 4A (DT)
[ 0.000000] epc : __plic_toggle+0x5a/0x62
[ 0.000000] ra : __plic_init.isra.0+0x2d0/0x462
[ 0.000000] epc : ffffffff802ce8ec ra : ffffffff80618816 sp : ffffffff80e03c90
[ 0.000000] gp : ffffffff80ec5bb8 tp : ffffffff80e10d40 t0 : ffffffd900045940
[ 0.000000] t1 : 0000000000000002 t2 : ffffffd90004a10c s0 : ffffffd9fef6ed68
[ 0.000000] s1 : ffffffd900045680 a0 : ffffffc801002080 a1 : 0000000000000002
[ 0.000000] a2 : 0000000000000000 a3 : 00000000000000f4 a4 : 0000000000000001
[ 0.000000] a5 : 0000000000000000 a6 : 0000000000000b40 a7 : ffffffd900045940
[ 0.000000] s2 : ffffffd9fef6ed78 s3 : ffffffff80ef9630 s4 : 0000000000000001
[ 0.000000] s5 : ffffffd9ffff5af8 s6 : 0000000000000001 s7 : ffffffff80815d68
[ 0.000000] s8 : 0000000000000008 s9 : 0000000000000000 s10: ffffffff80815d68
[ 0.000000] s11: ffffffff80b1b1b8 t3 : ffffffff80c003d0 t4 : 0000000000000001
[ 0.000000] t5 : 0000000000000003 t6 : 0000000000000001
[ 0.000000] status: 8000000201800100 badaddr: 000000ffd8002080 cause: 0000000000000005
[ 0.000000] [<ffffffff802ce8ec>] __plic_toggle+0x5a/0x62
[ 0.000000] [<ffffffff8061ffc8>] of_irq_init+0x14a/0x248
[ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
[ 0.000000] [<ffffffff806034f6>] init_IRQ+0xc6/0x100
[ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
[ 0.000000] Code: 0007 c319 9123 00e7 8082 000f 0140 411c 000f 0820 (c593) fff5
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Fatal exception in interrupt
I guess I'm either using some unsupported configuration or making some
stupid mistakes, but I cannot find any documentation about how to
configure the mainline kernel for Lichee Pi 4A properly. Could you give
some pointers?
And this line
Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
does not match my hardware (my board is a 16 GB DRAM variant). So in
the future we'll need multiple DTs for all the variants?
> NOTE: the thead cpu reset dt-binding and DT node are removed in v3. This
> makes secondary CPUs unable to be online. However, minimal th1520
> support is better than nothing. And the community has been working on
> and will work on the cpu reset dt-binding, for example, Conor, Guo and
> Jessica are discussing about it, I have seen valuable comments and
> inputs from them. I believe we can add back cpu reset in next
> development window.
>
> Thanks
>
> Since v2:
> - remove thead cpu-rst dt-binding doc and its DT node from th1520.dtsi
> - collect Reviewed-by and Acked-by tags
> - update uart reg size as suggested by Yixun
> - Add Guo Ren and Fu Wei as THEAD SoCs Maintainers
>
> Since v1:
> - add missing plic, clint, th1520 itself dt-bindings
> - use c900-plic
> - s/light/th1520
> - add dt-binding for T-HEAD CPU reset
> - enable ARCH_THEAD in defconfig
> - fix all dtbs_check error/warning except the CPU RESET, see above.
>
> Jisheng Zhang (8):
> dt-bindings: interrupt-controller: Add T-HEAD's TH1520 PLIC
> dt-bindings: timer: Add T-HEAD TH1520 clint
> dt-bindings: riscv: Add T-HEAD TH1520 board compatibles
> riscv: Add the T-HEAD SoC family Kconfig option
> riscv: dts: add initial T-HEAD TH1520 SoC device tree
> riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
> MAINTAINERS: add entry for T-HEAD RISC-V SoC
> riscv: defconfig: enable T-HEAD SoC
>
> .../sifive,plic-1.0.0.yaml | 1 +
> .../devicetree/bindings/riscv/thead.yaml | 29 ++
> .../bindings/timer/sifive,clint.yaml | 1 +
> MAINTAINERS | 8 +
> arch/riscv/Kconfig.socs | 6 +
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/thead/Makefile | 2 +
> .../dts/thead/th1520-lichee-module-4a.dtsi | 38 ++
> .../boot/dts/thead/th1520-lichee-pi-4a.dts | 32 ++
> arch/riscv/boot/dts/thead/th1520.dtsi | 422 ++++++++++++++++++
> arch/riscv/configs/defconfig | 1 +
> 11 files changed, 541 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/riscv/thead.yaml
> create mode 100644 arch/riscv/boot/dts/thead/Makefile
> create mode 100644 arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi
> create mode 100644 arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> create mode 100644 arch/riscv/boot/dts/thead/th1520.dtsi
>
Hey Guo Ren,
On Tue, Jul 25, 2023 at 08:52:09AM +0100, Conor Dooley wrote:
> On Tue, Jul 25, 2023 at 03:38:58PM +0800, Xi Ruoyao wrote:
> > On Sun, 2023-06-18 at 00:15 +0800, Jisheng Zhang wrote:
> > > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > > tree files for the core module and the development board.
> > >
> > > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > > shell.
> >
> > Thanks for the excellent work, but when I tried to boot Linux 6.5.0-rc3
> > on my Lichee Pi 4A it fails with:
> >
> > ## Flattened Device Tree blob at 01f00000
> > Booting using the fdt blob at 0x1f00000
> > Using Device Tree in place at 0000000001f00000, end 0000000001f050c4
> >
> > Starting kernel ...
> >
> > [ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
> > [ 0.000000] Machine model: Sipeed Lichee Pi 4A
> > [ 0.000000] SBI specification v0.3 detected
> > [ 0.000000] SBI implementation ID=0x1 Version=0x9
> > [ 0.000000] Oops - load access fault [#1]
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
> > [ 0.000000] Hardware name: Sipeed Lichee Pi 4A (DT)
> > [ 0.000000] epc : __plic_toggle+0x5a/0x62
> > [ 0.000000] ra : __plic_init.isra.0+0x2d0/0x462
> > [ 0.000000] epc : ffffffff802ce8ec ra : ffffffff80618816 sp : ffffffff80e03c90
> > [ 0.000000] gp : ffffffff80ec5bb8 tp : ffffffff80e10d40 t0 : ffffffd900045940
> > [ 0.000000] t1 : 0000000000000002 t2 : ffffffd90004a10c s0 : ffffffd9fef6ed68
> > [ 0.000000] s1 : ffffffd900045680 a0 : ffffffc801002080 a1 : 0000000000000002
> > [ 0.000000] a2 : 0000000000000000 a3 : 00000000000000f4 a4 : 0000000000000001
> > [ 0.000000] a5 : 0000000000000000 a6 : 0000000000000b40 a7 : ffffffd900045940
> > [ 0.000000] s2 : ffffffd9fef6ed78 s3 : ffffffff80ef9630 s4 : 0000000000000001
> > [ 0.000000] s5 : ffffffd9ffff5af8 s6 : 0000000000000001 s7 : ffffffff80815d68
> > [ 0.000000] s8 : 0000000000000008 s9 : 0000000000000000 s10: ffffffff80815d68
> > [ 0.000000] s11: ffffffff80b1b1b8 t3 : ffffffff80c003d0 t4 : 0000000000000001
> > [ 0.000000] t5 : 0000000000000003 t6 : 0000000000000001
> > [ 0.000000] status: 8000000201800100 badaddr: 000000ffd8002080 cause: 0000000000000005
> > [ 0.000000] [<ffffffff802ce8ec>] __plic_toggle+0x5a/0x62
> > [ 0.000000] [<ffffffff8061ffc8>] of_irq_init+0x14a/0x248
> > [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> > [ 0.000000] [<ffffffff806034f6>] init_IRQ+0xc6/0x100
> > [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> > [ 0.000000] Code: 0007 c319 9123 00e7 8082 000f 0140 411c 000f 0820 (c593) fff5
> > [ 0.000000] ---[ end trace 0000000000000000 ]---
> > [ 0.000000] Kernel panic - not syncing: Fatal exception in interrupt
> >
> > I guess I'm either using some unsupported configuration or making some
> > stupid mistakes, but I cannot find any documentation about how to
> > configure the mainline kernel for Lichee Pi 4A properly. Could you give
> > some pointers?
>
> Are you using the vendor OpenSBI? IIRC, and the lads can probably
> correct me here, you need to have an OpenSBI that contains
> https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
> which the vendor supplied OpenSBI does not have.
Guo Ren, can you try to get this sorted out? The T-Head SDK seems to be
shipping stuff that is several years old, so new SoCs from vendors that
have used your SDK are unable to run mainline kernels (and therefore
mainstream distros), without a firmware update.
The TH1520 branch on github, seems to be based on OpenSBI v0.9:
> > [ 0.000000] SBI implementation ID=0x1 Version=0x9
https://github.com/T-head-Semi/opensbi/blob/4e77060e0512ad981eee55d5a2501f6d88a41fd9/include/sbi/sbi_version.h#L13
OpenSBI v0.9 was released on the 18/01/2021:
https://github.com/riscv-software-src/opensbi/releases/tag/v0.9
The "fix" I linked above was included in v1.0, released on 24/12/2021.
I think it is hitting here for the Lichee Pi4a, but I know the same
thing has happened to the BeagleV Ahead, and I figure it'll impact
other SoCs going forward too.
Thanks,
Conor
On Tue, 2023-07-25 at 08:52 +0100, Conor Dooley wrote:
> Are you using the vendor OpenSBI? IIRC, and the lads can probably
> correct me here, you need to have an OpenSBI that contains
> https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
> which the vendor supplied OpenSBI does not have.
I'll try OpenSBI from the upstream.
> > And this line
> >
> > Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
> >
> > does not match my hardware (my board is a 16 GB DRAM variant). So in
> > the future we'll need multiple DTs for all the variants?
>
> A bootloader stage would ideally patch the DT that the kernel ends up
> getting. If you're loading your own dtb, you can do it easily in U-Boot
> after you extract it from your FIT image or whatever. I have no idea
> what the vendor U-Boot does.
The vendor ships three DTs and in uboot there are some fancy logic to
detect which should be used.
On Tue, Jul 25, 2023 at 09:10:06AM +0100, Conor Dooley wrote:
> Hey Guo Ren,
>
> On Tue, Jul 25, 2023 at 08:52:09AM +0100, Conor Dooley wrote:
> > On Tue, Jul 25, 2023 at 03:38:58PM +0800, Xi Ruoyao wrote:
> > > On Sun, 2023-06-18 at 00:15 +0800, Jisheng Zhang wrote:
> > > > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > > > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > > > tree files for the core module and the development board.
> > > >
> > > > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > > > shell.
> > >
> > > Thanks for the excellent work, but when I tried to boot Linux 6.5.0-rc3
> > > on my Lichee Pi 4A it fails with:
> > >
> > > ## Flattened Device Tree blob at 01f00000
> > > Booting using the fdt blob at 0x1f00000
> > > Using Device Tree in place at 0000000001f00000, end 0000000001f050c4
> > >
> > > Starting kernel ...
> > >
> > > [ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
> > > [ 0.000000] Machine model: Sipeed Lichee Pi 4A
> > > [ 0.000000] SBI specification v0.3 detected
>
> > > [ 0.000000] SBI implementation ID=0x1 Version=0x9
>
> > > [ 0.000000] Oops - load access fault [#1]
> > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
> > > [ 0.000000] Hardware name: Sipeed Lichee Pi 4A (DT)
> > > [ 0.000000] epc : __plic_toggle+0x5a/0x62
> > > [ 0.000000] ra : __plic_init.isra.0+0x2d0/0x462
> > > [ 0.000000] epc : ffffffff802ce8ec ra : ffffffff80618816 sp : ffffffff80e03c90
> > > [ 0.000000] gp : ffffffff80ec5bb8 tp : ffffffff80e10d40 t0 : ffffffd900045940
> > > [ 0.000000] t1 : 0000000000000002 t2 : ffffffd90004a10c s0 : ffffffd9fef6ed68
> > > [ 0.000000] s1 : ffffffd900045680 a0 : ffffffc801002080 a1 : 0000000000000002
> > > [ 0.000000] a2 : 0000000000000000 a3 : 00000000000000f4 a4 : 0000000000000001
> > > [ 0.000000] a5 : 0000000000000000 a6 : 0000000000000b40 a7 : ffffffd900045940
> > > [ 0.000000] s2 : ffffffd9fef6ed78 s3 : ffffffff80ef9630 s4 : 0000000000000001
> > > [ 0.000000] s5 : ffffffd9ffff5af8 s6 : 0000000000000001 s7 : ffffffff80815d68
> > > [ 0.000000] s8 : 0000000000000008 s9 : 0000000000000000 s10: ffffffff80815d68
> > > [ 0.000000] s11: ffffffff80b1b1b8 t3 : ffffffff80c003d0 t4 : 0000000000000001
> > > [ 0.000000] t5 : 0000000000000003 t6 : 0000000000000001
> > > [ 0.000000] status: 8000000201800100 badaddr: 000000ffd8002080 cause: 0000000000000005
> > > [ 0.000000] [<ffffffff802ce8ec>] __plic_toggle+0x5a/0x62
> > > [ 0.000000] [<ffffffff8061ffc8>] of_irq_init+0x14a/0x248
> > > [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> > > [ 0.000000] [<ffffffff806034f6>] init_IRQ+0xc6/0x100
> > > [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> > > [ 0.000000] Code: 0007 c319 9123 00e7 8082 000f 0140 411c 000f 0820 (c593) fff5
> > > [ 0.000000] ---[ end trace 0000000000000000 ]---
> > > [ 0.000000] Kernel panic - not syncing: Fatal exception in interrupt
> > >
> > > I guess I'm either using some unsupported configuration or making some
> > > stupid mistakes, but I cannot find any documentation about how to
> > > configure the mainline kernel for Lichee Pi 4A properly. Could you give
> > > some pointers?
> >
> > Are you using the vendor OpenSBI? IIRC, and the lads can probably
> > correct me here, you need to have an OpenSBI that contains
> > https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
> > which the vendor supplied OpenSBI does not have.
>
> Guo Ren, can you try to get this sorted out? The T-Head SDK seems to be
> shipping stuff that is several years old, so new SoCs from vendors that
> have used your SDK are unable to run mainline kernels (and therefore
> mainstream distros), without a firmware update.
>
> The TH1520 branch on github, seems to be based on OpenSBI v0.9:
> > > [ 0.000000] SBI implementation ID=0x1 Version=0x9
> https://github.com/T-head-Semi/opensbi/blob/4e77060e0512ad981eee55d5a2501f6d88a41fd9/include/sbi/sbi_version.h#L13
> OpenSBI v0.9 was released on the 18/01/2021:
> https://github.com/riscv-software-src/opensbi/releases/tag/v0.9
> The "fix" I linked above was included in v1.0, released on 24/12/2021.
>
> I think it is hitting here for the Lichee Pi4a, but I know the same
> thing has happened to the BeagleV Ahead, and I figure it'll impact
> other SoCs going forward too.
I ran into the access fault in the PLIC code when I first attempted to
run mainline Linux on the BeagleV Ahead. I switched from the vendor
OpenSBI v0.9 to uptream OpenSBI v1.3 and the PLIC oops went away.
For reference, my boot log when using OpenSBI v1.3:
https://gist.github.com/pdp7/23259595a7570f1f11086d286e16dfb6
And my device tree patch which essentially just adjusts the memory node
to match the amount of DDR in the BeagleV Ahead versus the lpi4a that
Jisheng has:
https://lore.kernel.org/linux-riscv/20230722-upstream-beaglev-ahead-dts-v2-0-a470ab8fe806@baylibre.com/
-Drew
On Tue, Jul 25, 2023 at 08:52:09AM +0100, Conor Dooley wrote:
> Hey,
>
> On Tue, Jul 25, 2023 at 03:38:58PM +0800, Xi Ruoyao wrote:
> > Hi Jisheng,
> >
> > On Sun, 2023-06-18 at 00:15 +0800, Jisheng Zhang wrote:
> > > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > > tree files for the core module and the development board.
> > >
> > > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > > shell.
> >
> > Thanks for the excellent work, but when I tried to boot Linux 6.5.0-rc3
> > on my Lichee Pi 4A it fails with:
> >
> > ## Flattened Device Tree blob at 01f00000
> > Booting using the fdt blob at 0x1f00000
> > Using Device Tree in place at 0000000001f00000, end 0000000001f050c4
> >
> > Starting kernel ...
> >
> > [ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
> > [ 0.000000] Machine model: Sipeed Lichee Pi 4A
> > [ 0.000000] SBI specification v0.3 detected
> > [ 0.000000] SBI implementation ID=0x1 Version=0x9
> > [ 0.000000] SBI TIME extension detected
> > [ 0.000000] SBI IPI extension detected
> > [ 0.000000] SBI RFENCE extension detected
> > [ 0.000000] earlycon: uart0 at MMIO32 0x000000ffe7014000 (options '115200n8')
> > [ 0.000000] printk: bootconsole [uart0] enabled
> > [ 0.000000] efi: UEFI not found.
> > [ 0.000000] OF: reserved mem: 0x0000000000000000..0x000000000003ffff (256 KiB) nomap non-reusable mmode_resv0@0
> > [ 0.000000] Zone ranges:
> > [ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
> > [ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff]
> > [ 0.000000] Movable zone start for each node
> > [ 0.000000] Early memory node ranges
> > [ 0.000000] node 0: [mem 0x0000000000000000-0x000000000003ffff]
> > [ 0.000000] node 0: [mem 0x0000000000040000-0x00000001ffffffff]
> > [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
> > [ 0.000000] SBI HSM extension detected
> > [ 0.000000] riscv: base ISA extensions acdfim
> > [ 0.000000] riscv: ELF capabilities acdfim
> > [ 0.000000] percpu: Embedded 17 pages/cpu s38184 r0 d31448 u69632
> > [ 0.000000] Kernel command line: console=ttyS0,115200 earlycon loglevel=7
> > [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
> > [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
> > [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2064384
> > [ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> > [ 0.000000] software IO TLB: area num 4.
> > [ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
> > [ 0.000000] Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
> > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> > [ 0.000000] rcu: RCU event tracing is enabled.
> > [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
> > [ 0.000000] Trampoline variant of Tasks RCU enabled.
> > [ 0.000000] Tracing variant of Tasks RCU enabled.
> > [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
> > [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> > [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> > [ 0.000000] riscv-intc: 64 local interrupts mapped
> > [ 0.000000] Oops - load access fault [#1]
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
> > [ 0.000000] Hardware name: Sipeed Lichee Pi 4A (DT)
> > [ 0.000000] epc : __plic_toggle+0x5a/0x62
> > [ 0.000000] ra : __plic_init.isra.0+0x2d0/0x462
> > [ 0.000000] epc : ffffffff802ce8ec ra : ffffffff80618816 sp : ffffffff80e03c90
> > [ 0.000000] gp : ffffffff80ec5bb8 tp : ffffffff80e10d40 t0 : ffffffd900045940
> > [ 0.000000] t1 : 0000000000000002 t2 : ffffffd90004a10c s0 : ffffffd9fef6ed68
> > [ 0.000000] s1 : ffffffd900045680 a0 : ffffffc801002080 a1 : 0000000000000002
> > [ 0.000000] a2 : 0000000000000000 a3 : 00000000000000f4 a4 : 0000000000000001
> > [ 0.000000] a5 : 0000000000000000 a6 : 0000000000000b40 a7 : ffffffd900045940
> > [ 0.000000] s2 : ffffffd9fef6ed78 s3 : ffffffff80ef9630 s4 : 0000000000000001
> > [ 0.000000] s5 : ffffffd9ffff5af8 s6 : 0000000000000001 s7 : ffffffff80815d68
> > [ 0.000000] s8 : 0000000000000008 s9 : 0000000000000000 s10: ffffffff80815d68
> > [ 0.000000] s11: ffffffff80b1b1b8 t3 : ffffffff80c003d0 t4 : 0000000000000001
> > [ 0.000000] t5 : 0000000000000003 t6 : 0000000000000001
> > [ 0.000000] status: 8000000201800100 badaddr: 000000ffd8002080 cause: 0000000000000005
> > [ 0.000000] [<ffffffff802ce8ec>] __plic_toggle+0x5a/0x62
> > [ 0.000000] [<ffffffff8061ffc8>] of_irq_init+0x14a/0x248
> > [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> > [ 0.000000] [<ffffffff806034f6>] init_IRQ+0xc6/0x100
> > [ 0.000000] [<ffffffff80600a7e>] start_kernel+0x40c/0x6fe
> > [ 0.000000] Code: 0007 c319 9123 00e7 8082 000f 0140 411c 000f 0820 (c593) fff5
> > [ 0.000000] ---[ end trace 0000000000000000 ]---
> > [ 0.000000] Kernel panic - not syncing: Fatal exception in interrupt
> >
> > I guess I'm either using some unsupported configuration or making some
> > stupid mistakes, but I cannot find any documentation about how to
> > configure the mainline kernel for Lichee Pi 4A properly. Could you give
> > some pointers?
>
> Are you using the vendor OpenSBI? IIRC, and the lads can probably
> correct me here, you need to have an OpenSBI that contains
> https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
> which the vendor supplied OpenSBI does not have.
To ruoyao,
I believe Conor has provided enough details and given you the clues.
And I believe you were using the legacy opensbi. If you still reproduce
the issue with the latest opensbi generic platform, plz provided full
uart log from openSBI to the kernel panic point.
>
> > And this line
> >
> > Memory: 8145304K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243304K reserved, 0K cma-reserved)
> >
> > does not match my hardware (my board is a 16 GB DRAM variant). So in
> > the future we'll need multiple DTs for all the variants?
>
> A bootloader stage would ideally patch the DT that the kernel ends up
> getting. If you're loading your own dtb, you can do it easily in U-Boot
> after you extract it from your FIT image or whatever. I have no idea
> what the vendor U-Boot does.
uboot can modify the dtb memory node on the fly ;)
>
> Thanks,
> Conor.
On Tue, 2023-07-25 at 22:58 +0800, Jisheng Zhang wrote:
> > Are you using the vendor OpenSBI? IIRC, and the lads can probably
> > correct me here, you need to have an OpenSBI that contains
> > https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
> > which the vendor supplied OpenSBI does not have.
>
> To ruoyao,
>
> I believe Conor has provided enough details and given you the clues.
> And I believe you were using the legacy opensbi. If you still reproduce
> the issue with the latest opensbi generic platform, plz provided full
> uart log from openSBI to the kernel panic point.
Thanks you all for the help!
I downloaded the latest opensbi 1.3.1 and put fw_dynamic.bin in the
generic directory into /boot (renamed not to overwritten the vendor
one), then loaded it onto address 0 from the vendor u-boot. Now the
plic issue was gone, but another panic happened. Log is pasted at the
end of this mail.
I've not set up an initramfs, so I'm expecting a panic after all, but I
think it should be "VFS: cannot mount root fs" or something, not
"unexpected interrupt cause".
Is it a problem with vendor u-boot? Should I try loading a latest u-
boot from the vendor one, and then load the kernel with the new u-boot?
Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
miscompile the kernel?
## Flattened Device Tree blob at 46000000
Booting using the fdt blob at 0x46000000
Using Device Tree in place at 0000000046000000, end 00000000460050c4
Starting kernel ...
OpenSBI v1.3.1
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|___/_____|
| |
|_|
Platform Name : Sipeed Lichee Pi 4A
Platform Features : medeleg
Platform HART Count : 4
Platform IPI Device : aclint-mswi
Platform Timer Device : aclint-mtimer @ 3000000Hz
Platform Console Device : uart8250
Platform HSM Device : ---
Platform PMU Device : ---
Platform Reboot Device : ---
Platform Shutdown Device : ---
Platform Suspend Device : ---
Platform CPPC Device : ---
Firmware Base : 0x0
Firmware Size : 224 KB
Firmware RW Offset : 0x20000
Firmware RW Size : 96 KB
Firmware Heap Offset : 0x2e000
Firmware Heap Size : 40 KB (total), 2 KB (reserved), 9 KB (used), 28 KB (free)
Firmware Scratch Size : 4096 B (total), 760 B (used), 3336 B (free)
Runtime SBI Version : 1.0
Domain0 Name : root
Domain0 Boot HART : 0
Domain0 HARTs : 0*,1*,2*,3*
Domain0 Region00 : 0x000000ffdc008000-0x000000ffdc00bfff M: (I,R,W) S/U: ()
Domain0 Region01 : 0x000000ffdc000000-0x000000ffdc007fff M: (I,R,W) S/U: ()
Domain0 Region02 : 0x0000000000000000-0x000000000001ffff M: (R,X) S/U: ()
Domain0 Region03 : 0x0000000000020000-0x000000000003ffff M: (R,W) S/U: ()
Domain0 Region04 : 0x0000000000000000-0xffffffffffffffff M: (R,W,X) S/U: (R,W,X)
Domain0 Next Address : 0x0000000040200000
Domain0 Next Arg1 : 0x0000000046000000
Domain0 Next Mode : S-mode
Domain0 SysReset : yes
Domain0 SysSuspend : yes
Boot HART ID : 0
Boot HART Domain : root
Boot HART Priv Version : v1.11
Boot HART Base ISA : rv64imafdcvx
Boot HART ISA Extensions : time
Boot HART PMP Count : 0
Boot HART PMP Granularity : 0
Boot HART PMP Address Bits: 0
Boot HART MHPM Count : 16
Boot HART MIDELEG : 0x0000000000000222
Boot HART MEDELEG : 0x000000000000b109
[ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
[ 0.000000] Machine model: Sipeed Lichee Pi 4A
[ 0.000000] SBI specification v1.0 detected
[ 0.000000] SBI implementation ID=0x1 Version=0x10003
[ 0.000000] SBI TIME extension detected
[ 0.000000] SBI IPI extension detected
[ 0.000000] SBI RFENCE extension detected
[ 0.000000] earlycon: uart0 at MMIO32 0x000000ffe7014000 (options '115200n8')
[ 0.000000] printk: bootconsole [uart0] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] OF: reserved mem: 0x0000000000000000..0x000000000001ffff (128 KiB) nomap non-reusable mmode_resv0@0
[ 0.000000] OF: reserved mem: 0x0000000000020000..0x000000000003ffff (128 KiB) nomap non-reusable mmode_resv1@20000
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000000003ffff]
[ 0.000000] node 0: [mem 0x0000000000040000-0x00000001ffffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
[ 0.000000] SBI HSM extension detected
[ 0.000000] riscv: base ISA extensions acdfim
[ 0.000000] riscv: ELF capabilities acdfim
[ 0.000000] percpu: Embedded 17 pages/cpu s38184 r0 d31448 u69632
[ 0.000000] Kernel command line: earlycon console=ttyS0,115200
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2064384
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] software IO TLB: area num 4.
[ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
[ 0.000000] Memory: 8145300K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243308K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] riscv-intc: 64 local interrupts mapped
[ 0.000000] plic: interrupt-controller@ffd8000000: mapped 240 interrupts with 4 handlers for 8 contexts.
[ 0.000000] riscv: providing IPIs using SBI IPI extension
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1623fa770, max_idle_ns: 881590404476 ns
[ 0.000001] sched_clock: 64 bits at 3000kHz, resolution 333ns, wraps every 4398046511097ns
[ 0.008488] Console: colour dummy device 80x25
[ 0.012944] Kernel panic - not syncing: unexpected interrupt cause
[ 0.012952] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
[ 0.012964] Hardware name: Sipeed Lichee Pi 4A (DT)
[ 0.012970] Call Trace:
[ 0.012976] [<ffffffff80004c38>] walk_stackframe+0x0/0x7e
[ 0.013002] [<ffffffff804c868c>] dump_stack_lvl+0x34/0x4e
[ 0.013022] [<ffffffff804c1334>] panic+0xf2/0x292
[ 0.013035] [<ffffffff802cddc0>] riscv_intc_irq+0x34/0x38
[ 0.013052] [<ffffffff804c8716>] handle_riscv_irq+0x66/0xa6
[ 0.059145] ---[ end Kernel panic - not syncing: unexpected interrupt cause ]---
On Wed, Jul 26, 2023 at 08:48:08PM +0800, Xi Ruoyao wrote:
> On Tue, 2023-07-25 at 22:58 +0800, Jisheng Zhang wrote:
> > > Are you using the vendor OpenSBI? IIRC, and the lads can probably
> > > correct me here, you need to have an OpenSBI that contains
> > > https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
> > > which the vendor supplied OpenSBI does not have.
> >
> > To ruoyao,
> >
> > I believe Conor has provided enough details and given you the clues.
> > And I believe you were using the legacy opensbi. If you still reproduce
> > the issue with the latest opensbi generic platform, plz provided full
> > uart log from openSBI to the kernel panic point.
>
> Thanks you all for the help!
>
> I downloaded the latest opensbi 1.3.1 and put fw_dynamic.bin in the
> generic directory into /boot (renamed not to overwritten the vendor
> one), then loaded it onto address 0 from the vendor u-boot. Now the
> plic issue was gone, but another panic happened. Log is pasted at the
> end of this mail.
>
> I've not set up an initramfs, so I'm expecting a panic after all, but I
> think it should be "VFS: cannot mount root fs" or something, not
> "unexpected interrupt cause".
>
> Is it a problem with vendor u-boot? Should I try loading a latest u-
> boot from the vendor one, and then load the kernel with the new u-boot?
which dts r u using? see below.
>
> Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
> miscompile the kernel?
>
> ## Flattened Device Tree blob at 46000000
> Booting using the fdt blob at 0x46000000
> Using Device Tree in place at 0000000046000000, end 00000000460050c4
>
> Starting kernel ...
>
>
> OpenSBI v1.3.1
> ____ _____ ____ _____
> / __ \ / ____| _ \_ _|
> | | | |_ __ ___ _ __ | (___ | |_) || |
> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> | |__| | |_) | __/ | | |____) | |_) || |_
> \____/| .__/ \___|_| |_|_____/|___/_____|
> | |
> |_|
>
> Platform Name : Sipeed Lichee Pi 4A
> Platform Features : medeleg
> Platform HART Count : 4
> Platform IPI Device : aclint-mswi
> Platform Timer Device : aclint-mtimer @ 3000000Hz
> Platform Console Device : uart8250
> Platform HSM Device : ---
> Platform PMU Device : ---
> Platform Reboot Device : ---
> Platform Shutdown Device : ---
> Platform Suspend Device : ---
> Platform CPPC Device : ---
> Firmware Base : 0x0
> Firmware Size : 224 KB
> Firmware RW Offset : 0x20000
> Firmware RW Size : 96 KB
> Firmware Heap Offset : 0x2e000
> Firmware Heap Size : 40 KB (total), 2 KB (reserved), 9 KB (used), 28 KB (free)
> Firmware Scratch Size : 4096 B (total), 760 B (used), 3336 B (free)
> Runtime SBI Version : 1.0
>
> Domain0 Name : root
> Domain0 Boot HART : 0
> Domain0 HARTs : 0*,1*,2*,3*
> Domain0 Region00 : 0x000000ffdc008000-0x000000ffdc00bfff M: (I,R,W) S/U: ()
> Domain0 Region01 : 0x000000ffdc000000-0x000000ffdc007fff M: (I,R,W) S/U: ()
> Domain0 Region02 : 0x0000000000000000-0x000000000001ffff M: (R,X) S/U: ()
> Domain0 Region03 : 0x0000000000020000-0x000000000003ffff M: (R,W) S/U: ()
> Domain0 Region04 : 0x0000000000000000-0xffffffffffffffff M: (R,W,X) S/U: (R,W,X)
> Domain0 Next Address : 0x0000000040200000
> Domain0 Next Arg1 : 0x0000000046000000
> Domain0 Next Mode : S-mode
> Domain0 SysReset : yes
> Domain0 SysSuspend : yes
>
> Boot HART ID : 0
> Boot HART Domain : root
> Boot HART Priv Version : v1.11
> Boot HART Base ISA : rv64imafdcvx
what? I don't think the mainline dts provide v and x.
> Boot HART ISA Extensions : time
> Boot HART PMP Count : 0
> Boot HART PMP Granularity : 0
> Boot HART PMP Address Bits: 0
> Boot HART MHPM Count : 16
> Boot HART MIDELEG : 0x0000000000000222
> Boot HART MEDELEG : 0x000000000000b109
> [ 0.000000] Linux version 6.5.0-rc3 (lfs@stargazer) (riscv64-lfs-linux-gnu-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT Tue Jul 25 13:38:20 CST 2023
> [ 0.000000] Machine model: Sipeed Lichee Pi 4A
> [ 0.000000] SBI specification v1.0 detected
> [ 0.000000] SBI implementation ID=0x1 Version=0x10003
> [ 0.000000] SBI TIME extension detected
> [ 0.000000] SBI IPI extension detected
> [ 0.000000] SBI RFENCE extension detected
> [ 0.000000] earlycon: uart0 at MMIO32 0x000000ffe7014000 (options '115200n8')
> [ 0.000000] printk: bootconsole [uart0] enabled
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] OF: reserved mem: 0x0000000000000000..0x000000000001ffff (128 KiB) nomap non-reusable mmode_resv0@0
> [ 0.000000] OF: reserved mem: 0x0000000000020000..0x000000000003ffff (128 KiB) nomap non-reusable mmode_resv1@20000
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
> [ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x000000000003ffff]
> [ 0.000000] node 0: [mem 0x0000000000040000-0x00000001ffffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
> [ 0.000000] SBI HSM extension detected
> [ 0.000000] riscv: base ISA extensions acdfim
> [ 0.000000] riscv: ELF capabilities acdfim
> [ 0.000000] percpu: Embedded 17 pages/cpu s38184 r0 d31448 u69632
> [ 0.000000] Kernel command line: earlycon console=ttyS0,115200
> [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2064384
> [ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> [ 0.000000] software IO TLB: area num 4.
> [ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
> [ 0.000000] Memory: 8145300K/8388608K available (4922K kernel code, 4786K rwdata, 2048K rodata, 2148K init, 393K bss, 243308K reserved, 0K cma-reserved)
> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] rcu: RCU event tracing is enabled.
> [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
> [ 0.000000] Trampoline variant of Tasks RCU enabled.
> [ 0.000000] Tracing variant of Tasks RCU enabled.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> [ 0.000000] riscv-intc: 64 local interrupts mapped
> [ 0.000000] plic: interrupt-controller@ffd8000000: mapped 240 interrupts with 4 handlers for 8 contexts.
> [ 0.000000] riscv: providing IPIs using SBI IPI extension
> [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
> [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1623fa770, max_idle_ns: 881590404476 ns
> [ 0.000001] sched_clock: 64 bits at 3000kHz, resolution 333ns, wraps every 4398046511097ns
> [ 0.008488] Console: colour dummy device 80x25
> [ 0.012944] Kernel panic - not syncing: unexpected interrupt cause
> [ 0.012952] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #1
> [ 0.012964] Hardware name: Sipeed Lichee Pi 4A (DT)
> [ 0.012970] Call Trace:
> [ 0.012976] [<ffffffff80004c38>] walk_stackframe+0x0/0x7e
> [ 0.013002] [<ffffffff804c868c>] dump_stack_lvl+0x34/0x4e
> [ 0.013022] [<ffffffff804c1334>] panic+0xf2/0x292
> [ 0.013035] [<ffffffff802cddc0>] riscv_intc_irq+0x34/0x38
> [ 0.013052] [<ffffffff804c8716>] handle_riscv_irq+0x66/0xa6
> [ 0.059145] ---[ end Kernel panic - not syncing: unexpected interrupt cause ]---
>
On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> which dts r u using? see below.
>
> >
> > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
> > miscompile the kernel?
/* snip */
> > Boot HART ID : 0
> > Boot HART Domain : root
> > Boot HART Priv Version : v1.11
> > Boot HART Base ISA : rv64imafdcvx
>
> what? I don't think the mainline dts provide v and x.
I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dtb
into /boot and loaded it with u-boot "load" command onto 0x46000000, and
passed this address to the booti command.
But maybe I've copied the wrong file or made some other mistake... I'll
recheck.
On Thu, 2023-07-27 at 08:14 +0800, Xi Ruoyao wrote:
> On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> > which dts r u using? see below.
> >
> > >
> > > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
> > > miscompile the kernel?
>
> /* snip */
>
> > > Boot HART ID : 0
> > > Boot HART Domain : root
> > > Boot HART Priv Version : v1.11
> > > Boot HART Base ISA : rv64imafdcvx
> >
> > what? I don't think the mainline dts provide v and x.
>
> I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dtb
> into /boot and loaded it with u-boot "load" command onto 0x46000000, and
> passed this address to the booti command.
>
> But maybe I've copied the wrong file or made some other mistake... I'll
> recheck.
Hmm, and if I read OpenSBI code correctly, this line reflects the
content of the misa CSR, not the DT riscv,isa value.
The log of successful boot provided by Drew also contains
"rv64imafdcvx":
https://gist.github.com/pdp7/23259595a7570f1f11086d286e16dfb6
On Thu, 2023-07-27 at 08:54 +0800, Xi Ruoyao wrote:
> On Thu, 2023-07-27 at 08:14 +0800, Xi Ruoyao wrote:
> > On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> > > which dts r u using? see below.
> > >
> > > >
> > > > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
> > > > miscompile the kernel?
> >
> > /* snip */
> >
> > > > Boot HART ID : 0
> > > > Boot HART Domain : root
> > > > Boot HART Priv Version : v1.11
> > > > Boot HART Base ISA : rv64imafdcvx
> > >
> > > what? I don't think the mainline dts provide v and x.
> >
> > I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dtb
> > into /boot and loaded it with u-boot "load" command onto 0x46000000, and
> > passed this address to the booti command.
> >
> > But maybe I've copied the wrong file or made some other mistake... I'll
> > recheck.
>
> Hmm, and if I read OpenSBI code correctly, this line reflects the
> content of the misa CSR, not the DT riscv,isa value.
>
> The log of successful boot provided by Drew also contains
> "rv64imafdcvx":
>
> https://gist.github.com/pdp7/23259595a7570f1f11086d286e16dfb6
I tried a __show_reg call before the panic:
[ 0.012953] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0-rc3 #7
[ 0.012967] Hardware name: Sipeed Lichee Pi 4A (DT)
[ 0.012976] epc : ffffffff80c84a60 ra : 0000000000000000 sp : ffffffff8004dfee
[ 0.012988] gp : 0000000200000120 tp : ffffffff80c03d20 t0 : ffffffff80002d6c
[ 0.012997] t1 : ffffffff8004dfee t2 : ffffffff8004dfe6 s0 : ffffffff80c03d20
[ 0.013005] s1 : ffffffff80c966f0 a0 : ffffffff80c98140 a1 : 2000000000000000
[ 0.013012] a2 : 0000000000000043 a3 : 203a656c6f736e6f a4 : ffffffff80c03def
[ 0.013021] a5 : ffffffff80dcb4a0 a6 : 0000000000000001 a7 : 0000000000000014
[ 0.013030] s2 : 000000000000000a s3 : 0000000000000000 s4 : 0000000000000000
[ 0.013036] s5 : ffffffd9fef69740 s6 : 0000000000000008 s7 : 0000000000000032
[ 0.013046] s8 : 0000000000000002 s9 : ffffffff80c03df0 s10: ffffffff80dcb4e8
[ 0.013056] s11: ffffffff80dc7c80 t3 : ffffffff80c03d48 t4 : ffffffff80dcb2f0
[ 0.013064] t5 : ffffffff80c84a60 t6 : ffffffff80c10b98
[ 0.013071] status: 0000000000000000 badaddr: 0000000000000001 cause: ffffffff80dcb4f7
[ 0.013082] Kernel panic - not syncing: unexpected interrupt cause
I compared these with System.map and the result seems completely erratic
(for example, sp is out of init_stack, and gp is not __global_pointer$).
On Thu, Jul 27, 2023 at 08:54:59AM +0800, Xi Ruoyao wrote:
> On Thu, 2023-07-27 at 08:14 +0800, Xi Ruoyao wrote:
> > On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> > > which dts r u using? see below.
> > >
> > > >
> > > > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
> > > > miscompile the kernel?
> >
> > /* snip */
> >
> > > > Boot HART ID : 0
> > > > Boot HART Domain : root
> > > > Boot HART Priv Version : v1.11
> > > > Boot HART Base ISA : rv64imafdcvx
> > >
> > > what? I don't think the mainline dts provide v and x.
> >
> > I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dtb
> > into /boot and loaded it with u-boot "load" command onto 0x46000000, and
> > passed this address to the booti command.
> >
> > But maybe I've copied the wrong file or made some other mistake... I'll
> > recheck.
>
> Hmm, and if I read OpenSBI code correctly, this line reflects the
> content of the misa CSR, not the DT riscv,isa value.
>
Aha indeed the "vx" isa extensions are not from the DT riscv,isa
property. I will try your opensbi/linux/uboot combinations on my
lpi4a board tomorrow.
> The log of successful boot provided by Drew also contains
> "rv64imafdcvx":
>
> https://gist.github.com/pdp7/23259595a7570f1f11086d286e16dfb6
>
On Fri, 2023-07-28 at 00:11 +0800, Jisheng Zhang wrote:
> On Thu, Jul 27, 2023 at 08:54:59AM +0800, Xi Ruoyao wrote:
> > On Thu, 2023-07-27 at 08:14 +0800, Xi Ruoyao wrote:
> > > On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> > > > which dts r u using? see below.
> > > >
> > > > >
> > > > > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no
> > > > > patches) can
> > > > > miscompile the kernel?
> > >
> > > /* snip */
> > >
> > > > > Boot HART ID : 0
> > > > > Boot HART Domain : root
> > > > > Boot HART Priv Version : v1.11
> > > > > Boot HART Base ISA : rv64imafdcvx
> > > >
> > > > what? I don't think the mainline dts provide v and x.
> > >
> > > I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-
> > > 4a.dtb
> > > into /boot and loaded it with u-boot "load" command onto
> > > 0x46000000, and
> > > passed this address to the booti command.
> > >
> > > But maybe I've copied the wrong file or made some other mistake...
> > > I'll
> > > recheck.
> >
> > Hmm, and if I read OpenSBI code correctly, this line reflects the
> > content of the misa CSR, not the DT riscv,isa value.
> >
>
> Aha indeed the "vx" isa extensions are not from the DT riscv,isa
> property. I will try your opensbi/linux/uboot combinations on my
> lpi4a board tomorrow.
My kernel config attached. Maybe you can find some stupid mistake in
it, I'm not familiar with RISC-V, nor DT-based systems :(.
>
> > The log of successful boot provided by Drew also contains
> > "rv64imafdcvx":
> >
> > https://gist.github.com/pdp7/23259595a7570f1f11086d286e16dfb6
> >
On Thu, Jul 27, 2023 at 08:54:59AM +0800, Xi Ruoyao wrote:
> On Thu, 2023-07-27 at 08:14 +0800, Xi Ruoyao wrote:
> > On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> > > which dts r u using? see below.
> > >
> > > >
> > > > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no patches) can
> > > > miscompile the kernel?
> >
> > /* snip */
> >
> > > > Boot HART ID????????????? : 0
> > > > Boot HART Domain????????? : root
> > > > Boot HART Priv Version??? : v1.11
> > > > Boot HART Base ISA??????? : rv64imafdcvx
> > >
> > > what? I don't think the mainline dts provide v and x.
> >
> > I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dtb
> > into /boot and loaded it with u-boot "load" command onto 0x46000000, and
> > passed this address to the booti command.
> >
> > But maybe I've copied the wrong file or made some other mistake... I'll
> > recheck.
>
> Hmm, and if I read OpenSBI code correctly, this line reflects the
> content of the misa CSR, not the DT riscv,isa value.
>
> The log of successful boot provided by Drew also contains
> "rv64imafdcvx":
>
> https://gist.github.com/pdp7/23259595a7570f1f11086d286e16dfb6
In case it helps, the thead fork of u-boot contains an important file
include/configs/light-c910.h that defines the boot scripts for each
board. Here is the BeagleV Ahead:
https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/blob/beaglev-v2020.01-1.1.2/include/configs/light-c910.h#L361
It might give some clues as to want commands to try.
From the lpi4a config:
https://github.com/revyos/thead-u-boot/blob/09e2c3f93f1a64c10ca51d9b9c0c22fbc0947c43/configs/light_lpi4a_defconfig
It looks like it sets:
CONFIG_TARGET_LIGHT_FM_C910_LPI4A=y
And that corresponds to:
https://github.com/revyos/thead-u-boot/blob/09e2c3f93f1a64c10ca51d9b9c0c22fbc0947c43/include/configs/light-c910.h#L425
Anyways, I finally got my Lichee Pi 4a out of the box, and I am going
to try it out too.
-Drew
On Fri, Jul 28, 2023 at 12:29:44AM +0800, Xi Ruoyao wrote:
> On Fri, 2023-07-28 at 00:11 +0800, Jisheng Zhang wrote:
> > On Thu, Jul 27, 2023 at 08:54:59AM +0800, Xi Ruoyao wrote:
> > > On Thu, 2023-07-27 at 08:14 +0800, Xi Ruoyao wrote:
> > > > On Wed, 2023-07-26 at 23:00 +0800, Jisheng Zhang wrote:
> > > > > which dts r u using? see below.
> > > > >
> > > > > >
> > > > > > Or maybe my toolchain (GCC 13.1.0, Binutils-2.40, with no
> > > > > > patches) can
> > > > > > miscompile the kernel?
> > > >
> > > > /* snip */
> > > >
> > > > > > Boot HART ID????????????? : 0
> > > > > > Boot HART Domain????????? : root
> > > > > > Boot HART Priv Version??? : v1.11
> > > > > > Boot HART Base ISA??????? : rv64imafdcvx
> > > > >
> > > > > what? I don't think the mainline dts provide v and x.
> > > >
> > > > I copied the compiled arch/riscv/boot/dts/thead/th1520-lichee-pi-
> > > > 4a.dtb
> > > > into /boot and loaded it with u-boot "load" command onto
> > > > 0x46000000, and
> > > > passed this address to the booti command.
> > > >
> > > > But maybe I've copied the wrong file or made some other mistake...
> > > > I'll
> > > > recheck.
> > >
> > > Hmm, and if I read OpenSBI code correctly, this line reflects the
> > > content of the misa CSR, not the DT riscv,isa value.
> > >
> >
> > Aha indeed the "vx" isa extensions are not from the DT riscv,isa
> > property. I will try your opensbi/linux/uboot combinations on my
> > lpi4a board tomorrow.
>
> My kernel config attached. Maybe you can find some stupid mistake in
> it, I'm not familiar with RISC-V, nor DT-based systems :(.
It seems like your kernel config is the problem. I used it and I saw
the same result of a panic in riscv_intc_irq:
https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
This is the config I have been using successfully:
https://gist.github.com/pdp7/ecb34ba1e93fc6cfc4dce66d71e14f82
Could you try that config?
Linux 6.5-rc3 boots okay when built with it:
https://gist.github.com/pdp7/580b072f9a5bf9be87cf88b5f81e50e3
Thanks,
Drew
On Fri, 2023-07-28 at 00:04 -0700, Drew Fustini wrote:
> It seems like your kernel config is the problem. I used it and I saw
> the same result of a panic in riscv_intc_irq:
> https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
>
> This is the config I have been using successfully:
> https://gist.github.com/pdp7/ecb34ba1e93fc6cfc4dce66d71e14f82
>
> Could you try that config?
>
> Linux 6.5-rc3 boots okay when built with it:
> https://gist.github.com/pdp7/580b072f9a5bf9be87cf88b5f81e50e3
Yes, your configuration works.
I'll try to figure out which specific configuration item is problematic
in my origin one...
On Fri, 2023-07-28 at 15:40 +0800, Xi Ruoyao wrote:
> On Fri, 2023-07-28 at 00:04 -0700, Drew Fustini wrote:
> > It seems like your kernel config is the problem. I used it and I saw
> > the same result of a panic in riscv_intc_irq:
> > https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
> >
> > This is the config I have been using successfully:
> > https://gist.github.com/pdp7/ecb34ba1e93fc6cfc4dce66d71e14f82
> >
> > Could you try that config?
> >
> > Linux 6.5-rc3 boots okay when built with it:
> > https://gist.github.com/pdp7/580b072f9a5bf9be87cf88b5f81e50e3
>
> Yes, your configuration works.
>
> I'll try to figure out which specific configuration item is problematic
> in my origin one...
Ah, I found it... If I deselect CONFIG_FRAME_POINTER it will crash.
And I see RISC-V selects ARCH_WANT_FRAME_POINTERS, so it seems frame
pointer is mandated. But then why I'm able to deselect
CONFIG_FRAME_POINTER?
On Fri, 28 Jul 2023 at 12:07, Xi Ruoyao <[email protected]> wrote:
>
> On Fri, 2023-07-28 at 15:40 +0800, Xi Ruoyao wrote:
> > On Fri, 2023-07-28 at 00:04 -0700, Drew Fustini wrote:
> > > It seems like your kernel config is the problem. I used it and I saw
> > > the same result of a panic in riscv_intc_irq:
> > > https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
> > >
> > > This is the config I have been using successfully:
> > > https://gist.github.com/pdp7/ecb34ba1e93fc6cfc4dce66d71e14f82
> > >
> > > Could you try that config?
> > >
> > > Linux 6.5-rc3 boots okay when built with it:
> > > https://gist.github.com/pdp7/580b072f9a5bf9be87cf88b5f81e50e3
> >
> > Yes, your configuration works.
> >
> > I'll try to figure out which specific configuration item is problematic
> > in my origin one...
>
> Ah, I found it... If I deselect CONFIG_FRAME_POINTER it will crash.
>
> And I see RISC-V selects ARCH_WANT_FRAME_POINTERS, so it seems frame
> pointer is mandated. But then why I'm able to deselect
> CONFIG_FRAME_POINTER?
You've probably run into this issue:
https://lore.kernel.org/linux-riscv/[email protected]/
Try applying those two patches.
/Emil
On Fri, Jul 28, 2023 at 12:23:12PM +0200, Emil Renner Berthing wrote:
> On Fri, 28 Jul 2023 at 12:07, Xi Ruoyao <[email protected]> wrote:
> >
> > On Fri, 2023-07-28 at 15:40 +0800, Xi Ruoyao wrote:
> > > On Fri, 2023-07-28 at 00:04 -0700, Drew Fustini wrote:
> > > > It seems like your kernel config is the problem. I used it and I saw
> > > > the same result of a panic in riscv_intc_irq:
> > > > https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
> > > >
> > > > This is the config I have been using successfully:
> > > > https://gist.github.com/pdp7/ecb34ba1e93fc6cfc4dce66d71e14f82
> > > >
> > > > Could you try that config?
> > > >
> > > > Linux 6.5-rc3 boots okay when built with it:
> > > > https://gist.github.com/pdp7/580b072f9a5bf9be87cf88b5f81e50e3
> > >
> > > Yes, your configuration works.
> > >
> > > I'll try to figure out which specific configuration item is problematic
> > > in my origin one...
> >
> > Ah, I found it... If I deselect CONFIG_FRAME_POINTER it will crash.
> >
> > And I see RISC-V selects ARCH_WANT_FRAME_POINTERS, so it seems frame
> > pointer is mandated. But then why I'm able to deselect
> > CONFIG_FRAME_POINTER?
>
> You've probably run into this issue:
> https://lore.kernel.org/linux-riscv/[email protected]/
>
> Try applying those two patches.
>
> /Emil
Thanks, I think that fixes the issue with CONFIG_FRAME_POINTER=n. I had
the same kernel crash [1] when trying the config from Xi [2].
I just did 'b4 shazam [email protected]' and
the riscv_intc_irq panic no longer occurs [3]. I don't have the mmc
patches applied on this branch so the boot just hangs at mounting rootfs
but I think it is otherwise okay.
Drew
[1] https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
[2] https://gist.github.com/pdp7/c6e358be892d506826be304dcc346a7a
[3] https://gist.github.com/pdp7/871ada434febeca4ff93f2381352c038
On Fri, 2023-07-28 at 10:53 -0700, Drew Fustini wrote:
> On Fri, Jul 28, 2023 at 12:23:12PM +0200, Emil Renner Berthing wrote:
> > On Fri, 28 Jul 2023 at 12:07, Xi Ruoyao <[email protected]> wrote:
> > >
> > > On Fri, 2023-07-28 at 15:40 +0800, Xi Ruoyao wrote:
> > > > On Fri, 2023-07-28 at 00:04 -0700, Drew Fustini wrote:
> > > > > It seems like your kernel config is the problem. I used it and I saw
> > > > > the same result of a panic in riscv_intc_irq:
> > > > > https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
> > > > >
> > > > > This is the config I have been using successfully:
> > > > > https://gist.github.com/pdp7/ecb34ba1e93fc6cfc4dce66d71e14f82
> > > > >
> > > > > Could you try that config?
> > > > >
> > > > > Linux 6.5-rc3 boots okay when built with it:
> > > > > https://gist.github.com/pdp7/580b072f9a5bf9be87cf88b5f81e50e3
> > > >
> > > > Yes, your configuration works.
> > > >
> > > > I'll try to figure out which specific configuration item is problematic
> > > > in my origin one...
> > >
> > > Ah, I found it... If I deselect CONFIG_FRAME_POINTER it will crash.
> > >
> > > And I see RISC-V selects ARCH_WANT_FRAME_POINTERS, so it seems frame
> > > pointer is mandated. But then why I'm able to deselect
> > > CONFIG_FRAME_POINTER?
> >
> > You've probably run into this issue:
> > https://lore.kernel.org/linux-riscv/[email protected]/
> >
> > Try applying those two patches.
> >
> > /Emil
>
> Thanks, I think that fixes the issue with CONFIG_FRAME_POINTER=n. I had
> the same kernel crash [1] when trying the config from Xi [2].
>
> I just did 'b4 shazam [email protected]' and
> the riscv_intc_irq panic no longer occurs [3]. I don't have the mmc
> patches applied on this branch so the boot just hangs at mounting rootfs
> but I think it is otherwise okay.
Again thanks for your help! I'm looking forward to your MMC driver :).
> [1] https://gist.github.com/pdp7/1a26ebe20017a3b90c4e9c005f8178e1
> [2] https://gist.github.com/pdp7/c6e358be892d506826be304dcc346a7a
> [3] https://gist.github.com/pdp7/871ada434febeca4ff93f2381352c038
On Fri, Aug 11, 2023 at 10:39:02AM -0700, Drew Fustini wrote:
> On Sun, Jun 18, 2023 at 12:15:21AM +0800, Jisheng Zhang wrote:
> > Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> > module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> > tree files for the core module and the development board.
> >
> > Support basic uart/gpio/dmac drivers, so supports booting to a basic
> > shell.
> >
> > NOTE: the thead cpu reset dt-binding and DT node are removed in v3. This
> > makes secondary CPUs unable to be online. However, minimal th1520
> > support is better than nothing. And the community has been working on
> > and will work on the cpu reset dt-binding, for example, Conor, Guo and
> > Jessica are discussing about it, I have seen valuable comments and
> > inputs from them. I believe we can add back cpu reset in next
> > development window.
>
> I'm interested in starting the secondary cpus on mainline. It seems that
> that "thead,reset-sample" is already implemented in upstream OpenSBI in
> lib/utils/reset/fdt_reset_thead.c and the issue is getting the
> dt-binding accepted. Is that correct?
There was nothing in the original series (AFAIR) that actually uses the
properties. Including it in the Linux DTS just makes life easier, since
the dts could also be used in OpenSBI?
> It looks like you've tried to restart the discussion on the DT list [1]
> so I hope that the DT maintainers will give their perspective.
I'm not sure what there is to say. I already gave feedback about it
which has been ignored.
On Sun, Jun 18, 2023 at 12:15:21AM +0800, Jisheng Zhang wrote:
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's TH1520 SoC. Add minimal device
> tree files for the core module and the development board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
>
> NOTE: the thead cpu reset dt-binding and DT node are removed in v3. This
> makes secondary CPUs unable to be online. However, minimal th1520
> support is better than nothing. And the community has been working on
> and will work on the cpu reset dt-binding, for example, Conor, Guo and
> Jessica are discussing about it, I have seen valuable comments and
> inputs from them. I believe we can add back cpu reset in next
> development window.
I'm interested in starting the secondary cpus on mainline. It seems that
that "thead,reset-sample" is already implemented in upstream OpenSBI in
lib/utils/reset/fdt_reset_thead.c and the issue is getting the
dt-binding accepted. Is that correct?
It looks like you've tried to restart the discussion on the DT list [1]
so I hope that the DT maintainers will give their perspective.
Thank you,
Drew
[1] https://lore.kernel.org/all/ZNURXBKkYdiWLanf@xhacker/