| Message ID | 20230617161529.2092-1-jszhang@kernel.org |
|---|---|
| Headers | show |
| Series | Add Sipeed Lichee Pi 4A RISC-V board support | expand |
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 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 <conor.dooley@microchip.com> > > > > 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.
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, 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.
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, 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 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: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 <xry111@linuxfromscratch.org> 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/20230716001506.3506041-1-guoren@kernel.org/ 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 <xry111@linuxfromscratch.org> 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/20230716001506.3506041-1-guoren@kernel.org/ > > 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 20230716001506.3506041-1-guoren@kernel.org' 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 <xry111@linuxfromscratch.org> 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/20230716001506.3506041-1-guoren@kernel.org/ > > > > 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 20230716001506.3506041-1-guoren@kernel.org' 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.