* [PATCH 00/10] Kendryte k210 SoC boards support
@ 2020-02-12 10:34 Damien Le Moal
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
` (12 more replies)
0 siblings, 13 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
This series adds support to boot nommu Linux on Kendryte K210 SoC based
boards. This is all based on initial work done by Christoph Hellwig.
The first 2 patches fix riscv gitignore and a potential nommu
compilation error. These patches are not specific to the Kendryte
support.
Patch 3 adds unaligned load/store trap handlers for M-mode.
Patch 4 enables a builtin DTB to allow passing a device tree to the
kernel when the board bootchain is enabled to pass one.
Patch 5 introduces an early SoC initialization enabling very early
hardware initialization not possible with device tree entries pointing
to drivers. This is used in patch 6 which introduces a sysctl driver for
the K210 SoC. The early SoC initialization is used to enable the
additional 2MB of SRAM normally reserved to the SoC AI chip.
Patch 7 to 9 add necessary Kconfig changes, a defconfig and a generic
device tree suitable for many K210 boards.
Finally, patch 10 adds compilation of a bootable image file (bin file)
that can be used to flash the board ROM.
This series was tested on the Kendryte KD233 development board, the
Sipeed MAIX dan dock board and the Sipeed MAIXDUINO board. The userspace
used was built using a modified buildroot tree for the toolchain part
and an unmodified busybox tree for the initramfs image (embedded in the
kernel as a cpio file). The folowwing github project contains the
modified buildroot tree:
https://github.com/damien-lemoal/riscv64-nommu-buildroot
This is based on work from Christoph Hellwig, with additional changes
and updates to the latest upstream versions for buildroot and uClibc.
Precompiled versions of the toolchain (gcc 9.2) and initramfs file tree
and cpio file can be found in this project under the directory:
buildroot/riscv64-uclibc-nommu/
Flashing the file arch/riscv/boot/loader.bin to a board can be done
using the Sipeed kflash.py tool with the command:
kflash.py/kflash.py -p /dev/ttyUSB0 -b 1500000 -t loader.bin
The kflash.py tool can be found here:
https://github.com/sipeed/kflash.py
For reference, using the Sipeed MAIXDUINO board, here is the boot
output:
[INFO] Rebooting...
--- forcing DTR inactive
--- forcing RTS inactive
--- Miniterm on /dev/ttyUSB0 115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
[ 0.000000] Linux version 5.6.0-rc1-00011-ga2b5be1c4374 (damien@yyy) (gcc version 8.2.0 (Buildroot 2018.11-rc2-00003-ga0787e9)) #610 SMP Wed Feb 12 18:53:50 JST 2020
[ 0.000000] earlycon: sifive0 at MMIO 0x0000000038000000 (options '')
[ 0.000000] printk: bootconsole [sifive0] enabled
[ 0.000000] initrd not found or empty - disabling initrd
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000080000000-0x00000000807fffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080000000-0x00000000807fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000807fffff]
[ 0.000000] elf_hwcap is 0x112d
[ 0.000000] percpu: max_distance=0x18000 too large for vmalloc space 0x0
[ 0.000000] percpu: Embedded 12 pages/cpu s18272 r0 d30880 u49152
[ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020
[ 0.000000] Kernel command line: earlycon console=ttySIF0
[ 0.000000] Dentry cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.000000] Sorting __ex_table...
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 6328K/8192K available (924K kernel code, 110K rwdata, 164K rodata, 321K init, 91K bss, 1864K reserved, 0K cma-reserved)
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[ 0.000000] plic: mapped 65 interrupts with 2 handlers for 4 contexts.
[ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
[ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x3990be68b, max_idle_ns: 881590404272 ns
[ 0.000014] sched_clock: 64 bits at 7MHz, resolution 128ns, wraps every 4398046511054ns
[ 0.008232] Console: colour dummy device 80x25
[ 0.012474] Calibrating delay loop (skipped), value calculated using timer frequency.. 15.60 BogoMIPS (lpj=31200)
[ 0.022678] pid_max: default: 4096 minimum: 301
[ 0.027288] Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.034414] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.044796] rcu: Hierarchical SRCU implementation.
[ 0.049602] smp: Bringing up secondary CPUs ...
[ 0.054746] smp: Brought up 1 node, 2 CPUs
[ 0.059093] devtmpfs: initialized
[ 0.065523] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.074544] futex hash table entries: 16 (order: -2, 1024 bytes, linear)
[ 0.082512] Kendryte K210 SoC sysctl
[ 0.096010] clocksource: Switched to clocksource riscv_clocksource
[ 0.178581] workingset: timestamp_bits=62 max_order=11 bucket_order=0
[ 0.185846] 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 0) is a SiFive UART v0
[ 0.194344] printk: console [ttySIF0] enabled
[ 0.194344] printk: console [ttySIF0] enabled
[ 0.202929] printk: bootconsole [sifive0] disabled
[ 0.202929] printk: bootconsole [sifive0] disabled
[ 0.214853] random: get_random_bytes called from 0x0000000080055178 with crng_init=0
[ 0.223606] devtmpfs: mounted
[ 0.226861] Freeing unused kernel memory: 320K
[ 0.230574] This architecture does not have kernel memory protection.
[ 0.236987] Run /sbin/init as init process
[ 0.241181] Run /etc/init as init process
[ 0.245178] Run /bin/init as init process
-----------------------------
| Kendryte K210 NOMMU Linux |
-----------------------------
Mounting /proc
Starting shell
BusyBox v1.32.0.git (2020-02-12 17:51:45 JST) hush - the humble shell
Enter 'help' for a list of built-in commands.
/ # cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdc
processor : 1
hart : 1
isa : rv64imafdc
/ #
/ # ls -l /
drwxrwxr-x 2 1000 1000 0 Feb 12 2020 bin
drwxr-xr-x 2 0 0 0 Jan 1 00:00 dev
drwxrwxr-x 2 1000 1000 0 Feb 12 2020 etc
dr-xr-xr-x 58 0 0 0 Jan 1 00:00 proc
drwxrwxr-x 2 1000 1000 0 Feb 12 2020 root
drwxrwxr-x 2 1000 1000 0 Feb 12 2020 sbin
drwxrwxr-x 2 1000 1000 0 Feb 12 2020 sys
drwxrwxr-x 2 1000 1000 0 Feb 12 2020 tmp
drwxrwxr-x 4 1000 1000 0 Feb 12 2020 usr
/ #
/ # cat /proc/vmstat
nr_free_pages 1148
...
/ #
The K210 SoC has more devices (GPIO, SD-card, LCD, etc) that likely can
be enabled and used. For this, the sysctl driver will need further
improvements as each device uses a different clock. To share the fun,
supporting these is left as an exercise for the hobbyist and hackers
interested in this SoC/boards :)
Christoph Hellwig (2):
riscv: Add Kendryte K210 SoC support
riscv: create a loader.bin for the kendryte kflash.py tool
Damien Le Moal (8):
riscv: Fix gitignore
riscv: Force flat memory model with no-mmu
riscv: Unaligned load/store handling for M_MODE
riscv: Add BUILTIN_DTB support
riscv: Add SOC early init support
riscv: Select required drivers for Kendryte SOC
riscv: Add Kendryte K210 device tree
riscv: Kendryte K210 default config
arch/riscv/Kbuild | 1 +
arch/riscv/Kconfig | 19 ++
arch/riscv/Kconfig.socs | 10 +
arch/riscv/Makefile | 4 +-
arch/riscv/boot/.gitignore | 2 +
arch/riscv/boot/Makefile | 3 +
arch/riscv/boot/dts/Makefile | 5 +
arch/riscv/boot/dts/kendryte/Makefile | 2 +
arch/riscv/boot/dts/kendryte/k210.dts | 23 ++
arch/riscv/boot/dts/kendryte/k210.dtsi | 123 ++++++++
arch/riscv/configs/nommu_k210_defconfig | 68 +++++
arch/riscv/include/asm/soc.h | 23 ++
arch/riscv/kernel/Makefile | 3 +-
arch/riscv/kernel/head.S | 1 +
arch/riscv/kernel/setup.c | 6 +
arch/riscv/kernel/soc.c | 28 ++
arch/riscv/kernel/traps.c | 27 +-
arch/riscv/kernel/traps_misaligned.c | 371 ++++++++++++++++++++++++
arch/riscv/kernel/vmlinux.lds.S | 6 +
arch/riscv/mm/init.c | 4 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/kendryte/Kconfig | 14 +
drivers/soc/kendryte/Makefile | 3 +
drivers/soc/kendryte/k210-sysctl.c | 245 ++++++++++++++++
25 files changed, 987 insertions(+), 6 deletions(-)
create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
create mode 100644 arch/riscv/configs/nommu_k210_defconfig
create mode 100644 arch/riscv/include/asm/soc.h
create mode 100644 arch/riscv/kernel/soc.c
create mode 100644 arch/riscv/kernel/traps_misaligned.c
create mode 100644 drivers/soc/kendryte/Kconfig
create mode 100644 drivers/soc/kendryte/Makefile
create mode 100644 drivers/soc/kendryte/k210-sysctl.c
--
2.24.1
^ permalink raw reply [flat|nested] 89+ messages in thread
* [PATCH 01/10] riscv: Fix gitignore
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-02-20 0:15 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
` (11 subsequent siblings)
12 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Tell git to not track the compiled boot/loader and boot/loader.lds
files.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/boot/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/boot/.gitignore b/arch/riscv/boot/.gitignore
index 8dab0bb6ae66..8a45a37d2af4 100644
--- a/arch/riscv/boot/.gitignore
+++ b/arch/riscv/boot/.gitignore
@@ -1,2 +1,4 @@
Image
Image.gz
+loader
+loader.lds
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-02-14 20:18 ` Sean Anderson
` (2 more replies)
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
` (10 subsequent siblings)
12 siblings, 3 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
a nommu kernel. Since the sparsemem model does not make sense anyway
for the nommu case, do not allow selecting this option to always use
the flatmem model.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 73f029eae0cc..1a3b5a5276be 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
config ARCH_SPARSEMEM_ENABLE
def_bool y
+ depends on MMU
select SPARSEMEM_VMEMMAP_ENABLE
config ARCH_SELECT_MEMORY_MODEL
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-03-02 3:57 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
` (9 subsequent siblings)
12 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Add handlers for unaligned load and stroe traps that may be generated
by applications. Code heavily inspired from the OpenSBI project.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
---
arch/riscv/kernel/Makefile | 2 +-
arch/riscv/kernel/traps.c | 27 +-
arch/riscv/kernel/traps_misaligned.c | 371 +++++++++++++++++++++++++++
3 files changed, 396 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/kernel/traps_misaligned.c
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index f40205cb9a22..97d0c35f8b37 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -28,7 +28,7 @@ obj-y += stacktrace.o
obj-y += cacheinfo.o
obj-$(CONFIG_MMU) += vdso.o vdso/
-obj-$(CONFIG_RISCV_M_MODE) += clint.o
+obj-$(CONFIG_RISCV_M_MODE) += clint.o traps_misaligned.o
obj-$(CONFIG_FPU) += fpu.o
obj-$(CONFIG_SMP) += smpboot.o
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index ffb3d94bf0cc..13e55459d7b0 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -97,12 +97,33 @@ DO_ERROR_INFO(do_trap_insn_fault,
SIGSEGV, SEGV_ACCERR, "instruction access fault");
DO_ERROR_INFO(do_trap_insn_illegal,
SIGILL, ILL_ILLOPC, "illegal instruction");
-DO_ERROR_INFO(do_trap_load_misaligned,
- SIGBUS, BUS_ADRALN, "load address misaligned");
DO_ERROR_INFO(do_trap_load_fault,
SIGSEGV, SEGV_ACCERR, "load access fault");
+#ifndef CONFIG_RISCV_M_MODE
+DO_ERROR_INFO(do_trap_load_misaligned,
+ SIGBUS, BUS_ADRALN, "Oops - load address misaligned");
DO_ERROR_INFO(do_trap_store_misaligned,
- SIGBUS, BUS_ADRALN, "store (or AMO) address misaligned");
+ SIGBUS, BUS_ADRALN, "Oops - store (or AMO) address misaligned");
+#else
+int handle_misaligned_load(struct pt_regs *regs);
+int handle_misaligned_store(struct pt_regs *regs);
+
+asmlinkage void do_trap_load_misaligned(struct pt_regs *regs)
+{
+ if (!handle_misaligned_load(regs))
+ return;
+ do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
+ "Oops - load address misaligned");
+}
+
+asmlinkage void do_trap_store_misaligned(struct pt_regs *regs)
+{
+ if (!handle_misaligned_store(regs))
+ return;
+ do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
+ "Oops - store (or AMO) address misaligned");
+}
+#endif
DO_ERROR_INFO(do_trap_store_fault,
SIGSEGV, SEGV_ACCERR, "store (or AMO) access fault");
DO_ERROR_INFO(do_trap_ecall_u,
diff --git a/arch/riscv/kernel/traps_misaligned.c b/arch/riscv/kernel/traps_misaligned.c
new file mode 100644
index 000000000000..a6105ee0150f
--- /dev/null
+++ b/arch/riscv/kernel/traps_misaligned.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+
+#include <asm/processor.h>
+#include <asm/ptrace.h>
+#include <asm/csr.h>
+
+#define INSN_MATCH_LB 0x3
+#define INSN_MASK_LB 0x707f
+#define INSN_MATCH_LH 0x1003
+#define INSN_MASK_LH 0x707f
+#define INSN_MATCH_LW 0x2003
+#define INSN_MASK_LW 0x707f
+#define INSN_MATCH_LD 0x3003
+#define INSN_MASK_LD 0x707f
+#define INSN_MATCH_LBU 0x4003
+#define INSN_MASK_LBU 0x707f
+#define INSN_MATCH_LHU 0x5003
+#define INSN_MASK_LHU 0x707f
+#define INSN_MATCH_LWU 0x6003
+#define INSN_MASK_LWU 0x707f
+#define INSN_MATCH_SB 0x23
+#define INSN_MASK_SB 0x707f
+#define INSN_MATCH_SH 0x1023
+#define INSN_MASK_SH 0x707f
+#define INSN_MATCH_SW 0x2023
+#define INSN_MASK_SW 0x707f
+#define INSN_MATCH_SD 0x3023
+#define INSN_MASK_SD 0x707f
+
+#define INSN_MATCH_FLW 0x2007
+#define INSN_MASK_FLW 0x707f
+#define INSN_MATCH_FLD 0x3007
+#define INSN_MASK_FLD 0x707f
+#define INSN_MATCH_FLQ 0x4007
+#define INSN_MASK_FLQ 0x707f
+#define INSN_MATCH_FSW 0x2027
+#define INSN_MASK_FSW 0x707f
+#define INSN_MATCH_FSD 0x3027
+#define INSN_MASK_FSD 0x707f
+#define INSN_MATCH_FSQ 0x4027
+#define INSN_MASK_FSQ 0x707f
+
+#define INSN_MATCH_C_LD 0x6000
+#define INSN_MASK_C_LD 0xe003
+#define INSN_MATCH_C_SD 0xe000
+#define INSN_MASK_C_SD 0xe003
+#define INSN_MATCH_C_LW 0x4000
+#define INSN_MASK_C_LW 0xe003
+#define INSN_MATCH_C_SW 0xc000
+#define INSN_MASK_C_SW 0xe003
+#define INSN_MATCH_C_LDSP 0x6002
+#define INSN_MASK_C_LDSP 0xe003
+#define INSN_MATCH_C_SDSP 0xe002
+#define INSN_MASK_C_SDSP 0xe003
+#define INSN_MATCH_C_LWSP 0x4002
+#define INSN_MASK_C_LWSP 0xe003
+#define INSN_MATCH_C_SWSP 0xc002
+#define INSN_MASK_C_SWSP 0xe003
+
+#define INSN_MATCH_C_FLD 0x2000
+#define INSN_MASK_C_FLD 0xe003
+#define INSN_MATCH_C_FLW 0x6000
+#define INSN_MASK_C_FLW 0xe003
+#define INSN_MATCH_C_FSD 0xa000
+#define INSN_MASK_C_FSD 0xe003
+#define INSN_MATCH_C_FSW 0xe000
+#define INSN_MASK_C_FSW 0xe003
+#define INSN_MATCH_C_FLDSP 0x2002
+#define INSN_MASK_C_FLDSP 0xe003
+#define INSN_MATCH_C_FSDSP 0xa002
+#define INSN_MASK_C_FSDSP 0xe003
+#define INSN_MATCH_C_FLWSP 0x6002
+#define INSN_MASK_C_FLWSP 0xe003
+#define INSN_MATCH_C_FSWSP 0xe002
+#define INSN_MASK_C_FSWSP 0xe003
+
+#define INSN_LEN(insn) ((((insn) & 0x3) < 0x3) ? 2 : 4)
+
+#if __riscv_xlen == 64
+#define LOG_REGBYTES 3
+#else
+#define LOG_REGBYTES 2
+#endif
+#define REGBYTES (1 << LOG_REGBYTES)
+
+#define SH_RD 7
+#define SH_RS1 15
+#define SH_RS2 20
+#define SH_RS2C 2
+
+#define RV_X(x, s, n) (((x) >> (s)) & ((1 << (n)) - 1))
+#define RVC_LW_IMM(x) ((RV_X(x, 6, 1) << 2) | \
+ (RV_X(x, 10, 3) << 3) | \
+ (RV_X(x, 5, 1) << 6))
+#define RVC_LD_IMM(x) ((RV_X(x, 10, 3) << 3) | \
+ (RV_X(x, 5, 2) << 6))
+#define RVC_LWSP_IMM(x) ((RV_X(x, 4, 3) << 2) | \
+ (RV_X(x, 12, 1) << 5) | \
+ (RV_X(x, 2, 2) << 6))
+#define RVC_LDSP_IMM(x) ((RV_X(x, 5, 2) << 3) | \
+ (RV_X(x, 12, 1) << 5) | \
+ (RV_X(x, 2, 3) << 6))
+#define RVC_SWSP_IMM(x) ((RV_X(x, 9, 4) << 2) | \
+ (RV_X(x, 7, 2) << 6))
+#define RVC_SDSP_IMM(x) ((RV_X(x, 10, 3) << 3) | \
+ (RV_X(x, 7, 3) << 6))
+#define RVC_RS1S(insn) (8 + RV_X(insn, SH_RD, 3))
+#define RVC_RS2S(insn) (8 + RV_X(insn, SH_RS2C, 3))
+#define RVC_RS2(insn) RV_X(insn, SH_RS2C, 5)
+
+#define SHIFT_RIGHT(x, y) \
+ ((y) < 0 ? ((x) << -(y)) : ((x) >> (y)))
+
+#define REG_MASK \
+ ((1 << (5 + LOG_REGBYTES)) - (1 << LOG_REGBYTES))
+
+#define REG_OFFSET(insn, pos) \
+ (SHIFT_RIGHT((insn), (pos) - LOG_REGBYTES) & REG_MASK)
+
+#define REG_PTR(insn, pos, regs) \
+ (ulong *)((ulong)(regs) + REG_OFFSET(insn, pos))
+
+#define GET_RM(insn) (((insn) >> 12) & 7)
+
+#define GET_RS1(insn, regs) (*REG_PTR(insn, SH_RS1, regs))
+#define GET_RS2(insn, regs) (*REG_PTR(insn, SH_RS2, regs))
+#define GET_RS1S(insn, regs) (*REG_PTR(RVC_RS1S(insn), 0, regs))
+#define GET_RS2S(insn, regs) (*REG_PTR(RVC_RS2S(insn), 0, regs))
+#define GET_RS2C(insn, regs) (*REG_PTR(insn, SH_RS2C, regs))
+#define GET_SP(regs) (*REG_PTR(2, 0, regs))
+#define SET_RD(insn, regs, val) (*REG_PTR(insn, SH_RD, regs) = (val))
+#define IMM_I(insn) ((s32)(insn) >> 20)
+#define IMM_S(insn) (((s32)(insn) >> 25 << 5) | \
+ (s32)(((insn) >> 7) & 0x1f))
+#define MASK_FUNCT3 0x7000
+
+#define GET_PRECISION(insn) (((insn) >> 25) & 3)
+#define GET_RM(insn) (((insn) >> 12) & 7)
+#define PRECISION_S 0
+#define PRECISION_D 1
+
+#define STR(x) XSTR(x)
+#define XSTR(x) #x
+
+#define DECLARE_UNPRIVILEGED_LOAD_FUNCTION(type, insn) \
+static inline type load_##type(const type *addr) \
+{ \
+ type val; \
+ asm (#insn " %0, %1" \
+ : "=&r" (val) : "m" (*addr)); \
+ return val; \
+}
+
+#define DECLARE_UNPRIVILEGED_STORE_FUNCTION(type, insn) \
+static inline void store_##type(type *addr, type val) \
+{ \
+ asm volatile (#insn " %0, %1\n" \
+ : : "r" (val), "m" (*addr)); \
+}
+
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u8, lbu)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u16, lhu)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s8, lb)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s16, lh)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s32, lw)
+DECLARE_UNPRIVILEGED_STORE_FUNCTION(u8, sb)
+DECLARE_UNPRIVILEGED_STORE_FUNCTION(u16, sh)
+DECLARE_UNPRIVILEGED_STORE_FUNCTION(u32, sw)
+#if __riscv_xlen == 64
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u32, lwu)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u64, ld)
+DECLARE_UNPRIVILEGED_STORE_FUNCTION(u64, sd)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(ulong, ld)
+#else
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u32, lw)
+DECLARE_UNPRIVILEGED_LOAD_FUNCTION(ulong, lw)
+
+static inline u64 load_u64(const u64 *addr)
+{
+ return load_u32((u32 *)addr)
+ + ((u64)load_u32((u32 *)addr + 1) << 32);
+}
+
+static inline void store_u64(u64 *addr, u64 val)
+{
+ store_u32((u32 *)addr, val);
+ store_u32((u32 *)addr + 1, val >> 32);
+}
+#endif
+
+static inline ulong get_insn(ulong mepc)
+{
+ register ulong __mepc asm ("a2") = mepc;
+ ulong val, rvc_mask = 3, tmp;
+
+ asm ("and %[tmp], %[addr], 2\n"
+ "bnez %[tmp], 1f\n"
+#if __riscv_xlen == 64
+ STR(LWU) " %[insn], (%[addr])\n"
+#else
+ STR(LW) " %[insn], (%[addr])\n"
+#endif
+ "and %[tmp], %[insn], %[rvc_mask]\n"
+ "beq %[tmp], %[rvc_mask], 2f\n"
+ "sll %[insn], %[insn], %[xlen_minus_16]\n"
+ "srl %[insn], %[insn], %[xlen_minus_16]\n"
+ "j 2f\n"
+ "1:\n"
+ "lhu %[insn], (%[addr])\n"
+ "and %[tmp], %[insn], %[rvc_mask]\n"
+ "bne %[tmp], %[rvc_mask], 2f\n"
+ "lhu %[tmp], 2(%[addr])\n"
+ "sll %[tmp], %[tmp], 16\n"
+ "add %[insn], %[insn], %[tmp]\n"
+ "2:"
+ : [insn] "=&r" (val), [tmp] "=&r" (tmp)
+ : [addr] "r" (__mepc), [rvc_mask] "r" (rvc_mask),
+ [xlen_minus_16] "i" (__riscv_xlen - 16));
+
+ return val;
+}
+
+union reg_data {
+ u8 data_bytes[8];
+ ulong data_ulong;
+ u64 data_u64;
+};
+
+int handle_misaligned_load(struct pt_regs *regs)
+{
+ union reg_data val;
+ unsigned long epc = regs->epc;
+ unsigned long insn = get_insn(epc);
+ unsigned long addr = csr_read(mtval);
+ int i, fp = 0, shift = 0, len = 0;
+
+ regs->epc = 0;
+
+ if ((insn & INSN_MASK_LW) == INSN_MATCH_LW) {
+ len = 4;
+ shift = 8 * (sizeof(unsigned long) - len);
+#if __riscv_xlen == 64
+ } else if ((insn & INSN_MASK_LD) == INSN_MATCH_LD) {
+ len = 8;
+ shift = 8 * (sizeof(unsigned long) - len);
+ } else if ((insn & INSN_MASK_LWU) == INSN_MATCH_LWU) {
+ len = 4;
+#endif
+ } else if ((insn & INSN_MASK_FLD) == INSN_MATCH_FLD) {
+ fp = 1;
+ len = 8;
+ } else if ((insn & INSN_MASK_FLW) == INSN_MATCH_FLW) {
+ fp = 1;
+ len = 4;
+ } else if ((insn & INSN_MASK_LH) == INSN_MATCH_LH) {
+ len = 2;
+ shift = 8 * (sizeof(unsigned long) - len);
+ } else if ((insn & INSN_MASK_LHU) == INSN_MATCH_LHU) {
+ len = 2;
+#ifdef __riscv_compressed
+#if __riscv_xlen >= 64
+ } else if ((insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD) {
+ len = 8;
+ shift = 8 * (sizeof(unsigned long) - len);
+ insn = RVC_RS2S(insn) << SH_RD;
+ } else if ((insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
+ ((insn >> SH_RD) & 0x1f)) {
+ len = 8;
+ shift = 8 * (sizeof(unsigned long) - len);
+#endif
+ } else if ((insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW) {
+ len = 4;
+ shift = 8 * (sizeof(unsigned long) - len);
+ insn = RVC_RS2S(insn) << SH_RD;
+ } else if ((insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
+ ((insn >> SH_RD) & 0x1f)) {
+ len = 4;
+ shift = 8 * (sizeof(unsigned long) - len);
+ } else if ((insn & INSN_MASK_C_FLD) == INSN_MATCH_C_FLD) {
+ fp = 1;
+ len = 8;
+ insn = RVC_RS2S(insn) << SH_RD;
+ } else if ((insn & INSN_MASK_C_FLDSP) == INSN_MATCH_C_FLDSP) {
+ fp = 1;
+ len = 8;
+#if __riscv_xlen == 32
+ } else if ((insn & INSN_MASK_C_FLW) == INSN_MATCH_C_FLW) {
+ fp = 1;
+ len = 4;
+ insn = RVC_RS2S(insn) << SH_RD;
+ } else if ((insn & INSN_MASK_C_FLWSP) == INSN_MATCH_C_FLWSP) {
+ fp = 1;
+ len = 4;
+#endif
+#endif
+ } else {
+ regs->epc = epc;
+ return -1;
+ }
+
+ val.data_u64 = 0;
+ for (i = 0; i < len; i++)
+ val.data_bytes[i] = load_u8((void *)(addr + i));
+
+ if (fp)
+ return -1;
+ SET_RD(insn, regs, val.data_ulong << shift >> shift);
+
+ regs->epc = epc + INSN_LEN(insn);
+
+ return 0;
+}
+
+int handle_misaligned_store(struct pt_regs *regs)
+{
+ union reg_data val;
+ unsigned long epc = regs->epc;
+ unsigned long insn = get_insn(epc);
+ unsigned long addr = csr_read(mtval);
+ int i, len = 0;
+
+ regs->epc = 0;
+
+ val.data_ulong = GET_RS2(insn, regs);
+
+ if ((insn & INSN_MASK_SW) == INSN_MATCH_SW) {
+ len = 4;
+#if __riscv_xlen == 64
+ } else if ((insn & INSN_MASK_SD) == INSN_MATCH_SD) {
+ len = 8;
+#endif
+ } else if ((insn & INSN_MASK_SH) == INSN_MATCH_SH) {
+ len = 2;
+#ifdef __riscv_compressed
+#if __riscv_xlen >= 64
+ } else if ((insn & INSN_MASK_C_SD) == INSN_MATCH_C_SD) {
+ len = 8;
+ val.data_ulong = GET_RS2S(insn, regs);
+ } else if ((insn & INSN_MASK_C_SDSP) == INSN_MATCH_C_SDSP &&
+ ((insn >> SH_RD) & 0x1f)) {
+ len = 8;
+ val.data_ulong = GET_RS2C(insn, regs);
+#endif
+ } else if ((insn & INSN_MASK_C_SW) == INSN_MATCH_C_SW) {
+ len = 4;
+ val.data_ulong = GET_RS2S(insn, regs);
+ } else if ((insn & INSN_MASK_C_SWSP) == INSN_MATCH_C_SWSP &&
+ ((insn >> SH_RD) & 0x1f)) {
+ len = 4;
+ val.data_ulong = GET_RS2C(insn, regs);
+#endif
+ } else {
+ regs->epc = epc;
+ return -1;
+ }
+
+ for (i = 0; i < len; i++)
+ store_u8((void *)(addr + i), val.data_bytes[i]);
+
+ regs->epc = epc + INSN_LEN(insn);
+
+ return 0;
+}
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (2 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-03-02 3:58 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
` (8 subsequent siblings)
12 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Enable a kernel builtin dtb for boards not capable of providing a
device tree to the kernel.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/Kbuild | 1 +
arch/riscv/Kconfig | 18 ++++++++++++++++++
arch/riscv/boot/dts/Makefile | 4 ++++
arch/riscv/kernel/setup.c | 6 ++++++
arch/riscv/mm/init.c | 4 ++++
5 files changed, 33 insertions(+)
diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
index d1d0aa70fdf1..988804e430e4 100644
--- a/arch/riscv/Kbuild
+++ b/arch/riscv/Kbuild
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-y += kernel/ mm/ net/
+obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 1a3b5a5276be..28899e15f548 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -355,6 +355,24 @@ config CMDLINE_FORCE
endchoice
+config USE_BUILTIN_DTB
+ bool "Use builtin DTB"
+ help
+ Link a device tree blob for particular hardware into the kernel,
+ suppressing use of the DTB pointer provided by the bootloader.
+ This option should only be used with hardware or bootloaders that
+ are not capable of providing a DTB to the kernel, or for
+ experimental hardware without stable device tree bindings.
+
+config BUILTIN_DTB_SOURCE
+ string "Source file for builtin DTB"
+ default ""
+ depends on USE_BUILTIN_DTB
+ help
+ Base name (without suffix, relative to arch/riscv/boot/dts) for
+ the a DTS file that will be used to produce the DTB linked into
+ the kernel.
+
endmenu
menu "Power management options"
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index dcc3ada78455..0bf2669aa12d 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,2 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
+ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
+obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
+else
subdir-y += sifive
+endif
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 0a6d415b0a5a..3e89be9d888c 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
setup_bootmem();
paging_init();
+
+#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
+ unflatten_and_copy_device_tree();
+#else
unflatten_device_tree();
+#endif
+
clint_init_boot_cpu();
#ifdef CONFIG_SWIOTLB
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 965a8cf4829c..1274e889d008 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -480,7 +480,11 @@ static void __init setup_vm_final(void)
#else
asmlinkage void __init setup_vm(uintptr_t dtb_pa)
{
+#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
+ dtb_early_va = __dtb_start;
+#else
dtb_early_va = (void *)dtb_pa;
+#endif
}
static inline void setup_vm_final(void)
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 05/10] riscv: Add SOC early init support
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (3 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
` (7 subsequent siblings)
12 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Add a mechanism for early SoC initialization for platforms that need
additional hardware initialization not possible through the regular
device tree and drivers mechanism. With this, a SoC specific
initialization function can be called very early, before DTB parsing
is done by parse_dtb() in Linux RISC-V kernel setup code.
This can be very useful for early hardware initialization for No-MMU
kernels booted directly in M-mode because it is quite likely that no
other booting stage exist prior to the No-MMU kernel.
Example use of a SoC early initialization is as follows:
static void vendor_abc_early_init(const void *fdt)
{
/*
* some early init code here that can use simple matches
* against the flat device tree file.
*/
}
SOC_EARLY_INIT_DECLARE("vendor,abc", abc_early_init);
This early initialization function is executed only if the flat device
tree for the board has a 'compatible = "vendor,abc"' entry;
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
---
arch/riscv/include/asm/soc.h | 23 +++++++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/head.S | 1 +
arch/riscv/kernel/soc.c | 28 ++++++++++++++++++++++++++++
arch/riscv/kernel/vmlinux.lds.S | 6 ++++++
5 files changed, 59 insertions(+)
create mode 100644 arch/riscv/include/asm/soc.h
create mode 100644 arch/riscv/kernel/soc.c
diff --git a/arch/riscv/include/asm/soc.h b/arch/riscv/include/asm/soc.h
new file mode 100644
index 000000000000..9b8c332cbe76
--- /dev/null
+++ b/arch/riscv/include/asm/soc.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+#ifndef _ASM_RISCV_SOC_H
+#define _ASM_RISCV_SOC_H
+
+#include <linux/of.h>
+#include <linux/linkage.h>
+#include <linux/types.h>
+
+#define SOC_EARLY_INIT_DECLARE(compat, fn) \
+ static const struct of_device_id __soc_early_init \
+ __used __section(__soc_early_init_table) \
+ = { .compatible = compat, .data = fn }
+
+void soc_early_init(void);
+
+extern unsigned long __soc_early_init_table_start;
+extern unsigned long __soc_early_init_table_end;
+
+#endif
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 97d0c35f8b37..e4a22999dbc6 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -10,6 +10,7 @@ endif
extra-y += head.o
extra-y += vmlinux.lds
+obj-y += soc.o
obj-y += cpu.o
obj-y += cpufeature.o
obj-y += entry.o
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index 271860fc2c3f..a7768d6165d4 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -125,6 +125,7 @@ clear_bss_done:
call kasan_early_init
#endif
/* Start the kernel */
+ call soc_early_init
call parse_dtb
tail start_kernel
diff --git a/arch/riscv/kernel/soc.c b/arch/riscv/kernel/soc.c
new file mode 100644
index 000000000000..0b3b3dc9ad0f
--- /dev/null
+++ b/arch/riscv/kernel/soc.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+#include <linux/init.h>
+#include <linux/libfdt.h>
+#include <asm/pgtable.h>
+#include <asm/soc.h>
+
+/*
+ * This is called extremly early, before parse_dtb(), to allow initializing
+ * SoC hardware before memory or any device driver initialization.
+ */
+void __init soc_early_init(void)
+{
+ void (*early_fn)(const void *fdt);
+ const struct of_device_id *s;
+ const void *fdt = dtb_early_va;
+
+ for (s = (void *)&__soc_early_init_table_start;
+ (void *)s < (void *)&__soc_early_init_table_end; s++) {
+ if (!fdt_node_check_compatible(fdt, 0, s->compatible)) {
+ early_fn = s->data;
+ early_fn(fdt);
+ return;
+ }
+ }
+}
diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
index 1e0193ded420..32b160942f40 100644
--- a/arch/riscv/kernel/vmlinux.lds.S
+++ b/arch/riscv/kernel/vmlinux.lds.S
@@ -24,6 +24,12 @@ SECTIONS
HEAD_TEXT_SECTION
INIT_TEXT_SECTION(PAGE_SIZE)
INIT_DATA_SECTION(16)
+ . = ALIGN(8);
+ __soc_early_init_table : {
+ __soc_early_init_table_start = .;
+ KEEP(*(__soc_early_init_table))
+ __soc_early_init_table_end = .;
+ }
/* we have to discard exit text and such at runtime, not link time */
.exit.text :
{
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 06/10] riscv: Add Kendryte K210 SoC support
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (4 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-02-14 20:31 ` Sean Anderson
2020-03-04 19:38 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
` (6 subsequent siblings)
12 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
From: Christoph Hellwig <hch@lst.de>
Add support for the Kendryte K210 RISC-V SoC. For now, this support
only provides a simple sysctl driver allowing to setup the CPU and
uart clock. This support is enabled through the new Kconfig option
SOC_KENDRYTE and defines the config option CONFIG_K210_SYSCTL
to enable the K210 SoC sysctl driver compilation.
The sysctl driver also registers an early SoC initialization function
allowing enabling the general purpose use of the 2MB of SRAM normally
reserved for the SoC AI engine. This initialization function is
automatically called before the dt early initialization using the flat
dt root node compatible property matching the value "kendryte,k210".
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/Kconfig.socs | 6 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/kendryte/Kconfig | 14 ++
drivers/soc/kendryte/Makefile | 3 +
drivers/soc/kendryte/k210-sysctl.c | 245 +++++++++++++++++++++++++++++
6 files changed, 270 insertions(+)
create mode 100644 drivers/soc/kendryte/Kconfig
create mode 100644 drivers/soc/kendryte/Makefile
create mode 100644 drivers/soc/kendryte/k210-sysctl.c
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index d325b67d00df..4d5d4a65b2a2 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -10,4 +10,10 @@ config SOC_SIFIVE
help
This enables support for SiFive SoC platform hardware.
+config SOC_KENDRYTE
+ bool "Kendryte K210 SoC"
+ depends on !MMU
+ help
+ This enables support for Kendryte K210 SoC hardware.
+
endmenu
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 1778f8c62861..425ab6f7e375 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -22,5 +22,6 @@ source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
source "drivers/soc/xilinx/Kconfig"
source "drivers/soc/zte/Kconfig"
+source "drivers/soc/kendryte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 8b49d782a1ab..af58063bb989 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
obj-y += xilinx/
obj-$(CONFIG_ARCH_ZX) += zte/
+obj-$(CONFIG_SOC_KENDRYTE) += kendryte/
diff --git a/drivers/soc/kendryte/Kconfig b/drivers/soc/kendryte/Kconfig
new file mode 100644
index 000000000000..49785b1b0217
--- /dev/null
+++ b/drivers/soc/kendryte/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0
+
+if SOC_KENDRYTE
+
+config K210_SYSCTL
+ bool "Kendryte K210 system controller"
+ default y
+ depends on RISCV
+ help
+ Enables controlling the K210 various clocks and to enable
+ general purpose use of the extra 2MB of SRAM normally
+ reserved for the AI engine.
+
+endif
diff --git a/drivers/soc/kendryte/Makefile b/drivers/soc/kendryte/Makefile
new file mode 100644
index 000000000000..002d9ce95c0d
--- /dev/null
+++ b/drivers/soc/kendryte/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_K210_SYSCTL) += k210-sysctl.o
diff --git a/drivers/soc/kendryte/k210-sysctl.c b/drivers/soc/kendryte/k210-sysctl.c
new file mode 100644
index 000000000000..7d4ecd954af0
--- /dev/null
+++ b/drivers/soc/kendryte/k210-sysctl.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019 Christoph Hellwig.
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ */
+#include <linux/types.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <asm/soc.h>
+
+#define K210_SYSCTL_CLK0_FREQ 26000000UL
+
+/* Registers base address */
+#define K210_SYSCTL_SYSCTL_BASE_ADDR 0x50440000ULL
+
+/* Registers */
+#define K210_SYSCTL_PLL0 0x08
+#define K210_SYSCTL_PLL1 0x0c
+/* clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
+#define PLL_RESET (1 << 20)
+#define PLL_PWR (1 << 21)
+#define PLL_INTFB (1 << 22)
+#define PLL_BYPASS (1 << 23)
+#define PLL_TEST (1 << 24)
+#define PLL_OUT_EN (1 << 25)
+#define PLL_TEST_EN (1 << 26)
+#define K210_SYSCTL_PLL_LOCK 0x18
+#define PLL0_LOCK1 (1 << 0)
+#define PLL0_LOCK2 (1 << 1)
+#define PLL0_SLIP_CLEAR (1 << 2)
+#define PLL0_TEST_CLK_OUT (1 << 3)
+#define PLL1_LOCK1 (1 << 8)
+#define PLL1_LOCK2 (1 << 9)
+#define PLL1_SLIP_CLEAR (1 << 10)
+#define PLL1_TEST_CLK_OUT (1 << 11)
+#define PLL2_LOCK1 (1 << 16)
+#define PLL2_LOCK2 (1 << 16)
+#define PLL2_SLIP_CLEAR (1 << 18)
+#define PLL2_TEST_CLK_OUT (1 << 19)
+#define K210_SYSCTL_CLKSEL0 0x20
+#define CLKSEL_ACLK (1 << 0)
+#define K210_SYSCTL_CLKEN_CENT 0x28
+#define CLKEN_CPU (1 << 0)
+#define CLKEN_SRAM0 (1 << 1)
+#define CLKEN_SRAM1 (1 << 2)
+#define CLKEN_APB0 (1 << 3)
+#define CLKEN_APB1 (1 << 4)
+#define CLKEN_APB2 (1 << 5)
+#define K210_SYSCTL_CLKEN_PERI 0x2c
+#define CLKEN_ROM (1 << 0)
+#define CLKEN_DMA (1 << 1)
+#define CLKEN_AI (1 << 2)
+#define CLKEN_DVP (1 << 3)
+#define CLKEN_FFT (1 << 4)
+#define CLKEN_GPIO (1 << 5)
+#define CLKEN_SPI0 (1 << 6)
+#define CLKEN_SPI1 (1 << 7)
+#define CLKEN_SPI2 (1 << 8)
+#define CLKEN_SPI3 (1 << 9)
+#define CLKEN_I2S0 (1 << 10)
+#define CLKEN_I2S1 (1 << 11)
+#define CLKEN_I2S2 (1 << 12)
+#define CLKEN_I2C0 (1 << 13)
+#define CLKEN_I2C1 (1 << 14)
+#define CLKEN_I2C2 (1 << 15)
+#define CLKEN_UART1 (1 << 16)
+#define CLKEN_UART2 (1 << 17)
+#define CLKEN_UART3 (1 << 18)
+#define CLKEN_AES (1 << 19)
+#define CLKEN_FPIO (1 << 20)
+#define CLKEN_TIMER0 (1 << 21)
+#define CLKEN_TIMER1 (1 << 22)
+#define CLKEN_TIMER2 (1 << 23)
+#define CLKEN_WDT0 (1 << 24)
+#define CLKEN_WDT1 (1 << 25)
+#define CLKEN_SHA (1 << 26)
+#define CLKEN_OTP (1 << 27)
+#define CLKEN_RTC (1 << 29)
+
+struct k210_sysctl {
+ void __iomem *regs;
+ struct clk_hw hw;
+};
+
+static void k210_set_bits(u32 val, void __iomem *reg)
+{
+ writel(readl(reg) | val, reg);
+}
+
+static void k210_clear_bits(u32 val, void __iomem *reg)
+{
+ writel(readl(reg) & ~val, reg);
+}
+
+static void k210_pll1_enable(void __iomem *regs)
+{
+ u32 val;
+
+ val = readl(regs + K210_SYSCTL_PLL1);
+ val &= ~0xfffff;
+ val |= (59 << 4) | (3 << 10) | (59 << 15);
+ writel(val, regs + K210_SYSCTL_PLL1);
+
+ k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
+ k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
+
+ /*
+ * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
+ */
+ k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
+ k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
+ nop();
+ nop();
+ k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
+
+ for (;;) {
+ val = readl(regs + K210_SYSCTL_PLL_LOCK);
+ if (val & PLL1_LOCK2)
+ break;
+ writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
+ }
+
+ k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
+}
+
+static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
+ u32 clksel0, pll0;
+ u64 pll0_freq, clkr0, clkf0, clkod0;
+
+ /*
+ * If the clock selector is not set, use the base frequency.
+ * Otherwise, use PLL0 frequency with a frequency divisor.
+ */
+ clksel0 = readl(s->regs + K210_SYSCTL_CLKSEL0);
+ if (!(clksel0 & CLKSEL_ACLK))
+ return K210_SYSCTL_CLK0_FREQ;
+
+ /*
+ * Get PLL0 frequency:
+ * freq = base frequency * clkf0 / (clkr0 * clkod0)
+ */
+ pll0 = readl(s->regs + K210_SYSCTL_PLL0);
+ clkr0 = 1 + (pll0 & 0x0000000f);
+ clkf0 = 1 + ((pll0 & 0x000003f0) >> 4);
+ clkod0 = 1 + ((pll0 & 0x00003c00) >> 10);
+ pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
+
+ /* Get the frequency divisor from the clock selector */
+ return pll0_freq / (2ULL << ((clksel0 & 0x00000006) >> 1));
+}
+
+static const struct clk_ops k210_sysctl_clk_ops = {
+ .recalc_rate = k210_sysctl_clk_recalc_rate,
+};
+
+static const struct clk_init_data k210_clk_init_data = {
+ .name = "k210-sysctl-pll1",
+ .ops = &k210_sysctl_clk_ops,
+};
+
+static int k210_sysctl_probe(struct platform_device *pdev)
+{
+ struct k210_sysctl *s;
+ int error;
+
+ pr_info("Kendryte K210 SoC sysctl\n");
+
+ s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
+ if (!s)
+ return -ENOMEM;
+
+ s->regs = devm_ioremap_resource(&pdev->dev,
+ platform_get_resource(pdev, IORESOURCE_MEM, 0));
+ if (IS_ERR(s->regs))
+ return PTR_ERR(s->regs);
+
+ s->hw.init = &k210_clk_init_data;
+ error = devm_clk_hw_register(&pdev->dev, &s->hw);
+ if (error) {
+ dev_err(&pdev->dev, "failed to register clk");
+ return error;
+ }
+
+ error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
+ &s->hw);
+ if (error) {
+ dev_err(&pdev->dev, "adding clk provider failed\n");
+ return error;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id k210_sysctl_of_match[] = {
+ { .compatible = "kendryte,k210-sysctl", },
+ {}
+};
+
+static struct platform_driver k210_sysctl_driver = {
+ .driver = {
+ .name = "k210-sysctl",
+ .of_match_table = k210_sysctl_of_match,
+ },
+ .probe = k210_sysctl_probe,
+};
+
+static int __init k210_sysctl_init(void)
+{
+ return platform_driver_register(&k210_sysctl_driver);
+}
+core_initcall(k210_sysctl_init);
+
+/*
+ * This needs to be called very early during initialization, given that
+ * PLL1 needs to be enabled to be able to use all SRAM.
+ */
+static void __init k210_soc_early_init(const void *fdt)
+{
+ void __iomem *regs;
+
+ regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
+ if (!regs)
+ panic("K210 sysctl ioremap");
+
+ /* Enable PLL1 to make the KPU SRAM useable */
+ k210_pll1_enable(regs);
+
+ k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
+
+ k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
+ regs + K210_SYSCTL_CLKEN_CENT);
+ k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
+ regs + K210_SYSCTL_CLKEN_PERI);
+
+ k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_CLKSEL0);
+
+ iounmap(regs);
+}
+SOC_EARLY_INIT_DECLARE("kendryte,k210", k210_soc_early_init);
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 07/10] riscv: Select required drivers for Kendryte SOC
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (5 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-03-02 3:59 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
` (5 subsequent siblings)
12 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
This patch selects drivers required for the Kendryte K210 SOC.
Since K210 based boards do not provide a device tree, this patch
also enables the BUILTIN_DTB option.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/Kconfig.socs | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 4d5d4a65b2a2..8d83210467d9 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -13,6 +13,10 @@ config SOC_SIFIVE
config SOC_KENDRYTE
bool "Kendryte K210 SoC"
depends on !MMU
+ select BUILTIN_DTB
+ select SERIAL_SIFIVE if TTY
+ select SERIAL_SIFIVE_CONSOLE if TTY
+ select SIFIVE_PLIC
help
This enables support for Kendryte K210 SoC hardware.
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (6 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-02-14 20:51 ` Sean Anderson
` (2 more replies)
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
` (4 subsequent siblings)
12 siblings, 3 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Add a generic device tree for Kendryte K210 SoC based boards. This (for
now) very simple device tree works for the Kendryte KD233 development
board, the Sipeed MAIX M1 Dock based boards and the Sipeed MAIXDUINO
board.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/kendryte/Makefile | 2 +
arch/riscv/boot/dts/kendryte/k210.dts | 23 +++++
arch/riscv/boot/dts/kendryte/k210.dtsi | 123 +++++++++++++++++++++++++
4 files changed, 149 insertions(+)
create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index 0bf2669aa12d..87815557f2db 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -3,4 +3,5 @@ ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
else
subdir-y += sifive
+subdir-y += kendryte
endif
diff --git a/arch/riscv/boot/dts/kendryte/Makefile b/arch/riscv/boot/dts/kendryte/Makefile
new file mode 100644
index 000000000000..815444e69e89
--- /dev/null
+++ b/arch/riscv/boot/dts/kendryte/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_KENDRYTE) += k210.dtb
diff --git a/arch/riscv/boot/dts/kendryte/k210.dts b/arch/riscv/boot/dts/kendryte/k210.dts
new file mode 100644
index 000000000000..0d1f28fce6b2
--- /dev/null
+++ b/arch/riscv/boot/dts/kendryte/k210.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+/ {
+ model = "Kendryte K210 generic";
+ compatible = "kendryte,k210";
+
+ chosen {
+ bootargs = "earlycon console=ttySIF0";
+ stdout-path = "serial0";
+ };
+};
+
+&uarths0 {
+ status = "okay";
+};
+
diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi
new file mode 100644
index 000000000000..4b9eeabb07f7
--- /dev/null
+++ b/arch/riscv/boot/dts/kendryte/k210.dtsi
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/ {
+ /*
+ * Although the K210 is a 64-bit CPU, the address bus is only 32-bits
+ * wide, and the upper half of all addresses is ignored.
+ */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "kendryte,k210";
+
+ aliases {
+ serial0 = &uarths0;
+ };
+
+ clocks {
+ in0: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <7800000>;
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ reg = <0>;
+ compatible = "riscv";
+ riscv,isa = "rv64imafdc";
+ mmu-type = "none";
+ i-cache-size = <0x8000>;
+ i-cache-block-size = <64>; /* bogus */
+ d-cache-size = <0x8000>;
+ d-cache-block-size = <64>; /* bogus */
+ clocks = <&sysctl 0>;
+ clock-frequency = <390000000>;
+ cpu0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ };
+ };
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ reg = <1>;
+ compatible = "riscv";
+ riscv,isa = "rv64imafdc";
+ mmu-type = "none";
+ i-cache-size = <0x8000>;
+ i-cache-block-size = <64>; /* bogus */
+ d-cache-size = <0x8000>;
+ d-cache-block-size = <64>; /* bogus */
+ clocks = <&sysctl 0>;
+ clock-frequency = <390000000>;
+ cpu1_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ };
+ };
+ };
+
+ sram0: memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x400000>;
+ };
+
+ sram1: memory@80400000 {
+ device_type = "memory";
+ reg = <0x80400000 0x200000>;
+ };
+
+ kpu_sram: memory@80600000 {
+ device_type = "memory";
+ reg = <0x80600000 0x200000>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "kendryte,k210-soc", "simple-bus";
+ ranges;
+ interrupt-parent = <&plic0>;
+
+ sysctl: sysctl@50440000 {
+ compatible = "kendryte,k210-sysctl", "syscon";
+ reg = <0x50440000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ clint0: interrupt-controller@2000000 {
+ compatible = "riscv,clint0";
+ reg = <0x2000000 0xC000>;
+ interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
+ clocks = <&sysctl 0>;
+ };
+
+ plic0: interrupt-controller@c000000 {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "kendryte,k210-plic0", "riscv,plic0";
+ reg = <0xC000000 0x3FFF008>;
+ interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
+ <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
+ riscv,ndev = <65>;
+ riscv,max-priority = <0x07>;
+ };
+
+ uarths0: serial@38000000 {
+ compatible = "kendryte,k210-uart0", "sifive,uart0";
+ reg = <0x38000000 0x20>;
+ interrupts = <33>;
+ clocks = <&sysctl 0>;
+ };
+ };
+};
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 09/10] riscv: Kendryte K210 default config
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (7 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-03-02 4:07 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
` (3 subsequent siblings)
12 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
The patch adds defconfig to build No-MMU kernel meant for
Kendryte K210 SoC.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/configs/nommu_k210_defconfig | 68 +++++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 arch/riscv/configs/nommu_k210_defconfig
diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
new file mode 100644
index 000000000000..00ded8f0bc55
--- /dev/null
+++ b/arch/riscv/configs/nommu_k210_defconfig
@@ -0,0 +1,68 @@
+# CONFIG_CPU_ISOLATION is not set
+CONFIG_LOG_BUF_SHIFT=15
+CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="k210.cpio"
+CONFIG_INITRAMFS_FORCE=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+# CONFIG_BOOT_CONFIG is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_SYSFS_SYSCALL is not set
+# CONFIG_FHANDLE is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+# CONFIG_IO_URING is not set
+# CONFIG_ADVISE_SYSCALLS is not set
+# CONFIG_MEMBARRIER is not set
+# CONFIG_KALLSYMS is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLOB=y
+# CONFIG_SLAB_MERGE_DEFAULT is not set
+# CONFIG_MMU is not set
+CONFIG_SOC_KENDRYTE=y
+CONFIG_MAXPHYSMEM_2GB=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+CONFIG_CMDLINE="earlycon console=ttySIF0"
+CONFIG_CMDLINE_FORCE=y
+CONFIG_USE_BUILTIN_DTB=y
+CONFIG_BUILTIN_DTB_SOURCE="kendryte/k210"
+# CONFIG_BLOCK is not set
+CONFIG_BINFMT_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_ALLOW_DEV_COREDUMP is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_LDISC_AUTOLOAD is not set
+# CONFIG_DEVMEM is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_VGA_CONSOLE is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_VIRTIO_MENU is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_LSM="[]"
+CONFIG_PRINTK_TIME=y
+# CONFIG_DEBUG_MISC is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_RCU_TRACE is not set
+# CONFIG_FTRACE is not set
+# CONFIG_RUNTIME_TESTING_MENU is not set
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (8 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
@ 2020-02-12 10:34 ` Damien Le Moal
2020-03-02 4:08 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
` (2 subsequent siblings)
12 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-12 10:34 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
From: Christoph Hellwig <hch@lst.de>
This can be loaded into the Kendryte KD210 based boards using:
kflash.py/kflash.py -t arch/riscv/boot/loader.bin
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
arch/riscv/Makefile | 4 ++--
arch/riscv/boot/Makefile | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index b9009a2fbaf5..440969763e14 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -84,11 +84,11 @@ vdso_install:
$(Q)$(MAKE) $(build)=arch/riscv/kernel/vdso $@
ifeq ($(CONFIG_RISCV_M_MODE),y)
-KBUILD_IMAGE := $(boot)/loader
+KBUILD_IMAGE := $(boot)/loader.bin
else
KBUILD_IMAGE := $(boot)/Image.gz
endif
-BOOT_TARGETS := Image Image.gz loader
+BOOT_TARGETS := Image Image.gz loader loader.bin
all: $(notdir $(KBUILD_IMAGE))
diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
index 36db8145f9f4..3530c59b3ea7 100644
--- a/arch/riscv/boot/Makefile
+++ b/arch/riscv/boot/Makefile
@@ -41,6 +41,9 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
$(obj)/Image.lzo: $(obj)/Image FORCE
$(call if_changed,lzo)
+$(obj)/loader.bin: $(obj)/loader FORCE
+ $(call if_changed,objcopy)
+
install:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image System.map "$(INSTALL_PATH)"
--
2.24.1
^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (9 preceding siblings ...)
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
@ 2020-02-14 15:05 ` Carlos Eduardo de Paula
2020-02-15 2:02 ` Damien Le Moal
2020-02-28 20:32 ` Sean Anderson
2020-03-04 19:44 ` Palmer Dabbelt
12 siblings, 1 reply; 89+ messages in thread
From: Carlos Eduardo de Paula @ 2020-02-14 15:05 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 7:34 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> This series adds support to boot nommu Linux on Kendryte K210 SoC based
> boards. This is all based on initial work done by Christoph Hellwig.
>
> The first 2 patches fix riscv gitignore and a potential nommu
> compilation error. These patches are not specific to the Kendryte
> support.
>
> Patch 3 adds unaligned load/store trap handlers for M-mode.
>
> Patch 4 enables a builtin DTB to allow passing a device tree to the
> kernel when the board bootchain is enabled to pass one.
>
> Patch 5 introduces an early SoC initialization enabling very early
> hardware initialization not possible with device tree entries pointing
> to drivers. This is used in patch 6 which introduces a sysctl driver for
> the K210 SoC. The early SoC initialization is used to enable the
> additional 2MB of SRAM normally reserved to the SoC AI chip.
>
> Patch 7 to 9 add necessary Kconfig changes, a defconfig and a generic
> device tree suitable for many K210 boards.
>
> Finally, patch 10 adds compilation of a bootable image file (bin file)
> that can be used to flash the board ROM.
>
> This series was tested on the Kendryte KD233 development board, the
> Sipeed MAIX dan dock board and the Sipeed MAIXDUINO board. The userspace
> used was built using a modified buildroot tree for the toolchain part
> and an unmodified busybox tree for the initramfs image (embedded in the
> kernel as a cpio file). The folowwing github project contains the
> modified buildroot tree:
>
> https://github.com/damien-lemoal/riscv64-nommu-buildroot
>
> This is based on work from Christoph Hellwig, with additional changes
> and updates to the latest upstream versions for buildroot and uClibc.
>
> Precompiled versions of the toolchain (gcc 9.2) and initramfs file tree
> and cpio file can be found in this project under the directory:
>
> buildroot/riscv64-uclibc-nommu/
>
> Flashing the file arch/riscv/boot/loader.bin to a board can be done
> using the Sipeed kflash.py tool with the command:
>
> kflash.py/kflash.py -p /dev/ttyUSB0 -b 1500000 -t loader.bin
>
> The kflash.py tool can be found here:
>
> https://github.com/sipeed/kflash.py
>
> For reference, using the Sipeed MAIXDUINO board, here is the boot
> output:
>
> [INFO] Rebooting...
> --- forcing DTR inactive
> --- forcing RTS inactive
> --- Miniterm on /dev/ttyUSB0 115200,8,N,1 ---
> --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
> [ 0.000000] Linux version 5.6.0-rc1-00011-ga2b5be1c4374 (damien@yyy) (gcc version 8.2.0 (Buildroot 2018.11-rc2-00003-ga0787e9)) #610 SMP Wed Feb 12 18:53:50 JST 2020
> [ 0.000000] earlycon: sifive0 at MMIO 0x0000000038000000 (options '')
> [ 0.000000] printk: bootconsole [sifive0] enabled
> [ 0.000000] initrd not found or empty - disabling initrd
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] elf_hwcap is 0x112d
> [ 0.000000] percpu: max_distance=0x18000 too large for vmalloc space 0x0
> [ 0.000000] percpu: Embedded 12 pages/cpu s18272 r0 d30880 u49152
> [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020
> [ 0.000000] Kernel command line: earlycon console=ttySIF0
> [ 0.000000] Dentry cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.000000] Sorting __ex_table...
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] Memory: 6328K/8192K available (924K kernel code, 110K rwdata, 164K rodata, 321K init, 91K bss, 1864K reserved, 0K cma-reserved)
> [ 0.000000] rcu: Hierarchical RCU implementation.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
> [ 0.000000] plic: mapped 65 interrupts with 2 handlers for 4 contexts.
> [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
> [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x3990be68b, max_idle_ns: 881590404272 ns
> [ 0.000014] sched_clock: 64 bits at 7MHz, resolution 128ns, wraps every 4398046511054ns
> [ 0.008232] Console: colour dummy device 80x25
> [ 0.012474] Calibrating delay loop (skipped), value calculated using timer frequency.. 15.60 BogoMIPS (lpj=31200)
> [ 0.022678] pid_max: default: 4096 minimum: 301
> [ 0.027288] Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.034414] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.044796] rcu: Hierarchical SRCU implementation.
> [ 0.049602] smp: Bringing up secondary CPUs ...
> [ 0.054746] smp: Brought up 1 node, 2 CPUs
> [ 0.059093] devtmpfs: initialized
> [ 0.065523] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 0.074544] futex hash table entries: 16 (order: -2, 1024 bytes, linear)
> [ 0.082512] Kendryte K210 SoC sysctl
> [ 0.096010] clocksource: Switched to clocksource riscv_clocksource
> [ 0.178581] workingset: timestamp_bits=62 max_order=11 bucket_order=0
> [ 0.185846] 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 0) is a SiFive UART v0
> [ 0.194344] printk: console [ttySIF0] enabled
> [ 0.194344] printk: console [ttySIF0] enabled
> [ 0.202929] printk: bootconsole [sifive0] disabled
> [ 0.202929] printk: bootconsole [sifive0] disabled
> [ 0.214853] random: get_random_bytes called from 0x0000000080055178 with crng_init=0
> [ 0.223606] devtmpfs: mounted
> [ 0.226861] Freeing unused kernel memory: 320K
> [ 0.230574] This architecture does not have kernel memory protection.
> [ 0.236987] Run /sbin/init as init process
> [ 0.241181] Run /etc/init as init process
> [ 0.245178] Run /bin/init as init process
>
> -----------------------------
> | Kendryte K210 NOMMU Linux |
> -----------------------------
> Mounting /proc
> Starting shell
>
>
> BusyBox v1.32.0.git (2020-02-12 17:51:45 JST) hush - the humble shell
> Enter 'help' for a list of built-in commands.
>
> / # cat /proc/cpuinfo
> processor : 0
> hart : 0
> isa : rv64imafdc
>
> processor : 1
> hart : 1
> isa : rv64imafdc
>
> / #
> / # ls -l /
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 bin
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 dev
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 etc
> dr-xr-xr-x 58 0 0 0 Jan 1 00:00 proc
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 root
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 sbin
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 sys
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 tmp
> drwxrwxr-x 4 1000 1000 0 Feb 12 2020 usr
> / #
> / # cat /proc/vmstat
> nr_free_pages 1148
> ...
> / #
>
> The K210 SoC has more devices (GPIO, SD-card, LCD, etc) that likely can
> be enabled and used. For this, the sysctl driver will need further
> improvements as each device uses a different clock. To share the fun,
> supporting these is left as an exercise for the hobbyist and hackers
> interested in this SoC/boards :)
>
> Christoph Hellwig (2):
> riscv: Add Kendryte K210 SoC support
> riscv: create a loader.bin for the kendryte kflash.py tool
>
> Damien Le Moal (8):
> riscv: Fix gitignore
> riscv: Force flat memory model with no-mmu
> riscv: Unaligned load/store handling for M_MODE
> riscv: Add BUILTIN_DTB support
> riscv: Add SOC early init support
> riscv: Select required drivers for Kendryte SOC
> riscv: Add Kendryte K210 device tree
> riscv: Kendryte K210 default config
>
> arch/riscv/Kbuild | 1 +
> arch/riscv/Kconfig | 19 ++
> arch/riscv/Kconfig.socs | 10 +
> arch/riscv/Makefile | 4 +-
> arch/riscv/boot/.gitignore | 2 +
> arch/riscv/boot/Makefile | 3 +
> arch/riscv/boot/dts/Makefile | 5 +
> arch/riscv/boot/dts/kendryte/Makefile | 2 +
> arch/riscv/boot/dts/kendryte/k210.dts | 23 ++
> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 ++++++++
> arch/riscv/configs/nommu_k210_defconfig | 68 +++++
> arch/riscv/include/asm/soc.h | 23 ++
> arch/riscv/kernel/Makefile | 3 +-
> arch/riscv/kernel/head.S | 1 +
> arch/riscv/kernel/setup.c | 6 +
> arch/riscv/kernel/soc.c | 28 ++
> arch/riscv/kernel/traps.c | 27 +-
> arch/riscv/kernel/traps_misaligned.c | 371 ++++++++++++++++++++++++
> arch/riscv/kernel/vmlinux.lds.S | 6 +
> arch/riscv/mm/init.c | 4 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/kendryte/Kconfig | 14 +
> drivers/soc/kendryte/Makefile | 3 +
> drivers/soc/kendryte/k210-sysctl.c | 245 ++++++++++++++++
> 25 files changed, 987 insertions(+), 6 deletions(-)
> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
> create mode 100644 arch/riscv/configs/nommu_k210_defconfig
> create mode 100644 arch/riscv/include/asm/soc.h
> create mode 100644 arch/riscv/kernel/soc.c
> create mode 100644 arch/riscv/kernel/traps_misaligned.c
> create mode 100644 drivers/soc/kendryte/Kconfig
> create mode 100644 drivers/soc/kendryte/Makefile
> create mode 100644 drivers/soc/kendryte/k210-sysctl.c
>
> --
> 2.24.1
>
>
Hi Damien, I've tested the patches on v5.5.0 and it boots perfectly on
my MaixGo board. I used the provided initramfs.cpio as the payload and
got to the busybox prompt.
While trying to build my own busybox, I got a few problems. I've
checked-out your tree and copied the toolchain. Then when building
busybox with your minimal config, I got this error:
LINK busybox_unstripped
Your linker does not support --sort-section,alignment
Your linker does not support --sort-common
Your linker does not support -Wl,--gc-sections
Trying libraries: m rt
Failed: -Wl,--start-group -lm -lrt -Wl,--end-group
Output of:
/opt/riscv64-uclibc/bin/riscv64-linux-gcc -Wall -Wshadow
-Wwrite-strings -Wundef -Wstrict-prototypes -Wunused
-Wunused-parameter -Wunused-function -Wunused-value
-Wmissing-prototypes -Wmissing-declarations -Wno-format-security
-Wdeclaration-after-statement -Wold-style-definition -finline-limit=0
-fno-builtin-strlen -fomit-frame-pointer -ffunction-sections
-fdata-sections -fno-guess-branch-probability -funsigned-char
-static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1
-falign-loops=1 -fno-unwind-tables -fno-asynchronous-unwind-tables
-fno-builtin-printf -Wno-string-plus-int -Wno-constant-logical-operand
-Os -Os -fPIC --sysroot=/opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/sysroot/
-static -Os -static -Wl,-elf2flt=-r -o busybox_unstripped
-Wl,--start-group applets/built-in.o archival/lib.a
archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a
coreutils/libcoreutils/lib.a debianutils/lib.a klibc-utils/lib.a
e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a
libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a
modutils/lib.a networking/lib.a networking/libiproute/lib.a
networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a
selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a
util-linux/volume_id/lib.a archival/built-in.o
archival/libarchive/built-in.o console-tools/built-in.o
coreutils/built-in.o coreutils/libcoreutils/built-in.o
debianutils/built-in.o klibc-utils/built-in.o e2fsprogs/built-in.o
editors/built-in.o findutils/built-in.o init/built-in.o
libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o
mailutils/built-in.o miscutils/built-in.o modutils/built-in.o
networking/built-in.o networking/libiproute/built-in.o
networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o
runit/built-in.o selinux/built-in.o shell/built-in.o
sysklogd/built-in.o util-linux/built-in.o
util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lm
-lrt -Wl,--end-group
==========
/opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
find crt1.o: No such file or directory
/opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
find crti.o: No such file or directory
/opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
find crtbeginT.o: No such file or directory
collect2: error: ld returned 1 exit status
Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam"
make: *** [Makefile:718: busybox_unstripped] Error 1
Then I've built the complete buildroot toolchain and replaced it on /opt.
Then I've proceeded to "make SKIP_STRIP=y" and "make install" and it
built fine. I got into _install dir and ran: "find . | sudo cpio -H
newc --create --verbose > ../k210.cpio" to generate the cpio. All this
with the
Rebuilt the kernel with it but when booting, I got this error:
[ 0.259289] Run /sbin/init as init process
[ 0.263480] Run /etc/init as init process
[ 0.267453] Run /bin/init as init process
[ 0.286973] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000000
[ 0.293869] CPU: 1 PID: 1 Comm: sh Not tainted 5.5.0-dirty #19
[ 0.299673] Call Trace:
[ 0.302109] [<00000000800401f6>] 0x00000000800401f6
[ 0.306969] [<000000008004033a>] 0x000000008004033a
[ 0.311831] [<0000000080111abe>] 0x0000000080111abe
[ 0.316693] [<000000008004340e>] 0x000000008004340e
[ 0.321556] [<0000000080045402>] 0x0000000080045402
[ 0.326417] [<0000000080045898>] 0x0000000080045898
[ 0.331279] [<000000008003f1d2>] 0x000000008003f1d2
[ 0.336142] SMP: stopping secondary CPUs
[ 0.340065] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00000000 ]---
I also tried with a gzipped cpio but got the "Kernel panic - not
syncing: no cpio magic" error.
What's the right way to create the cpio initramfs? I want to customize
it a little.
Thanks.
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
@ 2020-02-14 20:18 ` Sean Anderson
2020-02-15 2:15 ` Damien Le Moal
2020-03-02 3:48 ` Anup Patel
2020-03-04 18:38 ` Palmer Dabbelt
2 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-14 20:18 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Hi,
On 2/12/20 5:34 AM, Damien Le Moal wrote:
> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
> a nommu kernel. Since the sparsemem model does not make sense anyway
> for the nommu case, do not allow selecting this option to always use
> the flatmem model.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 73f029eae0cc..1a3b5a5276be 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>
> config ARCH_SPARSEMEM_ENABLE
> def_bool y
> + depends on MMU
> select SPARSEMEM_VMEMMAP_ENABLE
>
> config ARCH_SELECT_MEMORY_MODEL
>
Just for some background, why did you choose NOMMU? Afaik the K210 has
an MMU following the RISC-V privileged specification 1.9
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 06/10] riscv: Add Kendryte K210 SoC support
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
@ 2020-02-14 20:31 ` Sean Anderson
2020-03-04 19:38 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Sean Anderson @ 2020-02-14 20:31 UTC (permalink / raw)
To: linux-riscv
Hi Damien/Chistopher,
I'm working on adding k210 support to U-Boot [1], so I'm interested in
how you've tackled these problems. Hopefully, we can keep the
implementations broadly similar, to make it easier to correct bugs in
the future. In part
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=157821
On 2/12/20 5:34 AM, Damien Le Moal wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> Add support for the Kendryte K210 RISC-V SoC. For now, this support
> only provides a simple sysctl driver allowing to setup the CPU and
> uart clock. This support is enabled through the new Kconfig option
> SOC_KENDRYTE and defines the config option CONFIG_K210_SYSCTL
> to enable the K210 SoC sysctl driver compilation.
>
> The sysctl driver also registers an early SoC initialization function
> allowing enabling the general purpose use of the 2MB of SRAM normally
> reserved for the SoC AI engine. This initialization function is
> automatically called before the dt early initialization using the flat
> dt root node compatible property matching the value "kendryte,k210".
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig.socs | 6 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/kendryte/Kconfig | 14 ++
> drivers/soc/kendryte/Makefile | 3 +
> drivers/soc/kendryte/k210-sysctl.c | 245 +++++++++++++++++++++++++++++
> 6 files changed, 270 insertions(+)
> create mode 100644 drivers/soc/kendryte/Kconfig
> create mode 100644 drivers/soc/kendryte/Makefile
> create mode 100644 drivers/soc/kendryte/k210-sysctl.c
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index d325b67d00df..4d5d4a65b2a2 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -10,4 +10,10 @@ config SOC_SIFIVE
> help
> This enables support for SiFive SoC platform hardware.
>
> +config SOC_KENDRYTE
> + bool "Kendryte K210 SoC"
> + depends on !MMU
> + help
> + This enables support for Kendryte K210 SoC hardware.
> +
> endmenu
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 1778f8c62861..425ab6f7e375 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -22,5 +22,6 @@ source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> source "drivers/soc/xilinx/Kconfig"
> source "drivers/soc/zte/Kconfig"
> +source "drivers/soc/kendryte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 8b49d782a1ab..af58063bb989 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> obj-y += xilinx/
> obj-$(CONFIG_ARCH_ZX) += zte/
> +obj-$(CONFIG_SOC_KENDRYTE) += kendryte/
> diff --git a/drivers/soc/kendryte/Kconfig b/drivers/soc/kendryte/Kconfig
> new file mode 100644
> index 000000000000..49785b1b0217
> --- /dev/null
> +++ b/drivers/soc/kendryte/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_KENDRYTE
> +
> +config K210_SYSCTL
> + bool "Kendryte K210 system controller"
> + default y
> + depends on RISCV
> + help
> + Enables controlling the K210 various clocks and to enable
> + general purpose use of the extra 2MB of SRAM normally
> + reserved for the AI engine.
> +
> +endif
> diff --git a/drivers/soc/kendryte/Makefile b/drivers/soc/kendryte/Makefile
> new file mode 100644
> index 000000000000..002d9ce95c0d
> --- /dev/null
> +++ b/drivers/soc/kendryte/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_K210_SYSCTL) += k210-sysctl.o
> diff --git a/drivers/soc/kendryte/k210-sysctl.c b/drivers/soc/kendryte/k210-sysctl.c
> new file mode 100644
> index 000000000000..7d4ecd954af0
> --- /dev/null
> +++ b/drivers/soc/kendryte/k210-sysctl.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2019 Christoph Hellwig.
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/types.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <asm/soc.h>
> +
> +#define K210_SYSCTL_CLK0_FREQ 26000000UL
> +
> +/* Registers base address */
> +#define K210_SYSCTL_SYSCTL_BASE_ADDR 0x50440000ULL
> +
> +/* Registers */
> +#define K210_SYSCTL_PLL0 0x08
> +#define K210_SYSCTL_PLL1 0x0c
> +/* clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
> +#define PLL_RESET (1 << 20)
> +#define PLL_PWR (1 << 21)
> +#define PLL_INTFB (1 << 22)
> +#define PLL_BYPASS (1 << 23)
> +#define PLL_TEST (1 << 24)
> +#define PLL_OUT_EN (1 << 25)
> +#define PLL_TEST_EN (1 << 26)
> +#define K210_SYSCTL_PLL_LOCK 0x18
> +#define PLL0_LOCK1 (1 << 0)
> +#define PLL0_LOCK2 (1 << 1)
> +#define PLL0_SLIP_CLEAR (1 << 2)
> +#define PLL0_TEST_CLK_OUT (1 << 3)
> +#define PLL1_LOCK1 (1 << 8)
> +#define PLL1_LOCK2 (1 << 9)
> +#define PLL1_SLIP_CLEAR (1 << 10)
> +#define PLL1_TEST_CLK_OUT (1 << 11)
> +#define PLL2_LOCK1 (1 << 16)
> +#define PLL2_LOCK2 (1 << 16)
> +#define PLL2_SLIP_CLEAR (1 << 18)
> +#define PLL2_TEST_CLK_OUT (1 << 19)
> +#define K210_SYSCTL_CLKSEL0 0x20
> +#define CLKSEL_ACLK (1 << 0)
> +#define K210_SYSCTL_CLKEN_CENT 0x28
> +#define CLKEN_CPU (1 << 0)
> +#define CLKEN_SRAM0 (1 << 1)
> +#define CLKEN_SRAM1 (1 << 2)
> +#define CLKEN_APB0 (1 << 3)
> +#define CLKEN_APB1 (1 << 4)
> +#define CLKEN_APB2 (1 << 5)
> +#define K210_SYSCTL_CLKEN_PERI 0x2c
> +#define CLKEN_ROM (1 << 0)
> +#define CLKEN_DMA (1 << 1)
> +#define CLKEN_AI (1 << 2)
> +#define CLKEN_DVP (1 << 3)
> +#define CLKEN_FFT (1 << 4)
> +#define CLKEN_GPIO (1 << 5)
> +#define CLKEN_SPI0 (1 << 6)
> +#define CLKEN_SPI1 (1 << 7)
> +#define CLKEN_SPI2 (1 << 8)
> +#define CLKEN_SPI3 (1 << 9)
> +#define CLKEN_I2S0 (1 << 10)
> +#define CLKEN_I2S1 (1 << 11)
> +#define CLKEN_I2S2 (1 << 12)
> +#define CLKEN_I2C0 (1 << 13)
> +#define CLKEN_I2C1 (1 << 14)
> +#define CLKEN_I2C2 (1 << 15)
> +#define CLKEN_UART1 (1 << 16)
> +#define CLKEN_UART2 (1 << 17)
> +#define CLKEN_UART3 (1 << 18)
> +#define CLKEN_AES (1 << 19)
> +#define CLKEN_FPIO (1 << 20)
> +#define CLKEN_TIMER0 (1 << 21)
> +#define CLKEN_TIMER1 (1 << 22)
> +#define CLKEN_TIMER2 (1 << 23)
> +#define CLKEN_WDT0 (1 << 24)
> +#define CLKEN_WDT1 (1 << 25)
> +#define CLKEN_SHA (1 << 26)
> +#define CLKEN_OTP (1 << 27)
> +#define CLKEN_RTC (1 << 29)
> +
> +struct k210_sysctl {
> + void __iomem *regs;
> + struct clk_hw hw;
> +};
> +
> +static void k210_set_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) | val, reg);
> +}
> +
> +static void k210_clear_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) & ~val, reg);
> +}
> +
> +static void k210_pll1_enable(void __iomem *regs)
> +{
> + u32 val;
> +
> + val = readl(regs + K210_SYSCTL_PLL1);
> + val &= ~0xfffff;
> + val |= (59 << 4) | (3 << 10) | (59 << 15);
Can this be done with symbolic constants? Additionally, I believe bwadj
needs to be set to the value you use for f (at least when using internal
feedback). There is a datasheet floating around under the name
"TCITSMCN40GGPMPLLA1_guide" which has more information about the PLL's
internals.
> + writel(val, regs + K210_SYSCTL_PLL1);
> +
> + k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
> +
> + /*
> + * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
> + */
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + nop();
> + nop();
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> +
> + for (;;) {
> + val = readl(regs + K210_SYSCTL_PLL_LOCK);
> + if (val & PLL1_LOCK2)
> + break;
> + writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
> + }
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
> +}
> +
> +static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
> + u32 clksel0, pll0;
> + u64 pll0_freq, clkr0, clkf0, clkod0;
> +
> + /*
> + * If the clock selector is not set, use the base frequency.
> + * Otherwise, use PLL0 frequency with a frequency divisor.
> + */
> + clksel0 = readl(s->regs + K210_SYSCTL_CLKSEL0);
> + if (!(clksel0 & CLKSEL_ACLK))
> + return K210_SYSCTL_CLK0_FREQ;
> +
> + /*
> + * Get PLL0 frequency:
> + * freq = base frequency * clkf0 / (clkr0 * clkod0)
> + */
> + pll0 = readl(s->regs + K210_SYSCTL_PLL0);
> + clkr0 = 1 + (pll0 & 0x0000000f);
> + clkf0 = 1 + ((pll0 & 0x000003f0) >> 4);
> + clkod0 = 1 + ((pll0 & 0x00003c00) >> 10);
Can you do this with FIELD_GET and GENMASK instead?
> + pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
> +
> + /* Get the frequency divisor from the clock selector */
> + return pll0_freq / (2ULL << ((clksel0 & 0x00000006) >> 1));
Same thing here.
> +}
> +
> +static const struct clk_ops k210_sysctl_clk_ops = {
> + .recalc_rate = k210_sysctl_clk_recalc_rate,
> +};
> +
> +static const struct clk_init_data k210_clk_init_data = {
> + .name = "k210-sysctl-pll1",
> + .ops = &k210_sysctl_clk_ops,
> +};
> +
> +static int k210_sysctl_probe(struct platform_device *pdev)
> +{
> + struct k210_sysctl *s;
> + int error;
> +
> + pr_info("Kendryte K210 SoC sysctl\n");
> +
> + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> + if (!s)
> + return -ENOMEM;
> +
> + s->regs = devm_ioremap_resource(&pdev->dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> + if (IS_ERR(s->regs))
> + return PTR_ERR(s->regs);
> +
> + s->hw.init = &k210_clk_init_data;
> + error = devm_clk_hw_register(&pdev->dev, &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "failed to register clk");
> + return error;
> + }
> +
> + error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
> + &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "adding clk provider failed\n");
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id k210_sysctl_of_match[] = {
> + { .compatible = "kendryte,k210-sysctl", },
> + {}
> +};
> +
> +static struct platform_driver k210_sysctl_driver = {
> + .driver = {
> + .name = "k210-sysctl",
> + .of_match_table = k210_sysctl_of_match,
> + },
> + .probe = k210_sysctl_probe,
> +};
> +
> +static int __init k210_sysctl_init(void)
> +{
> + return platform_driver_register(&k210_sysctl_driver);
> +}
> +core_initcall(k210_sysctl_init);
> +
> +/*
> + * This needs to be called very early during initialization, given that
> + * PLL1 needs to be enabled to be able to use all SRAM.
> + */
> +static void __init k210_soc_early_init(const void *fdt)
> +{
> + void __iomem *regs;
> +
> + regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
> + if (!regs)
> + panic("K210 sysctl ioremap");
> +
> + /* Enable PLL1 to make the KPU SRAM useable */
> + k210_pll1_enable(regs);
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
> +
> + k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
> + regs + K210_SYSCTL_CLKEN_CENT);
> + k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
> + regs + K210_SYSCTL_CLKEN_PERI);
> +
> + k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_CLKSEL0);
> +
> + iounmap(regs);
> +}
> +SOC_EARLY_INIT_DECLARE("kendryte,k210", k210_soc_early_init);
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
@ 2020-02-14 20:51 ` Sean Anderson
2020-02-15 2:34 ` Damien Le Moal
2020-03-02 4:06 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-14 20:51 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2/12/20 5:34 AM, Damien Le Moal wrote:
> Add a generic device tree for Kendryte K210 SoC based boards. This (for
> now) very simple device tree works for the Kendryte KD233 development
> board, the Sipeed MAIX M1 Dock based boards and the Sipeed MAIXDUINO
> board.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/kendryte/Makefile | 2 +
> arch/riscv/boot/dts/kendryte/k210.dts | 23 +++++
> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 +++++++++++++++++++++++++
> 4 files changed, 149 insertions(+)
> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index 0bf2669aa12d..87815557f2db 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -3,4 +3,5 @@ ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> else
> subdir-y += sifive
> +subdir-y += kendryte
> endif
> diff --git a/arch/riscv/boot/dts/kendryte/Makefile b/arch/riscv/boot/dts/kendryte/Makefile
> new file mode 100644
> index 000000000000..815444e69e89
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_SOC_KENDRYTE) += k210.dtb
> diff --git a/arch/riscv/boot/dts/kendryte/k210.dts b/arch/riscv/boot/dts/kendryte/k210.dts
> new file mode 100644
> index 000000000000..0d1f28fce6b2
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/k210.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +/dts-v1/;
> +
> +#include "k210.dtsi"
> +
> +/ {
> + model = "Kendryte K210 generic";
> + compatible = "kendryte,k210";
> +
> + chosen {
> + bootargs = "earlycon console=ttySIF0";
> + stdout-path = "serial0";
> + };
> +};
> +
> +&uarths0 {
> + status = "okay";
> +};
> +
> diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi
> new file mode 100644
> index 000000000000..4b9eeabb07f7
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
Glad to see this is getting some use :)
This appears to be an old-ish version, and I've made some updates in the
past month or so. My current work is availible from [1].
[1] https://github.com/Forty-Bot/u-boot/blob/maix_v6/arch/riscv/dts/k210.dtsi
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +/ {
> + /*
> + * Although the K210 is a 64-bit CPU, the address bus is only 32-bits
> + * wide, and the upper half of all addresses is ignored.
> + */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "kendryte,k210";
> +
> + aliases {
> + serial0 = &uarths0;
> + };
> +
> + clocks {
> + in0: oscillator {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <26000000>;
> + };
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <7800000>;
This is true only for the default frequency. I wonder if there is a
better way to encode this.
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "none";
This should be "sv36".
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <64>; /* bogus */
I emailed some people at Kendryte and they confirmed the 64-byte
cacheline. The cpus are rocket cores.
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <64>; /* bogus */
> + clocks = <&sysctl 0>;
This is correct only by coincidence. The clock structure is
in0 -> pll0 -> aclk -> cpu
aclk divides by two by default, so it runs at 390 MHz, which is also
what you set pll1 to. However, if someone else (such as the bootloader)
changes the pll0 frequency then this will be completely off.
> + clock-frequency = <390000000>;
> + cpu0_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + reg = <1>;
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "none";
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <64>; /* bogus */
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <64>; /* bogus */
> + clocks = <&sysctl 0>;
> + clock-frequency = <390000000>;
> + cpu1_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + };
> +
> + sram0: memory@80000000 {
> + device_type = "memory";
> + reg = <0x80000000 0x400000>;
> + };
> +
> + sram1: memory@80400000 {
> + device_type = "memory";
> + reg = <0x80400000 0x200000>;
> + };
> +
> + kpu_sram: memory@80600000 {
> + device_type = "memory";
> + reg = <0x80600000 0x200000>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "kendryte,k210-soc", "simple-bus";
Should the -soc suffix be here? I saw it was absent from the fu540
device tree.
> + ranges;
> + interrupt-parent = <&plic0>;
> +
> + sysctl: sysctl@50440000 {
> + compatible = "kendryte,k210-sysctl", "syscon";
> + reg = <0x50440000 0x1000>;
> + #clock-cells = <1>;
> + };
Would it be possible to model this as an MFD? There are a lot of
different registers in here, many of which are unrelated to clocks. For
example, there are also reset registers, a reboot register, and DMA
handshake controls. I think modeling this as a clock controller only
does not correctly reflect the hardware, and will be awkward in the
future.
> +
> + clint0: interrupt-controller@2000000 {
> + compatible = "riscv,clint0";
> + reg = <0x2000000 0xC000>;
> + interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
> + clocks = <&sysctl 0>;
Again, this is wrong; it should be running off ACLK.
> + };
> +
> + plic0: interrupt-controller@c000000 {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "kendryte,k210-plic0", "riscv,plic0";
> + reg = <0xC000000 0x3FFF008>;
With regard to the size of registers, I had the following exchange on
the U-Boot mailing list.
On Tue, Feb 4, 2020 at 10:23 PM Sean Anderson <seanga2@gmail.com> wrote:
>
> On 2/4/20 6:32 AM, Bin Meng wrote:
>> Hi Sean,
>>
>> On Mon, Feb 3, 2020 at 4:10 AM Sean Anderson <seanga2@gmail.com> wrote:
>>> Should the size of a reg be the size of the documented registers, or the size
>>> of the address space which will be routed to that device?
>>
>> Perhaps we need use the size of the address space routed to that
>> device, in case there is some undocumented registers we need handle.
>
> Ok, I'll go with the whole address space then.
You may want to make similar changes for Linux; I didn't see any
documentation about what the preferred size was.
> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
> + riscv,ndev = <65>;
> + riscv,max-priority = <0x07>;
> + };
> +
> + uarths0: serial@38000000 {
> + compatible = "kendryte,k210-uart0", "sifive,uart0";
I would change the first compatible string to "kendryte,k210-uarths",
since that is how this uart is described in their documentation.
> + reg = <0x38000000 0x20>;
Same thing as the size comments above.
> + interrupts = <33>;
> + clocks = <&sysctl 0>;
Same clock comments.
> + };
> + };
> +};
>
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
@ 2020-02-15 2:02 ` Damien Le Moal
2020-02-17 13:28 ` Carlos Eduardo de Paula
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-02-15 2:02 UTC (permalink / raw)
To: Carlos Eduardo de Paula
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/02/15 0:06, Carlos Eduardo de Paula wrote:
> Hi Damien, I've tested the patches on v5.5.0 and it boots perfectly on
> my MaixGo board. I used the provided initramfs.cpio as the payload and
> got to the busybox prompt.
Great !
>
> While trying to build my own busybox, I got a few problems. I've
> checked-out your tree and copied the toolchain. Then when building
> busybox with your minimal config, I got this error:
>
> LINK busybox_unstripped
> Your linker does not support --sort-section,alignment
> Your linker does not support --sort-common
> Your linker does not support -Wl,--gc-sections
> Trying libraries: m rt
> Failed: -Wl,--start-group -lm -lrt -Wl,--end-group
> Output of:
> /opt/riscv64-uclibc/bin/riscv64-linux-gcc -Wall -Wshadow
> -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused
> -Wunused-parameter -Wunused-function -Wunused-value
> -Wmissing-prototypes -Wmissing-declarations -Wno-format-security
> -Wdeclaration-after-statement -Wold-style-definition -finline-limit=0
> -fno-builtin-strlen -fomit-frame-pointer -ffunction-sections
> -fdata-sections -fno-guess-branch-probability -funsigned-char
> -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1
> -falign-loops=1 -fno-unwind-tables -fno-asynchronous-unwind-tables
> -fno-builtin-printf -Wno-string-plus-int -Wno-constant-logical-operand
> -Os -Os -fPIC --sysroot=/opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/sysroot/
> -static -Os -static -Wl,-elf2flt=-r -o busybox_unstripped
> -Wl,--start-group applets/built-in.o archival/lib.a
> archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a
> coreutils/libcoreutils/lib.a debianutils/lib.a klibc-utils/lib.a
> e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a
> libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a
> modutils/lib.a networking/lib.a networking/libiproute/lib.a
> networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a
> selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a
> util-linux/volume_id/lib.a archival/built-in.o
> archival/libarchive/built-in.o console-tools/built-in.o
> coreutils/built-in.o coreutils/libcoreutils/built-in.o
> debianutils/built-in.o klibc-utils/built-in.o e2fsprogs/built-in.o
> editors/built-in.o findutils/built-in.o init/built-in.o
> libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o
> mailutils/built-in.o miscutils/built-in.o modutils/built-in.o
> networking/built-in.o networking/libiproute/built-in.o
> networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o
> runit/built-in.o selinux/built-in.o shell/built-in.o
> sysklogd/built-in.o util-linux/built-in.o
> util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lm
> -lrt -Wl,--end-group
> ==========
> /opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
> find crt1.o: No such file or directory
> /opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
> find crti.o: No such file or directory
> /opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
> find crtbeginT.o: No such file or directory
> collect2: error: ld returned 1 exit status
> Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
> Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam"
> make: *** [Makefile:718: busybox_unstripped] Error 1
Weird... librt is not needed normally and is actually not generated by the
toolchain due to the absence of native thread support I think. Maybe it was
needed due to some option selection in busybox you did ?
> Then I've built the complete buildroot toolchain and replaced it on /opt.
>
> Then I've proceeded to "make SKIP_STRIP=y" and "make install" and it
> built fine. I got into _install dir and ran: "find . | sudo cpio -H
> newc --create --verbose > ../k210.cpio" to generate the cpio. All this
> with the
>
> Rebuilt the kernel with it but when booting, I got this error:
>
> [ 0.259289] Run /sbin/init as init process
> [ 0.263480] Run /etc/init as init process
> [ 0.267453] Run /bin/init as init process
> [ 0.286973] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000000
> [ 0.293869] CPU: 1 PID: 1 Comm: sh Not tainted 5.5.0-dirty #19
> [ 0.299673] Call Trace:
> [ 0.302109] [<00000000800401f6>] 0x00000000800401f6
> [ 0.306969] [<000000008004033a>] 0x000000008004033a
> [ 0.311831] [<0000000080111abe>] 0x0000000080111abe
> [ 0.316693] [<000000008004340e>] 0x000000008004340e
> [ 0.321556] [<0000000080045402>] 0x0000000080045402
> [ 0.326417] [<0000000080045898>] 0x0000000080045898
> [ 0.331279] [<000000008003f1d2>] 0x000000008003f1d2
> [ 0.336142] SMP: stopping secondary CPUs
> [ 0.340065] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x00000000 ]---
The busybox _install directory is not enough on its own to become an
initramfs tree. You need to add some stuff to it. I use the following
script to build a simple one with _install as a base:
#!/bin/bash
if [ $# != 2 ]; then
echo "Usage: $0 <busybox install dir> <cpio img path>"
exit 1
fi
# Prepare
cd $1
mkdir dev sys proc tmp root etc
mkdir dev/pts dev/shm
cd dev
sudo mknod -m 622 console c 5 1
sudo mknod -m 666 null c 1 3
sudo mknod -m 666 zero c 1 5
sudo mknod -m 666 ptmx c 5 2
sudo mknod -m 666 tty c 5 0
sudo mknod -m 444 random c 1 8
sudo mknod -m 444 urandom c 1 9
sudo mknod -m 666 ttySIF0 c 4 64
sudo mknod -m 666 tty0 c 4 0
sudo chown root:tty {console,ptmx,tty}
cd ..
# Create image file
echo "Creating cpio image"
find . | cpio -H newc -o > $2
>
> I also tried with a gzipped cpio but got the "Kernel panic - not
> syncing: no cpio magic" error.
>
> What's the right way to create the cpio initramfs? I want to customize
> it a little.
You also need to copy an init script under /bin or /sbin in the _install
directory before running the above script. The one with the precompiled
image I wrote is simply:
#!/bin/sh
echo ""
echo "-----------------------------"
echo "| Kendryte K210 NOMMU Linux |"
echo "-----------------------------"
echo "Mounting /proc"
mount -t proc proc /proc
echo "Starting shell"
exec /bin/sh
At least for the config I use with busybox, I do not get one automatically.
I tend to not use the default busybox init stuff to keep control over what
is done and keep things small overall. But since things are now starting to
work well, we can start experimenting other configs for busybox (e.g. a
more complete one).
Cheers.
>
> Thanks.
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-14 20:18 ` Sean Anderson
@ 2020-02-15 2:15 ` Damien Le Moal
2020-02-15 2:26 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-02-15 2:15 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/02/15 5:18, Sean Anderson wrote:
> Hi,
>
> On 2/12/20 5:34 AM, Damien Le Moal wrote:
>> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
>> a nommu kernel. Since the sparsemem model does not make sense anyway
>> for the nommu case, do not allow selecting this option to always use
>> the flatmem model.
>>
>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>> ---
>> arch/riscv/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 73f029eae0cc..1a3b5a5276be 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>>
>> config ARCH_SPARSEMEM_ENABLE
>> def_bool y
>> + depends on MMU
>> select SPARSEMEM_VMEMMAP_ENABLE
>>
>> config ARCH_SELECT_MEMORY_MODEL
>>
>
> Just for some background, why did you choose NOMMU? Afaik the K210 has
> an MMU following the RISC-V privileged specification 1.9
Our early experiments with the k210 with opensbi revealed that the mmu is
definitely not a normal one or that it is not functional (e.g. S-mode fault
delegation bit setup leads to a hang). So at the time, we started assuming
that this is a nommu platform.
Since then, others also mentioned that there is in fact an MMU but not
following the latest specs (I think Olof mentioned that). But I have not
look into this (yet) to try to make it work. Not sure how much effort would
be needed on the kernel to support this older specs mmu.
In any case, considering the tiny 6+2MB of memory available, direct M-mode
Linux boot avoids the bootloader chain and openSBI use, which saves a lot
of memory. We could reduce this chain to opensbi with direct payload only,
but even then, page alignment will lead to memory loss. And at run-time,
nommu saves a lot too with the absence of page tables. Nommu makes sense
for this platform.
This is the first step to get this platform running Linux. Due to the low
memory, it probably isn't a practical use case to use Linux in the first
place, but it definitely is a great inexpensive platform for getting
started with RISCV. NOMMU allows running Linux without much effort. Going
forward, we can also try to get that SoC MMU running.
>
> --Sean
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-15 2:15 ` Damien Le Moal
@ 2020-02-15 2:26 ` Sean Anderson
2020-02-15 2:40 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-15 2:26 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2/14/20 9:15 PM, Damien Le Moal wrote:
> On 2020/02/15 5:18, Sean Anderson wrote:
>> Hi,
>>
>> On 2/12/20 5:34 AM, Damien Le Moal wrote:
>>> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
>>> a nommu kernel. Since the sparsemem model does not make sense anyway
>>> for the nommu case, do not allow selecting this option to always use
>>> the flatmem model.
>>>
>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>> ---
>>> arch/riscv/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>> index 73f029eae0cc..1a3b5a5276be 100644
>>> --- a/arch/riscv/Kconfig
>>> +++ b/arch/riscv/Kconfig
>>> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>>>
>>> config ARCH_SPARSEMEM_ENABLE
>>> def_bool y
>>> + depends on MMU
>>> select SPARSEMEM_VMEMMAP_ENABLE
>>>
>>> config ARCH_SELECT_MEMORY_MODEL
>>>
>>
>> Just for some background, why did you choose NOMMU? Afaik the K210 has
>> an MMU following the RISC-V privileged specification 1.9
>
> Our early experiments with the k210 with opensbi revealed that the mmu is
> definitely not a normal one or that it is not functional (e.g. S-mode fault
> delegation bit setup leads to a hang). So at the time, we started assuming
> that this is a nommu platform.
>
> Since then, others also mentioned that there is in fact an MMU but not
> following the latest specs (I think Olof mentioned that). But I have not
> look into this (yet) to try to make it work. Not sure how much effort would
> be needed on the kernel to support this older specs mmu.
>
> In any case, considering the tiny 6+2MB of memory available, direct M-mode
> Linux boot avoids the bootloader chain and openSBI use, which saves a lot
> of memory. We could reduce this chain to opensbi with direct payload only,
> but even then, page alignment will lead to memory loss. And at run-time,
> nommu saves a lot too with the absence of page tables. Nommu makes sense
> for this platform.
Well, the VM mode bits are in mstatus for this priv spec, so OpenSBI
won't work since there is no way to set them.
>
> This is the first step to get this platform running Linux. Due to the low
> memory, it probably isn't a practical use case to use Linux in the first
> place, but it definitely is a great inexpensive platform for getting
> started with RISCV. NOMMU allows running Linux without much effort. Going
> forward, we can also try to get that SoC MMU running.
Yeah, that's pretty reasonable. However, I don't think much has changed
other than the locations of some of the registers has been changed
around. The existing code to set up page table entries should not need
major modifications.
Alternatively, the base+bound scheme could probably work pretty well
with low memory, though we would not be able to re-use any existing
code.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-14 20:51 ` Sean Anderson
@ 2020-02-15 2:34 ` Damien Le Moal
2020-02-15 2:48 ` Sean Anderson
2020-02-27 19:43 ` Sean Anderson
0 siblings, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-15 2:34 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/02/15 5:51, Sean Anderson wrote:
> On 2/12/20 5:34 AM, Damien Le Moal wrote:
>> Add a generic device tree for Kendryte K210 SoC based boards. This (for
>> now) very simple device tree works for the Kendryte KD233 development
>> board, the Sipeed MAIX M1 Dock based boards and the Sipeed MAIXDUINO
>> board.
>>
>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>> ---
>> arch/riscv/boot/dts/Makefile | 1 +
>> arch/riscv/boot/dts/kendryte/Makefile | 2 +
>> arch/riscv/boot/dts/kendryte/k210.dts | 23 +++++
>> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 +++++++++++++++++++++++++
>> 4 files changed, 149 insertions(+)
>> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
>> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
>> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
>>
>> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
>> index 0bf2669aa12d..87815557f2db 100644
>> --- a/arch/riscv/boot/dts/Makefile
>> +++ b/arch/riscv/boot/dts/Makefile
>> @@ -3,4 +3,5 @@ ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
>> obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
>> else
>> subdir-y += sifive
>> +subdir-y += kendryte
>> endif
>> diff --git a/arch/riscv/boot/dts/kendryte/Makefile b/arch/riscv/boot/dts/kendryte/Makefile
>> new file mode 100644
>> index 000000000000..815444e69e89
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/kendryte/Makefile
>> @@ -0,0 +1,2 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +dtb-$(CONFIG_SOC_KENDRYTE) += k210.dtb
>> diff --git a/arch/riscv/boot/dts/kendryte/k210.dts b/arch/riscv/boot/dts/kendryte/k210.dts
>> new file mode 100644
>> index 000000000000..0d1f28fce6b2
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/kendryte/k210.dts
>> @@ -0,0 +1,23 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "k210.dtsi"
>> +
>> +/ {
>> + model = "Kendryte K210 generic";
>> + compatible = "kendryte,k210";
>> +
>> + chosen {
>> + bootargs = "earlycon console=ttySIF0";
>> + stdout-path = "serial0";
>> + };
>> +};
>> +
>> +&uarths0 {
>> + status = "okay";
>> +};
>> +
>> diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi
>> new file mode 100644
>> index 000000000000..4b9eeabb07f7
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi
>> @@ -0,0 +1,123 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
>
> Glad to see this is getting some use :)
Seeing what you did for uboot, I used a lot of it and naturally gave credit
where it is due :)
> This appears to be an old-ish version, and I've made some updates in the
> past month or so. My current work is availible from [1].
>
> [1] https://github.com/Forty-Bot/u-boot/blob/maix_v6/arch/riscv/dts/k210.dtsi
OK. Will check again.
>> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
>> + */
>> +
>> +/ {
>> + /*
>> + * Although the K210 is a 64-bit CPU, the address bus is only 32-bits
>> + * wide, and the upper half of all addresses is ignored.
>> + */
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "kendryte,k210";
>> +
>> + aliases {
>> + serial0 = &uarths0;
>> + };
>> +
>> + clocks {
>> + in0: oscillator {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <26000000>;
>> + };
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + timebase-frequency = <7800000>;
>
> This is true only for the default frequency. I wonder if there is a
> better way to encode this.
Yes, I suspected that. Seeing that the CPU frequency can be changed, I
wondered how this should all go together. But since the current code does
not change the cpu frequency, I simply stayed with the default here. I
suspect that we may want the default hard-coded in the code, and use the
value specified here as the one that should be setup by sysctl.
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + compatible = "riscv";
>> + riscv,isa = "rv64imafdc";
>> + mmu-type = "none";
>
> This should be "sv36".
If we want to run the MMU, yes. For a nommu kernel, I would rather stick
with "none". Not that it really matters since the nommu kernel will not
look at this entry anyway. No strong opinion either way in the end.
I have not checked the specs yet, but does sv36 necessarily implies older
specs 1.9 too ? If not, then we may want something else in there for this
soc special case.
>> + i-cache-size = <0x8000>;
>> + i-cache-block-size = <64>; /* bogus */
>
> I emailed some people at Kendryte and they confirmed the 64-byte
> cacheline. The cpus are rocket cores.
Good to know. I will remove the comment then.
>
>> + d-cache-size = <0x8000>;
>> + d-cache-block-size = <64>; /* bogus */
>> + clocks = <&sysctl 0>;
>
> This is correct only by coincidence. The clock structure is
>
> in0 -> pll0 -> aclk -> cpu
>
> aclk divides by two by default, so it runs at 390 MHz, which is also
> what you set pll1 to. However, if someone else (such as the bootloader)
> changes the pll0 frequency then this will be completely off.
Yes... The clock management needs more work as mentioned in the cover
letter. All of this works for now with direct m-mode boot (no boot loader)
and relies on the hardware defaults which are coded here. The sysctl driver
also relies on those defaults. A more solid implementation will need the
soc_early_init() code to discover and set things up correctly.
As mentioned in the cover letter, this is all a base. It works, but
definitely is not complete.
>> + clock-frequency = <390000000>;
>> + cpu0_intc: interrupt-controller {
>> + #interrupt-cells = <1>;
>> + interrupt-controller;
>> + compatible = "riscv,cpu-intc";
>> + };
>> + };
>> + cpu1: cpu@1 {
>> + device_type = "cpu";
>> + reg = <1>;
>> + compatible = "riscv";
>> + riscv,isa = "rv64imafdc";
>> + mmu-type = "none";
>> + i-cache-size = <0x8000>;
>> + i-cache-block-size = <64>; /* bogus */
>> + d-cache-size = <0x8000>;
>> + d-cache-block-size = <64>; /* bogus */
>> + clocks = <&sysctl 0>;
>> + clock-frequency = <390000000>;
>> + cpu1_intc: interrupt-controller {
>> + #interrupt-cells = <1>;
>> + interrupt-controller;
>> + compatible = "riscv,cpu-intc";
>> + };
>> + };
>> + };
>> +
>> + sram0: memory@80000000 {
>> + device_type = "memory";
>> + reg = <0x80000000 0x400000>;
>> + };
>> +
>> + sram1: memory@80400000 {
>> + device_type = "memory";
>> + reg = <0x80400000 0x200000>;
>> + };
>> +
>> + kpu_sram: memory@80600000 {
>> + device_type = "memory";
>> + reg = <0x80600000 0x200000>;
>> + };
>> +
>> + soc {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "kendryte,k210-soc", "simple-bus";
>
> Should the -soc suffix be here? I saw it was absent from the fu540
> device tree.
Yes, I guess it can be removed.
>> + ranges;
>> + interrupt-parent = <&plic0>;
>> +
>> + sysctl: sysctl@50440000 {
>> + compatible = "kendryte,k210-sysctl", "syscon";
>> + reg = <0x50440000 0x1000>;
>> + #clock-cells = <1>;
>> + };
>
> Would it be possible to model this as an MFD? There are a lot of
> different registers in here, many of which are unrelated to clocks. For
> example, there are also reset registers, a reboot register, and DMA
> handshake controls. I think modeling this as a clock controller only
> does not correctly reflect the hardware, and will be awkward in the
> future.
Absolutely. It is far from complete. And seeing your complete device tree,
there are likely a lot of peripherals for which Linux already has drivers
and that could be used if the clocks/sysctl are improved. As mentioned in
the cover letter, this is left as an exercise for interested people :)
Note that I am indeed interested in working on this a little more. I simply
lack the time to do it :)
>> +
>> + clint0: interrupt-controller@2000000 {
>> + compatible = "riscv,clint0";
>> + reg = <0x2000000 0xC000>;
>> + interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
>> + clocks = <&sysctl 0>;
>
> Again, this is wrong; it should be running off ACLK.
Yep. As you said, it works because we use the defaults for everything.
>> + };
>> +
>> + plic0: interrupt-controller@c000000 {
>> + #interrupt-cells = <1>;
>> + interrupt-controller;
>> + compatible = "kendryte,k210-plic0", "riscv,plic0";
>> + reg = <0xC000000 0x3FFF008>;
>
> With regard to the size of registers, I had the following exchange on
> the U-Boot mailing list.
>
> On Tue, Feb 4, 2020 at 10:23 PM Sean Anderson <seanga2@gmail.com> wrote:
>>
>> On 2/4/20 6:32 AM, Bin Meng wrote:
>>> Hi Sean,
>>>
>>> On Mon, Feb 3, 2020 at 4:10 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>> Should the size of a reg be the size of the documented registers, or the size
>>>> of the address space which will be routed to that device?
>>>
>>> Perhaps we need use the size of the address space routed to that
>>> device, in case there is some undocumented registers we need handle.
>>
>> Ok, I'll go with the whole address space then.
>
> You may want to make similar changes for Linux; I didn't see any
> documentation about what the preferred size was.
I wondered about it too. Not really sure what to do about it.
>> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
>> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
>> + riscv,ndev = <65>;
>> + riscv,max-priority = <0x07>;
>> + };
>> +
>> + uarths0: serial@38000000 {
>> + compatible = "kendryte,k210-uart0", "sifive,uart0";
>
> I would change the first compatible string to "kendryte,k210-uarths",
> since that is how this uart is described in their documentation.
OK. It makes sense.
>
>> + reg = <0x38000000 0x20>;
>
> Same thing as the size comments above.
>
>> + interrupts = <33>;
>> + clocks = <&sysctl 0>;
>
> Same clock comments.
>
>> + };
>> + };
>> +};
>>
>
> --Sean
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-15 2:26 ` Sean Anderson
@ 2020-02-15 2:40 ` Damien Le Moal
0 siblings, 0 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-15 2:40 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/02/15 11:26, Sean Anderson wrote:
> On 2/14/20 9:15 PM, Damien Le Moal wrote:
>> On 2020/02/15 5:18, Sean Anderson wrote:
>>> Hi,
>>>
>>> On 2/12/20 5:34 AM, Damien Le Moal wrote:
>>>> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
>>>> a nommu kernel. Since the sparsemem model does not make sense anyway
>>>> for the nommu case, do not allow selecting this option to always use
>>>> the flatmem model.
>>>>
>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>> ---
>>>> arch/riscv/Kconfig | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>>> index 73f029eae0cc..1a3b5a5276be 100644
>>>> --- a/arch/riscv/Kconfig
>>>> +++ b/arch/riscv/Kconfig
>>>> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>>>>
>>>> config ARCH_SPARSEMEM_ENABLE
>>>> def_bool y
>>>> + depends on MMU
>>>> select SPARSEMEM_VMEMMAP_ENABLE
>>>>
>>>> config ARCH_SELECT_MEMORY_MODEL
>>>>
>>>
>>> Just for some background, why did you choose NOMMU? Afaik the K210 has
>>> an MMU following the RISC-V privileged specification 1.9
>>
>> Our early experiments with the k210 with opensbi revealed that the mmu is
>> definitely not a normal one or that it is not functional (e.g. S-mode fault
>> delegation bit setup leads to a hang). So at the time, we started assuming
>> that this is a nommu platform.
>>
>> Since then, others also mentioned that there is in fact an MMU but not
>> following the latest specs (I think Olof mentioned that). But I have not
>> look into this (yet) to try to make it work. Not sure how much effort would
>> be needed on the kernel to support this older specs mmu.
>>
>> In any case, considering the tiny 6+2MB of memory available, direct M-mode
>> Linux boot avoids the bootloader chain and openSBI use, which saves a lot
>> of memory. We could reduce this chain to opensbi with direct payload only,
>> but even then, page alignment will lead to memory loss. And at run-time,
>> nommu saves a lot too with the absence of page tables. Nommu makes sense
>> for this platform.
>
> Well, the VM mode bits are in mstatus for this priv spec, so OpenSBI
> won't work since there is no way to set them.
Interesting. At FOSDEM, we discussed with Palmer the work that would be
needed to disentangle NOMMU and M-MODE boot, which for now are rather
synonymous, but shouldn't. I guess this platform would still require M-MODE
boot, but not necessarily NOMMU.
>> This is the first step to get this platform running Linux. Due to the low
>> memory, it probably isn't a practical use case to use Linux in the first
>> place, but it definitely is a great inexpensive platform for getting
>> started with RISCV. NOMMU allows running Linux without much effort. Going
>> forward, we can also try to get that SoC MMU running.
>
> Yeah, that's pretty reasonable. However, I don't think much has changed
> other than the locations of some of the registers has been changed
> around. The existing code to set up page table entries should not need
> major modifications.
OK. Sounds easy enough. But I think cleanup work to dissociate M-mode boot
and NOMMU will be needed first. After that, trying to enable the MMU should
be easier.
>
> Alternatively, the base+bound scheme could probably work pretty well
> with low memory, though we would not be able to re-use any existing
> code.
>
> --Sean
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-15 2:34 ` Damien Le Moal
@ 2020-02-15 2:48 ` Sean Anderson
2020-02-15 3:00 ` Damien Le Moal
2020-02-27 19:43 ` Sean Anderson
1 sibling, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-15 2:48 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2/14/20 9:34 PM, Damien Le Moal wrote:
> On 2020/02/15 5:51, Sean Anderson wrote:
>> On 2/12/20 5:34 AM, Damien Le Moal wrote:
>>> Add a generic device tree for Kendryte K210 SoC based boards. This (for
>>> now) very simple device tree works for the Kendryte KD233 development
>>> board, the Sipeed MAIX M1 Dock based boards and the Sipeed MAIXDUINO
>>> board.
>>>
>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>> ---
>>> arch/riscv/boot/dts/Makefile | 1 +
>>> arch/riscv/boot/dts/kendryte/Makefile | 2 +
>>> arch/riscv/boot/dts/kendryte/k210.dts | 23 +++++
>>> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 +++++++++++++++++++++++++
>>> 4 files changed, 149 insertions(+)
>>> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
>>> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
>>> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
>>>
>>> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
>>> index 0bf2669aa12d..87815557f2db 100644
>>> --- a/arch/riscv/boot/dts/Makefile
>>> +++ b/arch/riscv/boot/dts/Makefile
>>> @@ -3,4 +3,5 @@ ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
>>> obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
>>> else
>>> subdir-y += sifive
>>> +subdir-y += kendryte
>>> endif
>>> diff --git a/arch/riscv/boot/dts/kendryte/Makefile b/arch/riscv/boot/dts/kendryte/Makefile
>>> new file mode 100644
>>> index 000000000000..815444e69e89
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/kendryte/Makefile
>>> @@ -0,0 +1,2 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +dtb-$(CONFIG_SOC_KENDRYTE) += k210.dtb
>>> diff --git a/arch/riscv/boot/dts/kendryte/k210.dts b/arch/riscv/boot/dts/kendryte/k210.dts
>>> new file mode 100644
>>> index 000000000000..0d1f28fce6b2
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/kendryte/k210.dts
>>> @@ -0,0 +1,23 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "k210.dtsi"
>>> +
>>> +/ {
>>> + model = "Kendryte K210 generic";
>>> + compatible = "kendryte,k210";
>>> +
>>> + chosen {
>>> + bootargs = "earlycon console=ttySIF0";
>>> + stdout-path = "serial0";
>>> + };
>>> +};
>>> +
>>> +&uarths0 {
>>> + status = "okay";
>>> +};
>>> +
>>> diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi
>>> new file mode 100644
>>> index 000000000000..4b9eeabb07f7
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi
>>> @@ -0,0 +1,123 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
>>
>> Glad to see this is getting some use :)
>
> Seeing what you did for uboot, I used a lot of it and naturally gave credit
> where it is due :)
>
>> This appears to be an old-ish version, and I've made some updates in the
>> past month or so. My current work is availible from [1].
>>
>> [1] https://github.com/Forty-Bot/u-boot/blob/maix_v6/arch/riscv/dts/k210.dtsi
>
> OK. Will check again.
>
>>> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
>>> + */
>>> +
>>> +/ {
>>> + /*
>>> + * Although the K210 is a 64-bit CPU, the address bus is only 32-bits
>>> + * wide, and the upper half of all addresses is ignored.
>>> + */
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "kendryte,k210";
>>> +
>>> + aliases {
>>> + serial0 = &uarths0;
>>> + };
>>> +
>>> + clocks {
>>> + in0: oscillator {
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <26000000>;
>>> + };
>>> + };
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + timebase-frequency = <7800000>;
>>
>> This is true only for the default frequency. I wonder if there is a
>> better way to encode this.
>
> Yes, I suspected that. Seeing that the CPU frequency can be changed, I
> wondered how this should all go together. But since the current code does
> not change the cpu frequency, I simply stayed with the default here. I
> suspect that we may want the default hard-coded in the code, and use the
> value specified here as the one that should be setup by sysctl.
>
>>> + cpu0: cpu@0 {
>>> + device_type = "cpu";
>>> + reg = <0>;
>>> + compatible = "riscv";
>>> + riscv,isa = "rv64imafdc";
>>> + mmu-type = "none";
>>
>> This should be "sv36".
>
> If we want to run the MMU, yes. For a nommu kernel, I would rather stick
> with "none". Not that it really matters since the nommu kernel will not
> look at this entry anyway. No strong opinion either way in the end.
> I have not checked the specs yet, but does sv36 necessarily implies older
> specs 1.9 too ? If not, then we may want something else in there for this
> soc special case.
Ah, this should be "sv39", sorry. Ideally we would put something like
the priv spec version in the isa string, or perhaps as a separate
property. From reading the dt docs, it seems like one should try to
describe the hardware as best as possible to allow for
foward-compatibility.
>>> + i-cache-size = <0x8000>;
>>> + i-cache-block-size = <64>; /* bogus */
>>
>> I emailed some people at Kendryte and they confirmed the 64-byte
>> cacheline. The cpus are rocket cores.
>
> Good to know. I will remove the comment then.
>
>>
>>> + d-cache-size = <0x8000>;
>>> + d-cache-block-size = <64>; /* bogus */
>>> + clocks = <&sysctl 0>;
>>
>> This is correct only by coincidence. The clock structure is
>>
>> in0 -> pll0 -> aclk -> cpu
>>
>> aclk divides by two by default, so it runs at 390 MHz, which is also
>> what you set pll1 to. However, if someone else (such as the bootloader)
>> changes the pll0 frequency then this will be completely off.
>
> Yes... The clock management needs more work as mentioned in the cover
> letter. All of this works for now with direct m-mode boot (no boot loader)
> and relies on the hardware defaults which are coded here. The sysctl driver
> also relies on those defaults. A more solid implementation will need the
> soc_early_init() code to discover and set things up correctly.
>
> As mentioned in the cover letter, this is all a base. It works, but
> definitely is not complete.
At the very least, I would different identifiers for each clock. That
way you can ignore them now and add support later. There isn't a
"natural" ordering (since the clocks are in a different order in every
register), so I am using this arbitrary numbering scheme [1].
[1] https://github.com/Forty-Bot/u-boot/blob/maix_v6/include/dt-bindings/clock/k210-sysctl.h
>>> + clock-frequency = <390000000>;
>>> + cpu0_intc: interrupt-controller {
>>> + #interrupt-cells = <1>;
>>> + interrupt-controller;
>>> + compatible = "riscv,cpu-intc";
>>> + };
>>> + };
>>> + cpu1: cpu@1 {
>>> + device_type = "cpu";
>>> + reg = <1>;
>>> + compatible = "riscv";
>>> + riscv,isa = "rv64imafdc";
>>> + mmu-type = "none";
>>> + i-cache-size = <0x8000>;
>>> + i-cache-block-size = <64>; /* bogus */
>>> + d-cache-size = <0x8000>;
>>> + d-cache-block-size = <64>; /* bogus */
>>> + clocks = <&sysctl 0>;
>>> + clock-frequency = <390000000>;
>>> + cpu1_intc: interrupt-controller {
>>> + #interrupt-cells = <1>;
>>> + interrupt-controller;
>>> + compatible = "riscv,cpu-intc";
>>> + };
>>> + };
>>> + };
>>> +
>>> + sram0: memory@80000000 {
>>> + device_type = "memory";
>>> + reg = <0x80000000 0x400000>;
>>> + };
>>> +
>>> + sram1: memory@80400000 {
>>> + device_type = "memory";
>>> + reg = <0x80400000 0x200000>;
>>> + };
>>> +
>>> + kpu_sram: memory@80600000 {
>>> + device_type = "memory";
>>> + reg = <0x80600000 0x200000>;
>>> + };
>>> +
>>> + soc {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "kendryte,k210-soc", "simple-bus";
>>
>> Should the -soc suffix be here? I saw it was absent from the fu540
>> device tree.
>
> Yes, I guess it can be removed.
>
>>> + ranges;
>>> + interrupt-parent = <&plic0>;
>>> +
>>> + sysctl: sysctl@50440000 {
>>> + compatible = "kendryte,k210-sysctl", "syscon";
>>> + reg = <0x50440000 0x1000>;
>>> + #clock-cells = <1>;
>>> + };
>>
>> Would it be possible to model this as an MFD? There are a lot of
>> different registers in here, many of which are unrelated to clocks. For
>> example, there are also reset registers, a reboot register, and DMA
>> handshake controls. I think modeling this as a clock controller only
>> does not correctly reflect the hardware, and will be awkward in the
>> future.
>
> Absolutely. It is far from complete. And seeing your complete device tree,
> there are likely a lot of peripherals for which Linux already has drivers
> and that could be used if the clocks/sysctl are improved. As mentioned in
> the cover letter, this is left as an exercise for interested people :)
> Note that I am indeed interested in working on this a little more. I simply
> lack the time to do it :)
My next project after u-boot support was going to be Linux, so I can
lend a hand after I get everything merged on that end.
>>> +
>>> + clint0: interrupt-controller@2000000 {
>>> + compatible = "riscv,clint0";
>>> + reg = <0x2000000 0xC000>;
>>> + interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
>>> + clocks = <&sysctl 0>;
>>
>> Again, this is wrong; it should be running off ACLK.
>
> Yep. As you said, it works because we use the defaults for everything.
>
>>> + };
>>> +
>>> + plic0: interrupt-controller@c000000 {
>>> + #interrupt-cells = <1>;
>>> + interrupt-controller;
>>> + compatible = "kendryte,k210-plic0", "riscv,plic0";
>>> + reg = <0xC000000 0x3FFF008>;
>>
>> With regard to the size of registers, I had the following exchange on
>> the U-Boot mailing list.
>>
>> On Tue, Feb 4, 2020 at 10:23 PM Sean Anderson <seanga2@gmail.com> wrote:
>>>
>>> On 2/4/20 6:32 AM, Bin Meng wrote:
>>>> Hi Sean,
>>>>
>>>> On Mon, Feb 3, 2020 at 4:10 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>> Should the size of a reg be the size of the documented registers, or the size
>>>>> of the address space which will be routed to that device?
>>>>
>>>> Perhaps we need use the size of the address space routed to that
>>>> device, in case there is some undocumented registers we need handle.
>>>
>>> Ok, I'll go with the whole address space then.
>>
>> You may want to make similar changes for Linux; I didn't see any
>> documentation about what the preferred size was.
>
> I wondered about it too. Not really sure what to do about it.
The sizes in my device tree are based on reading device memory and
seeing where it repeats. For example, the memory at 50210000 and
50210100 is the same, so I set the uart1 reg to <50210000 0x100>.
>>> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
>>> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
>>> + riscv,ndev = <65>;
>>> + riscv,max-priority = <0x07>;
>>> + };
>>> +
>>> + uarths0: serial@38000000 {
>>> + compatible = "kendryte,k210-uart0", "sifive,uart0";
>>
>> I would change the first compatible string to "kendryte,k210-uarths",
>> since that is how this uart is described in their documentation.
>
> OK. It makes sense.
>
>>
>>> + reg = <0x38000000 0x20>;
>>
>> Same thing as the size comments above.
>>
>>> + interrupts = <33>;
>>> + clocks = <&sysctl 0>;
>>
>> Same clock comments.
>>
>>> + };
>>> + };
>>> +};
>>>
>>
>> --Sean
>>
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-15 2:48 ` Sean Anderson
@ 2020-02-15 3:00 ` Damien Le Moal
2020-02-18 14:12 ` Carlos Eduardo de Paula
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-02-15 3:00 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/02/15 11:48, Sean Anderson wrote:
>>>> + cpu0: cpu@0 {
>>>> + device_type = "cpu";
>>>> + reg = <0>;
>>>> + compatible = "riscv";
>>>> + riscv,isa = "rv64imafdc";
>>>> + mmu-type = "none";
>>>
>>> This should be "sv36".
>>
>> If we want to run the MMU, yes. For a nommu kernel, I would rather stick
>> with "none". Not that it really matters since the nommu kernel will not
>> look at this entry anyway. No strong opinion either way in the end.
>> I have not checked the specs yet, but does sv36 necessarily implies older
>> specs 1.9 too ? If not, then we may want something else in there for this
>> soc special case.
>
> Ah, this should be "sv39", sorry. Ideally we would put something like
> the priv spec version in the isa string, or perhaps as a separate
> property. From reading the dt docs, it seems like one should try to
> describe the hardware as best as possible to allow for
> foward-compatibility.
OK. But I guess we can keep the "none" here until we get to work on the MMU
support. That definitely sounds safer to me considering the specs difference.
>>>> + d-cache-size = <0x8000>;
>>>> + d-cache-block-size = <64>; /* bogus */
>>>> + clocks = <&sysctl 0>;
>>>
>>> This is correct only by coincidence. The clock structure is
>>>
>>> in0 -> pll0 -> aclk -> cpu
>>>
>>> aclk divides by two by default, so it runs at 390 MHz, which is also
>>> what you set pll1 to. However, if someone else (such as the bootloader)
>>> changes the pll0 frequency then this will be completely off.
>>
>> Yes... The clock management needs more work as mentioned in the cover
>> letter. All of this works for now with direct m-mode boot (no boot loader)
>> and relies on the hardware defaults which are coded here. The sysctl driver
>> also relies on those defaults. A more solid implementation will need the
>> soc_early_init() code to discover and set things up correctly.
>>
>> As mentioned in the cover letter, this is all a base. It works, but
>> definitely is not complete.
>
> At the very least, I would different identifiers for each clock. That
> way you can ignore them now and add support later. There isn't a
> "natural" ordering (since the clocks are in a different order in every
> register), so I am using this arbitrary numbering scheme [1].
>
> [1] https://github.com/Forty-Bot/u-boot/blob/maix_v6/include/dt-bindings/clock/k210-sysctl.h
Good idea. I had a look at this when I used your device tree but decided on
not using it for simplicity since using the default HW setup led to that
single clock 0. But this is a good point. I will use the identifiers and
for now have all the IDs used defined to "0". As the sysctl driver is
changed and improved, the DT can remain the same and more devices added easily.
>>>> + ranges;
>>>> + interrupt-parent = <&plic0>;
>>>> +
>>>> + sysctl: sysctl@50440000 {
>>>> + compatible = "kendryte,k210-sysctl", "syscon";
>>>> + reg = <0x50440000 0x1000>;
>>>> + #clock-cells = <1>;
>>>> + };
>>>
>>> Would it be possible to model this as an MFD? There are a lot of
>>> different registers in here, many of which are unrelated to clocks. For
>>> example, there are also reset registers, a reboot register, and DMA
>>> handshake controls. I think modeling this as a clock controller only
>>> does not correctly reflect the hardware, and will be awkward in the
>>> future.
>>
>> Absolutely. It is far from complete. And seeing your complete device tree,
>> there are likely a lot of peripherals for which Linux already has drivers
>> and that could be used if the clocks/sysctl are improved. As mentioned in
>> the cover letter, this is left as an exercise for interested people :)
>> Note that I am indeed interested in working on this a little more. I simply
>> lack the time to do it :)
>
> My next project after u-boot support was going to be Linux, so I can
> lend a hand after I get everything merged on that end.
That would be great !
>>>> + plic0: interrupt-controller@c000000 {
>>>> + #interrupt-cells = <1>;
>>>> + interrupt-controller;
>>>> + compatible = "kendryte,k210-plic0", "riscv,plic0";
>>>> + reg = <0xC000000 0x3FFF008>;
>>>
>>> With regard to the size of registers, I had the following exchange on
>>> the U-Boot mailing list.
>>>
>>> On Tue, Feb 4, 2020 at 10:23 PM Sean Anderson <seanga2@gmail.com> wrote:
>>>>
>>>> On 2/4/20 6:32 AM, Bin Meng wrote:
>>>>> Hi Sean,
>>>>>
>>>>> On Mon, Feb 3, 2020 at 4:10 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>>> Should the size of a reg be the size of the documented registers, or the size
>>>>>> of the address space which will be routed to that device?
>>>>>
>>>>> Perhaps we need use the size of the address space routed to that
>>>>> device, in case there is some undocumented registers we need handle.
>>>>
>>>> Ok, I'll go with the whole address space then.
>>>
>>> You may want to make similar changes for Linux; I didn't see any
>>> documentation about what the preferred size was.
>>
>> I wondered about it too. Not really sure what to do about it.
>
> The sizes in my device tree are based on reading device memory and
> seeing where it repeats. For example, the memory at 50210000 and
> 50210100 is the same, so I set the uart1 reg to <50210000 0x100>.
OK. Will make changes and retest.
>
>>>> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
>>>> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
>>>> + riscv,ndev = <65>;
>>>> + riscv,max-priority = <0x07>;
>>>> + };
>>>> +
>>>> + uarths0: serial@38000000 {
>>>> + compatible = "kendryte,k210-uart0", "sifive,uart0";
>>>
>>> I would change the first compatible string to "kendryte,k210-uarths",
>>> since that is how this uart is described in their documentation.
>>
>> OK. It makes sense.
>>
>>>
>>>> + reg = <0x38000000 0x20>;
>>>
>>> Same thing as the size comments above.
>>>
>>>> + interrupts = <33>;
>>>> + clocks = <&sysctl 0>;
>>>
>>> Same clock comments.
>>>
>>>> + };
>>>> + };
>>>> +};
>>>>
>>>
>>> --Sean
>>>
>>
>>
>
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-15 2:02 ` Damien Le Moal
@ 2020-02-17 13:28 ` Carlos Eduardo de Paula
2020-02-26 21:31 ` Carlos Eduardo de Paula
0 siblings, 1 reply; 89+ messages in thread
From: Carlos Eduardo de Paula @ 2020-02-17 13:28 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
Hi Damien, thanks for pointing this out. I've created the directory
structure and their permissions and was able to build a custom
busybox. I'll now check on how to use the buildroot generated cpio on
it.
On Fri, Feb 14, 2020 at 11:02 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2020/02/15 0:06, Carlos Eduardo de Paula wrote:
> > Hi Damien, I've tested the patches on v5.5.0 and it boots perfectly on
> > my MaixGo board. I used the provided initramfs.cpio as the payload and
> > got to the busybox prompt.
>
> Great !
>
> >
> > While trying to build my own busybox, I got a few problems. I've
> > checked-out your tree and copied the toolchain. Then when building
> > busybox with your minimal config, I got this error:
> >
> > LINK busybox_unstripped
> > Your linker does not support --sort-section,alignment
> > Your linker does not support --sort-common
> > Your linker does not support -Wl,--gc-sections
> > Trying libraries: m rt
> > Failed: -Wl,--start-group -lm -lrt -Wl,--end-group
> > Output of:
> > /opt/riscv64-uclibc/bin/riscv64-linux-gcc -Wall -Wshadow
> > -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused
> > -Wunused-parameter -Wunused-function -Wunused-value
> > -Wmissing-prototypes -Wmissing-declarations -Wno-format-security
> > -Wdeclaration-after-statement -Wold-style-definition -finline-limit=0
> > -fno-builtin-strlen -fomit-frame-pointer -ffunction-sections
> > -fdata-sections -fno-guess-branch-probability -funsigned-char
> > -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1
> > -falign-loops=1 -fno-unwind-tables -fno-asynchronous-unwind-tables
> > -fno-builtin-printf -Wno-string-plus-int -Wno-constant-logical-operand
> > -Os -Os -fPIC --sysroot=/opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/sysroot/
> > -static -Os -static -Wl,-elf2flt=-r -o busybox_unstripped
> > -Wl,--start-group applets/built-in.o archival/lib.a
> > archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a
> > coreutils/libcoreutils/lib.a debianutils/lib.a klibc-utils/lib.a
> > e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a
> > libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a
> > modutils/lib.a networking/lib.a networking/libiproute/lib.a
> > networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a
> > selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a
> > util-linux/volume_id/lib.a archival/built-in.o
> > archival/libarchive/built-in.o console-tools/built-in.o
> > coreutils/built-in.o coreutils/libcoreutils/built-in.o
> > debianutils/built-in.o klibc-utils/built-in.o e2fsprogs/built-in.o
> > editors/built-in.o findutils/built-in.o init/built-in.o
> > libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o
> > mailutils/built-in.o miscutils/built-in.o modutils/built-in.o
> > networking/built-in.o networking/libiproute/built-in.o
> > networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o
> > runit/built-in.o selinux/built-in.o shell/built-in.o
> > sysklogd/built-in.o util-linux/built-in.o
> > util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lm
> > -lrt -Wl,--end-group
> > ==========
> > /opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
> > find crt1.o: No such file or directory
> > /opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
> > find crti.o: No such file or directory
> > /opt/riscv64-uclibc/riscv64-buildroot-linux-uclibc/bin/ld.real: cannot
> > find crtbeginT.o: No such file or directory
> > collect2: error: ld returned 1 exit status
> > Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
> > Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam"
> > make: *** [Makefile:718: busybox_unstripped] Error 1
>
> Weird... librt is not needed normally and is actually not generated by the
> toolchain due to the absence of native thread support I think. Maybe it was
> needed due to some option selection in busybox you did ?
>
> > Then I've built the complete buildroot toolchain and replaced it on /opt.
> >
> > Then I've proceeded to "make SKIP_STRIP=y" and "make install" and it
> > built fine. I got into _install dir and ran: "find . | sudo cpio -H
> > newc --create --verbose > ../k210.cpio" to generate the cpio. All this
> > with the
> >
> > Rebuilt the kernel with it but when booting, I got this error:
> >
> > [ 0.259289] Run /sbin/init as init process
> > [ 0.263480] Run /etc/init as init process
> > [ 0.267453] Run /bin/init as init process
> > [ 0.286973] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x00000000
> > [ 0.293869] CPU: 1 PID: 1 Comm: sh Not tainted 5.5.0-dirty #19
> > [ 0.299673] Call Trace:
> > [ 0.302109] [<00000000800401f6>] 0x00000000800401f6
> > [ 0.306969] [<000000008004033a>] 0x000000008004033a
> > [ 0.311831] [<0000000080111abe>] 0x0000000080111abe
> > [ 0.316693] [<000000008004340e>] 0x000000008004340e
> > [ 0.321556] [<0000000080045402>] 0x0000000080045402
> > [ 0.326417] [<0000000080045898>] 0x0000000080045898
> > [ 0.331279] [<000000008003f1d2>] 0x000000008003f1d2
> > [ 0.336142] SMP: stopping secondary CPUs
> > [ 0.340065] ---[ end Kernel panic - not syncing: Attempted to kill
> > init! exitcode=0x00000000 ]---
>
> The busybox _install directory is not enough on its own to become an
> initramfs tree. You need to add some stuff to it. I use the following
> script to build a simple one with _install as a base:
>
> #!/bin/bash
>
> if [ $# != 2 ]; then
> echo "Usage: $0 <busybox install dir> <cpio img path>"
> exit 1
> fi
>
> # Prepare
> cd $1
> mkdir dev sys proc tmp root etc
> mkdir dev/pts dev/shm
>
> cd dev
> sudo mknod -m 622 console c 5 1
> sudo mknod -m 666 null c 1 3
> sudo mknod -m 666 zero c 1 5
> sudo mknod -m 666 ptmx c 5 2
> sudo mknod -m 666 tty c 5 0
> sudo mknod -m 444 random c 1 8
> sudo mknod -m 444 urandom c 1 9
> sudo mknod -m 666 ttySIF0 c 4 64
> sudo mknod -m 666 tty0 c 4 0
> sudo chown root:tty {console,ptmx,tty}
> cd ..
>
> # Create image file
> echo "Creating cpio image"
>
> find . | cpio -H newc -o > $2
>
> >
> > I also tried with a gzipped cpio but got the "Kernel panic - not
> > syncing: no cpio magic" error.
> >
> > What's the right way to create the cpio initramfs? I want to customize
> > it a little.
>
> You also need to copy an init script under /bin or /sbin in the _install
> directory before running the above script. The one with the precompiled
> image I wrote is simply:
>
> #!/bin/sh
>
> echo ""
> echo "-----------------------------"
> echo "| Kendryte K210 NOMMU Linux |"
> echo "-----------------------------"
>
> echo "Mounting /proc"
> mount -t proc proc /proc
>
> echo "Starting shell"
> exec /bin/sh
>
>
> At least for the config I use with busybox, I do not get one automatically.
> I tend to not use the default busybox init stuff to keep control over what
> is done and keep things small overall. But since things are now starting to
> work well, we can start experimenting other configs for busybox (e.g. a
> more complete one).
>
> Cheers.
>
> >
> > Thanks.
> >
>
>
> --
> Damien Le Moal
> Western Digital Research
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-15 3:00 ` Damien Le Moal
@ 2020-02-18 14:12 ` Carlos Eduardo de Paula
2020-02-18 14:18 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Carlos Eduardo de Paula @ 2020-02-18 14:12 UTC (permalink / raw)
To: Damien Le Moal
Cc: orionwl, Anup Patel, Sean Anderson, Palmer Dabbelt,
Paul Walmsley, linux-riscv
On Sat, Feb 15, 2020 at 12:00 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2020/02/15 11:48, Sean Anderson wrote:
> >>>> + cpu0: cpu@0 {
> >>>> + device_type = "cpu";
> >>>> + reg = <0>;
> >>>> + compatible = "riscv";
> >>>> + riscv,isa = "rv64imafdc";
> >>>> + mmu-type = "none";
> >>>
> >>> This should be "sv36".
> >>
> >> If we want to run the MMU, yes. For a nommu kernel, I would rather stick
> >> with "none". Not that it really matters since the nommu kernel will not
> >> look at this entry anyway. No strong opinion either way in the end.
> >> I have not checked the specs yet, but does sv36 necessarily implies older
> >> specs 1.9 too ? If not, then we may want something else in there for this
> >> soc special case.
> >
> > Ah, this should be "sv39", sorry. Ideally we would put something like
> > the priv spec version in the isa string, or perhaps as a separate
> > property. From reading the dt docs, it seems like one should try to
> > describe the hardware as best as possible to allow for
> > foward-compatibility.
>
> OK. But I guess we can keep the "none" here until we get to work on the MMU
> support. That definitely sounds safer to me considering the specs difference.
>
> >>>> + d-cache-size = <0x8000>;
> >>>> + d-cache-block-size = <64>; /* bogus */
> >>>> + clocks = <&sysctl 0>;
> >>>
> >>> This is correct only by coincidence. The clock structure is
> >>>
> >>> in0 -> pll0 -> aclk -> cpu
> >>>
> >>> aclk divides by two by default, so it runs at 390 MHz, which is also
> >>> what you set pll1 to. However, if someone else (such as the bootloader)
> >>> changes the pll0 frequency then this will be completely off.
> >>
> >> Yes... The clock management needs more work as mentioned in the cover
> >> letter. All of this works for now with direct m-mode boot (no boot loader)
> >> and relies on the hardware defaults which are coded here. The sysctl driver
> >> also relies on those defaults. A more solid implementation will need the
> >> soc_early_init() code to discover and set things up correctly.
> >>
> >> As mentioned in the cover letter, this is all a base. It works, but
> >> definitely is not complete.
> >
> > At the very least, I would different identifiers for each clock. That
> > way you can ignore them now and add support later. There isn't a
> > "natural" ordering (since the clocks are in a different order in every
> > register), so I am using this arbitrary numbering scheme [1].
> >
> > [1] https://github.com/Forty-Bot/u-boot/blob/maix_v6/include/dt-bindings/clock/k210-sysctl.h
>
> Good idea. I had a look at this when I used your device tree but decided on
> not using it for simplicity since using the default HW setup led to that
> single clock 0. But this is a good point. I will use the identifiers and
> for now have all the IDs used defined to "0". As the sysctl driver is
> changed and improved, the DT can remain the same and more devices added easily.
>
> >>>> + ranges;
> >>>> + interrupt-parent = <&plic0>;
> >>>> +
> >>>> + sysctl: sysctl@50440000 {
> >>>> + compatible = "kendryte,k210-sysctl", "syscon";
> >>>> + reg = <0x50440000 0x1000>;
> >>>> + #clock-cells = <1>;
> >>>> + };
> >>>
> >>> Would it be possible to model this as an MFD? There are a lot of
> >>> different registers in here, many of which are unrelated to clocks. For
> >>> example, there are also reset registers, a reboot register, and DMA
> >>> handshake controls. I think modeling this as a clock controller only
> >>> does not correctly reflect the hardware, and will be awkward in the
> >>> future.
> >>
> >> Absolutely. It is far from complete. And seeing your complete device tree,
> >> there are likely a lot of peripherals for which Linux already has drivers
> >> and that could be used if the clocks/sysctl are improved. As mentioned in
> >> the cover letter, this is left as an exercise for interested people :)
> >> Note that I am indeed interested in working on this a little more. I simply
> >> lack the time to do it :)
> >
> > My next project after u-boot support was going to be Linux, so I can
> > lend a hand after I get everything merged on that end.
>
> That would be great !
>
> >>>> + plic0: interrupt-controller@c000000 {
> >>>> + #interrupt-cells = <1>;
> >>>> + interrupt-controller;
> >>>> + compatible = "kendryte,k210-plic0", "riscv,plic0";
> >>>> + reg = <0xC000000 0x3FFF008>;
> >>>
> >>> With regard to the size of registers, I had the following exchange on
> >>> the U-Boot mailing list.
> >>>
> >>> On Tue, Feb 4, 2020 at 10:23 PM Sean Anderson <seanga2@gmail.com> wrote:
> >>>>
> >>>> On 2/4/20 6:32 AM, Bin Meng wrote:
> >>>>> Hi Sean,
> >>>>>
> >>>>> On Mon, Feb 3, 2020 at 4:10 AM Sean Anderson <seanga2@gmail.com> wrote:
> >>>>>> Should the size of a reg be the size of the documented registers, or the size
> >>>>>> of the address space which will be routed to that device?
> >>>>>
> >>>>> Perhaps we need use the size of the address space routed to that
> >>>>> device, in case there is some undocumented registers we need handle.
> >>>>
> >>>> Ok, I'll go with the whole address space then.
> >>>
> >>> You may want to make similar changes for Linux; I didn't see any
> >>> documentation about what the preferred size was.
> >>
> >> I wondered about it too. Not really sure what to do about it.
> >
> > The sizes in my device tree are based on reading device memory and
> > seeing where it repeats. For example, the memory at 50210000 and
> > 50210100 is the same, so I set the uart1 reg to <50210000 0x100>.
>
> OK. Will make changes and retest.
>
> >
> >>>> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
> >>>> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
> >>>> + riscv,ndev = <65>;
> >>>> + riscv,max-priority = <0x07>;
> >>>> + };
> >>>> +
> >>>> + uarths0: serial@38000000 {
> >>>> + compatible = "kendryte,k210-uart0", "sifive,uart0";
> >>>
> >>> I would change the first compatible string to "kendryte,k210-uarths",
> >>> since that is how this uart is described in their documentation.
> >>
> >> OK. It makes sense.
> >>
> >>>
> >>>> + reg = <0x38000000 0x20>;
> >>>
> >>> Same thing as the size comments above.
> >>>
> >>>> + interrupts = <33>;
> >>>> + clocks = <&sysctl 0>;
> >>>
> >>> Same clock comments.
> >>>
> >>>> + };
> >>>> + };
> >>>> +};
> >>>>
> >>>
> >>> --Sean
> >>>
> >>
> >>
> >
> >
>
>
> --
> Damien Le Moal
> Western Digital Research
>
Maybe it's a known thing but I found an MMU implementation here:
https://gist.github.com/44670/0d8c152df7c5b59d17d469aba4dda0e5
Comes from as fork of the sdk here https://github.com/44670/libk9
implementing also the LCD and other peripheral support.
Might help out adding support to it.
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-18 14:12 ` Carlos Eduardo de Paula
@ 2020-02-18 14:18 ` Sean Anderson
2020-02-18 14:30 ` Carlos Eduardo de Paula
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-18 14:18 UTC (permalink / raw)
To: Carlos Eduardo de Paula, Damien Le Moal
Cc: orionwl, linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2/18/20 9:12 AM, Carlos Eduardo de Paula wrote:
> Maybe it's a known thing but I found an MMU implementation here:
> https://gist.github.com/44670/0d8c152df7c5b59d17d469aba4dda0e5
Yeah, that's part of the evidence which convinced me to research the vm
capabilities of the k210 after I saw Christoph's series was NOMMU.
> Comes from as fork of the sdk here https://github.com/44670/libk9
> implementing also the LCD and other peripheral support.
>
> Might help out adding support to it.
Hmm, maybe. I've been wrangling a bit trying to get the SD card slot to
work.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-18 14:18 ` Sean Anderson
@ 2020-02-18 14:30 ` Carlos Eduardo de Paula
2020-02-18 17:48 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Carlos Eduardo de Paula @ 2020-02-18 14:30 UTC (permalink / raw)
To: Sean Anderson
Cc: Damien Le Moal, Anup Patel, Palmer Dabbelt, linux-riscv, Paul Walmsley
On Tue, Feb 18, 2020 at 11:18 AM Sean Anderson <seanga2@gmail.com> wrote:
>
> On 2/18/20 9:12 AM, Carlos Eduardo de Paula wrote:
> > Maybe it's a known thing but I found an MMU implementation here:
> > https://gist.github.com/44670/0d8c152df7c5b59d17d469aba4dda0e5
>
> Yeah, that's part of the evidence which convinced me to research the vm
> capabilities of the k210 after I saw Christoph's series was NOMMU.
>
> > Comes from as fork of the sdk here https://github.com/44670/libk9
> > implementing also the LCD and other peripheral support.
> >
> > Might help out adding support to it.
>
> Hmm, maybe. I've been wrangling a bit trying to get the SD card slot to
> work.
>
> --Sean
Yes, I started looking at the SD card but had no clue on what needs to
be done regarding GPIO - FPIO - SPI pre-reqs for it.
Wladimir (don't know his email) started playing with UART1 interface
to the 8285 module to allow WiFi communication. We thought about
having a TUN/TAP interface over it to bring the TCP/IP stack up.
https://twitter.com/orionwl/status/1229442145628585990
Carlos
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-18 14:30 ` Carlos Eduardo de Paula
@ 2020-02-18 17:48 ` Sean Anderson
2020-02-18 19:26 ` Carlos Eduardo de Paula
2020-02-19 8:50 ` Wladimir J. van der Laan
0 siblings, 2 replies; 89+ messages in thread
From: Sean Anderson @ 2020-02-18 17:48 UTC (permalink / raw)
To: Carlos Eduardo de Paula
Cc: Damien Le Moal, Wladimir J. van der Laan, Anup Patel,
Palmer Dabbelt, Paul Walmsley, linux-riscv
On 2/18/20 9:30 AM, Carlos Eduardo de Paula wrote:
> On Tue, Feb 18, 2020 at 11:18 AM Sean Anderson <seanga2@gmail.com> wrote:
>>
>> On 2/18/20 9:12 AM, Carlos Eduardo de Paula wrote:
>>> Maybe it's a known thing but I found an MMU implementation here:
>>> https://gist.github.com/44670/0d8c152df7c5b59d17d469aba4dda0e5
>>
>> Yeah, that's part of the evidence which convinced me to research the vm
>> capabilities of the k210 after I saw Christoph's series was NOMMU.
>>
>>> Comes from as fork of the sdk here https://github.com/44670/libk9
>>> implementing also the LCD and other peripheral support.
So the LCD connector is supposed to be for a ST7789V controller, but
there doesn't appear to be a driver in Linux for it. I don't have an
appropriate LCD screen, so I will not be able to write a driver.
>>>
>>> Might help out adding support to it.
>>
>> Hmm, maybe. I've been wrangling a bit trying to get the SD card slot to
>> work.
>>
>> --Sean
>
> Yes, I started looking at the SD card but had no clue on what needs to
> be done regarding GPIO - FPIO - SPI pre-reqs for it.
There is no need for GPIOs. The datasheet shows SPI0 as hooked up to the
SD card, but the default pinconf doesn't have it hooked up. In addition,
the dedicated SPI0 data lines are already connected to the LCD. For
these reasons, I decided to hook up SPI1 to the card slot. I have some
preliminary patches to add FPIOA support to u-boot. If you are
interested in my current progress, it is availible from [1]. This is not
a "stable" branch though, and I frequently rebase/force-push to it.
[1] https://github.com/Forty-Bot/u-boot/tree/maix_v6
> Wladimir (don't know his email) started playing with UART1 interface
> to the 8285 module to allow WiFi communication. We thought about
> having a TUN/TAP interface over it to bring the TCP/IP stack up.
> https://twitter.com/orionwl/status/1229442145628585990
Nice. I don't think too many raw register pokes should be needed,
because you are just using a uart to communicate...
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-18 17:48 ` Sean Anderson
@ 2020-02-18 19:26 ` Carlos Eduardo de Paula
2020-02-19 9:06 ` Wladimir J. van der Laan
2020-02-19 8:50 ` Wladimir J. van der Laan
1 sibling, 1 reply; 89+ messages in thread
From: Carlos Eduardo de Paula @ 2020-02-18 19:26 UTC (permalink / raw)
To: Sean Anderson
Cc: Damien Le Moal, Wladimir J. van der Laan, Anup Patel,
Palmer Dabbelt, Paul Walmsley, linux-riscv
On Tue, Feb 18, 2020 at 2:48 PM Sean Anderson <seanga2@gmail.com> wrote:
>
> So the LCD connector is supposed to be for a ST7789V controller, but
> there doesn't appear to be a driver in Linux for it. I don't have an
> appropriate LCD screen, so I will not be able to write a driver.
>
Actually there is a driver and config DRM_PANEL_SITRONIX_ST7789V, in
gpu/drm/panel/panel-sitronix-st7789v.c and also FB_TFT_ST7789V and
CONFIG_FB_TFT_ST7789V with the driver a in
staging/fbtft/fb_st7789v.c. Might be easier :)
Weird that the Kendryte SDK refers to the LCD as NT35310
(https://github.com/kendryte/kendryte-standalone-demo/tree/develop/lcd).
> >>>
> >>> Might help out adding support to it.
> >>
> >> Hmm, maybe. I've been wrangling a bit trying to get the SD card slot to
> >> work.
> >>
> >> --Sean
> >
> > Yes, I started looking at the SD card but had no clue on what needs to
> > be done regarding GPIO - FPIO - SPI pre-reqs for it.
>
> There is no need for GPIOs. The datasheet shows SPI0 as hooked up to the
> SD card, but the default pinconf doesn't have it hooked up. In addition,
> the dedicated SPI0 data lines are already connected to the LCD. For
> these reasons, I decided to hook up SPI1 to the card slot. I have some
> preliminary patches to add FPIOA support to u-boot. If you are
> interested in my current progress, it is availible from [1]. This is not
> a "stable" branch though, and I frequently rebase/force-push to it.
>
> [1] https://github.com/Forty-Bot/u-boot/tree/maix_v6
>
Nice, gonna take a look at it.
> > Wladimir (don't know his email) started playing with UART1 interface
> > to the 8285 module to allow WiFi communication. We thought about
> > having a TUN/TAP interface over it to bring the TCP/IP stack up.
> > https://twitter.com/orionwl/status/1229442145628585990
>
> Nice. I don't think too many raw register pokes should be needed,
> because you are just using a uart to communicate...
>
> --Sean
>
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-18 17:48 ` Sean Anderson
2020-02-18 19:26 ` Carlos Eduardo de Paula
@ 2020-02-19 8:50 ` Wladimir J. van der Laan
1 sibling, 0 replies; 89+ messages in thread
From: Wladimir J. van der Laan @ 2020-02-19 8:50 UTC (permalink / raw)
To: Sean Anderson
Cc: Carlos Eduardo de Paula, Anup Patel, Damien Le Moal,
Palmer Dabbelt, Paul Walmsley, linux-riscv
> > Wladimir (don't know his email) started playing with UART1 interface
> > to the 8285 module to allow WiFi communication. We thought about
> > having a TUN/TAP interface over it to bring the TCP/IP stack up.
> > https://twitter.com/orionwl/status/1229442145628585990
>
> Nice. I don't think too many raw register pokes should be needed,
> because you are just using a uart to communicate...
The reason I needed any raw register pokes at all is because I don't have a sysctl / fpioa driver, and didn't
feel like writing one at this time, so just write the appropriate values to the registers to map the UART1 to the
correct pins and enable WIFI_EN. After setting up those, Linux's driver works as-is for the UART!
Wladimir
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-18 19:26 ` Carlos Eduardo de Paula
@ 2020-02-19 9:06 ` Wladimir J. van der Laan
2020-02-19 22:28 ` Sean Anderson
2020-02-22 19:07 ` Wladimir J. van der Laan
0 siblings, 2 replies; 89+ messages in thread
From: Wladimir J. van der Laan @ 2020-02-19 9:06 UTC (permalink / raw)
To: Carlos Eduardo de Paula
Cc: Damien Le Moal, Anup Patel, Sean Anderson, Palmer Dabbelt,
Paul Walmsley, linux-riscv
On Tue, Feb 18, 2020 at 04:26:17PM -0300, Carlos Eduardo de Paula wrote:
> On Tue, Feb 18, 2020 at 2:48 PM Sean Anderson <seanga2@gmail.com> wrote:
> >
> > So the LCD connector is supposed to be for a ST7789V controller, but
> > there doesn't appear to be a driver in Linux for it. I don't have an
> > appropriate LCD screen, so I will not be able to write a driver.
> >
>
> Actually there is a driver and config DRM_PANEL_SITRONIX_ST7789V, in
> gpu/drm/panel/panel-sitronix-st7789v.c and also FB_TFT_ST7789V and
> CONFIG_FB_TFT_ST7789V with the driver a in
> staging/fbtft/fb_st7789v.c. Might be easier :)
>
> Weird that the Kendryte SDK refers to the LCD as NT35310
> (https://github.com/kendryte/kendryte-standalone-demo/tree/develop/lcd).
I remember checking the datasheet for both a while ago and NT35310 and ST7789V
seem to be more or less compatible, with only register differences
for more obscure functionality.
The more involved part is likely to adapt the spi-dw driver, apart from making the
ctrlr0 shifts configurable, there's the "OCTAL" mode that is used and extra
register that isn't set in the Linux driver (spi_ctrlr0 / 0xf4) concerning
"instruction address translation mode" and other things that needs to
be set correctly for LCD transfers to work.
> > There is no need for GPIOs. The datasheet shows SPI0 as hooked up to the
> > SD card, but the default pinconf doesn't have it hooked up. In addition,
> > the dedicated SPI0 data lines are already connected to the LCD. For
Yes - apparently only if you set sysctl spi_dvp_data_enable to route the
SPI0_0-7 pins to to the LCD data pins (bypassing FPIOA).
BTW speaking of which, does anyone know what's up with the K210's DMA
controller? It looks like it can only transfer 32-bit values from and to
peripherals? At least the kendryte-standalone-sdk goes to great lengths to
first allocate a 32-bit buffer then manually copy it to say, bytes or 16-bit
words. Seems quite a silly workaround with a lot of overhead.
Wladimir
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-19 9:06 ` Wladimir J. van der Laan
@ 2020-02-19 22:28 ` Sean Anderson
2020-02-20 10:48 ` Wladimir J. van der Laan
2020-02-22 19:07 ` Wladimir J. van der Laan
1 sibling, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-19 22:28 UTC (permalink / raw)
To: Wladimir J. van der Laan, Carlos Eduardo de Paula
Cc: Damien Le Moal, Anup Patel, Palmer Dabbelt, linux-riscv, Paul Walmsley
On 2/19/20 4:06 AM, Wladimir J. van der Laan wrote:
> On Tue, Feb 18, 2020 at 04:26:17PM -0300, Carlos Eduardo de Paula wrote:
>> On Tue, Feb 18, 2020 at 2:48 PM Sean Anderson <seanga2@gmail.com> wrote:
>>>
>>> So the LCD connector is supposed to be for a ST7789V controller, but
>>> there doesn't appear to be a driver in Linux for it. I don't have an
>>> appropriate LCD screen, so I will not be able to write a driver.
>>>
>>
>> Actually there is a driver and config DRM_PANEL_SITRONIX_ST7789V, in
>> gpu/drm/panel/panel-sitronix-st7789v.c and also FB_TFT_ST7789V and
>> CONFIG_FB_TFT_ST7789V with the driver a in
>> staging/fbtft/fb_st7789v.c. Might be easier :)
Ah, I didn't notice that, thanks.
>>
>> Weird that the Kendryte SDK refers to the LCD as NT35310
>> (https://github.com/kendryte/kendryte-standalone-demo/tree/develop/lcd).
>
> I remember checking the datasheet for both a while ago and NT35310 and ST7789V
> seem to be more or less compatible, with only register differences
> for more obscure functionality.
>
> The more involved part is likely to adapt the spi-dw driver, apart from making the
> ctrlr0 shifts configurable, there's the "OCTAL" mode that is used and extra
> register that isn't set in the Linux driver (spi_ctrlr0 / 0xf4) concerning
> "instruction address translation mode" and other things that needs to
> be set correctly for LCD transfers to work.
>
>>> There is no need for GPIOs. The datasheet shows SPI0 as hooked up to the
>>> SD card, but the default pinconf doesn't have it hooked up. In addition,
>>> the dedicated SPI0 data lines are already connected to the LCD. For
>
> Yes - apparently only if you set sysctl spi_dvp_data_enable to route the
> SPI0_0-7 pins to to the LCD data pins (bypassing FPIOA).
>
> BTW speaking of which, does anyone know what's up with the K210's DMA
> controller? It looks like it can only transfer 32-bit values from and to
> peripherals? At least the kendryte-standalone-sdk goes to great lengths to
> first allocate a 32-bit buffer then manually copy it to say, bytes or 16-bit
> words. Seems quite a silly workaround with a lot of overhead.
Do you have a link to that section?
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 01/10] riscv: Fix gitignore
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
@ 2020-02-20 0:15 ` Palmer Dabbelt
0 siblings, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-02-20 0:15 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:23 PST (-0800), Damien Le Moal wrote:
> Tell git to not track the compiled boot/loader and boot/loader.lds
> files.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/boot/.gitignore | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/boot/.gitignore b/arch/riscv/boot/.gitignore
> index 8dab0bb6ae66..8a45a37d2af4 100644
> --- a/arch/riscv/boot/.gitignore
> +++ b/arch/riscv/boot/.gitignore
> @@ -1,2 +1,4 @@
> Image
> Image.gz
> +loader
> +loader.lds
I've taken this into fixes. Thanks!
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-19 22:28 ` Sean Anderson
@ 2020-02-20 10:48 ` Wladimir J. van der Laan
0 siblings, 0 replies; 89+ messages in thread
From: Wladimir J. van der Laan @ 2020-02-20 10:48 UTC (permalink / raw)
To: Sean Anderson
Cc: Carlos Eduardo de Paula, Anup Patel, Damien Le Moal,
Palmer Dabbelt, Paul Walmsley, linux-riscv
> > BTW speaking of which, does anyone know what's up with the K210's DMA
> > controller? It looks like it can only transfer 32-bit values from and to
> > peripherals? At least the kendryte-standalone-sdk goes to great lengths to
> > first allocate a 32-bit buffer then manually copy it to say, bytes or 16-bit
> > words. Seems quite a silly workaround with a lot of overhead.
>
> Do you have a link to that section?
It's not really one section but all over the place in all clients of the DMA.
See for example the SPI here:
https://github.com/kendryte/kendryte-standalone-sdk/blob/develop/lib/drivers/spi.c#L372
Or serial (this one tripped me up):
https://github.com/kendryte/kendryte-standalone-sdk/blob/develop/lib/drivers/uart.c#L265
https://github.com/kendryte/kendryte-standalone-sdk/blob/develop/lib/drivers/uart.c#L163
One can fairly reliably find them by looking for 'malloc' in the drivers.
A few months back I did some experiments with different values for transfer
sizes and such and wasn't able to get the DMA controller to do this, myself.
The "FIX_CACHE" define is new, BTW. They don't DMA directly from/to cached
memory anymore but use an intermediate copy in uncached special I/O memory in
the 4xxxxxxx range. I haven't had problems with e.g. manually DMAing to the screen
through SPI myself but there might be a coherency edge case (their commit messages
are not exactly enlightening).
Kind regards,
Wladimir
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-19 9:06 ` Wladimir J. van der Laan
2020-02-19 22:28 ` Sean Anderson
@ 2020-02-22 19:07 ` Wladimir J. van der Laan
2020-04-01 17:55 ` Drew Fustini
1 sibling, 1 reply; 89+ messages in thread
From: Wladimir J. van der Laan @ 2020-02-22 19:07 UTC (permalink / raw)
To: Carlos Eduardo de Paula
Cc: Damien Le Moal, Anup Patel, Sean Anderson, Palmer Dabbelt,
Paul Walmsley, linux-riscv
> > > So the LCD connector is supposed to be for a ST7789V controller, but
> > > there doesn't appear to be a driver in Linux for it. I don't have an
> > > appropriate LCD screen, so I will not be able to write a driver.
> > >
> >
> > Actually there is a driver and config DRM_PANEL_SITRONIX_ST7789V, in
> > gpu/drm/panel/panel-sitronix-st7789v.c and also FB_TFT_ST7789V and
> > CONFIG_FB_TFT_ST7789V with the driver a in
> > staging/fbtft/fb_st7789v.c. Might be easier :)
> >
> > Weird that the Kendryte SDK refers to the LCD as NT35310
> > (https://github.com/kendryte/kendryte-standalone-demo/tree/develop/lcd).
>
> I remember checking the datasheet for both a while ago and NT35310 and ST7789V
> seem to be more or less compatible, with only register differences
> for more obscure functionality.
I just stumbled on this:
https://forum.kendryte.com/topic/68/a-guide-to-adapt-kendryte-kd233-kpu-demo-to-sipeed-m1
under "LCD Driver".
So it looks like the K233 uses a nt35310, while Sipeed M1 uses st7789. This is
a likely explanation for them mentioning both chips in the SDKs.
Kind regards,
Wladimir
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-17 13:28 ` Carlos Eduardo de Paula
@ 2020-02-26 21:31 ` Carlos Eduardo de Paula
2020-02-27 2:18 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Carlos Eduardo de Paula @ 2020-02-26 21:31 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
> >
> > >
> > > Thanks.
> > >
> >
> >
> > --
> > Damien Le Moal
> > Western Digital Research
>
I've integrated all required changes into a buildroot fork from your
repo where it's possible to build the complete image (Kernel + Patches
+ Busybox iniramfs) in a single place and there is no need to place
the toolchain outside, build the kernel and etc.
The changes are in https://github.com/carlosedp/riscv64-nommu-buildroot.
@Damien Le Moal I can send you a PR if you want.
Carlos
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-26 21:31 ` Carlos Eduardo de Paula
@ 2020-02-27 2:18 ` Damien Le Moal
0 siblings, 0 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-02-27 2:18 UTC (permalink / raw)
To: Carlos Eduardo de Paula
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/02/27 6:32, Carlos Eduardo de Paula wrote:
>>>
>>>>
>>>> Thanks.
>>>>
>>>
>>>
>>> --
>>> Damien Le Moal
>>> Western Digital Research
>>
>
> I've integrated all required changes into a buildroot fork from your
> repo where it's possible to build the complete image (Kernel + Patches
> + Busybox iniramfs) in a single place and there is no need to place
> the toolchain outside, build the kernel and etc.
>
> The changes are in https://github.com/carlosedp/riscv64-nommu-buildroot.
>
> @Damien Le Moal I can send you a PR if you want.
Yes, please do ! I need to prepare a v2 of the patchset. I can integrate the v2
patches with your fixes for everybody to test.
Thanks !
>
> Carlos
>
> --
> ________________________________________
> Carlos Eduardo de Paula
> me@carlosedp.com
> http://carlosedp.com
> http://twitter.com/carlosedp
> Linkedin
> ________________________________________
>
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-15 2:34 ` Damien Le Moal
2020-02-15 2:48 ` Sean Anderson
@ 2020-02-27 19:43 ` Sean Anderson
1 sibling, 0 replies; 89+ messages in thread
From: Sean Anderson @ 2020-02-27 19:43 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2/14/20 9:34 PM, Damien Le Moal wrote:
> On 2020/02/15 5:51, Sean Anderson wrote:
>> On 2/12/20 5:34 AM, Damien Le Moal wrote:
>>> + soc {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "kendryte,k210-soc", "simple-bus";
>>
>> Should the -soc suffix be here? I saw it was absent from the fu540
>> device tree.
>
> Yes, I guess it can be removed.
Actually, I think it is removed from the fu540 bits beccause sifive has
different names for the cores (rocket, U54, etc.) and the SoC (FU540).
Since for this chip there is no separate name, we should probably keep
the SoC suffix.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (10 preceding siblings ...)
2020-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
@ 2020-02-28 20:32 ` Sean Anderson
2020-03-02 3:01 ` Damien Le Moal
2020-03-04 19:44 ` Palmer Dabbelt
12 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-02-28 20:32 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
Hi,
When booting from U-Boot I get an OOM. Perhaps this is related to the
second cpu not coming up?
=> go 80000000
## Starting application at 0x80000000 ...
[ 0.000000] Linux version 5.6.0-rc1-00054-gd32122774dab (sean@godwin) (gcc version 9.2.0 (GCC)) #12 SMP Fri Feb 28 14:34:45 EST 2020
[ 0.000000] earlycon: sifive0 at MMIO 0x0000000038000000 (options '')
[ 0.000000] printk: bootconsole [sifive0] enabled
[ 0.000000] initrd not found or empty - disabling initrd
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000080000000-0x00000000807fffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080000000-0x00000000807fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000807fffff]
[ 0.000000] elf_hwcap is 0x112d
[ 0.000000] percpu: max_distance=0x18000 too large for vmalloc space 0x0
[ 0.000000] percpu: Embedded 12 pages/cpu s18272 r0 d30880 u49152
[ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020
[ 0.000000] Kernel command line: earlycon console=ttySIF0
[ 0.000000] Dentry cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.000000] Sorting __ex_table...
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 5528K/8192K available (918K kernel code, 106K rwdata, 166K rodata, 1129K init, 91K bss, 2664K reserved, 0K cma-reserved)
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[ 0.000000] plic: mapped 65 interrupts with 2 handlers for 4 contexts.
[ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
[ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x3990be68b, max_idle_ns: 881590404272 ns
[ 0.000015] sched_clock: 64 bits at 7MHz, resolution 128ns, wraps every 4398046511054ns
[ 0.008238] Console: colour dummy device 80x25
[ 0.012477] Calibrating delay loop (skipped), value calculated using timer frequency.. 15.60 BogoMIPS (lpj=31200)
[ 0.022684] pid_max: default: 4096 minimum: 301
[ 0.027302] Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.034423] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.044826] rcu: Hierarchical SRCU implementation.
[ 0.049623] smp: Bringing up secondary CPUs ...
[ 1.083970] CPU1: failed to come online
[ 1.087079] smp: Brought up 1 node, 1 CPU
[ 1.092006] devtmpfs: initialized
[ 1.098586] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 1.107609] futex hash table entries: 16 (order: -2, 1024 bytes, linear)
[ 1.115619] Kendryte K210 SoC sysctl
[ 1.129362] clocksource: Switched to clocksource riscv_clocksource
[ 1.385690] swapper/0: page allocation failure: order:9, mode:0x100cc2(GFP_HIGHUSER), nodemask=(null)
[ 1.394224] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc1-00054-gd32122774dab #12
[ 1.402129] Call Trace:
[ 1.404565] [<000000008011c2f2>] 0x000000008011c2f2
[ 1.409426] [<000000008011c436>] 0x000000008011c436
[ 1.414287] [<00000000801ed86e>] 0x00000000801ed86e
[ 1.419150] [<00000000801740c0>] 0x00000000801740c0
[ 1.424012] [<00000000801743d4>] 0x00000000801743d4
[ 1.428874] [<00000000801746da>] 0x00000000801746da
[ 1.433736] [<00000000801ababe>] 0x00000000801ababe
[ 1.438598] [<00000000801abbf2>] 0x00000000801abbf2
[ 1.443460] [<000000008018b06a>] 0x000000008018b06a
[ 1.448322] [<0000000080176de0>] 0x0000000080176de0
[ 1.453184] [<0000000080176fd2>] 0x0000000080176fd2
[ 1.458047] [<0000000080001b8a>] 0x0000000080001b8a
[ 1.462909] [<000000008000145a>] 0x000000008000145a
[ 1.467771] [<00000000800014b0>] 0x00000000800014b0
[ 1.472633] [<000000008000e7cc>] 0x000000008000e7cc
[ 1.477495] [<000000008000e80c>] 0x000000008000e80c
[ 1.482357] [<0000000080001e44>] 0x0000000080001e44
[ 1.487219] [<0000000080000a80>] 0x0000000080000a80
[ 1.492081] [<0000000080000ce4>] 0x0000000080000ce4
[ 1.496943] [<00000000801fd934>] 0x00000000801fd934
[ 1.501805] [<000000008011b304>] 0x000000008011b304
[ 1.506918] Mem-Info:
[ 1.508957] active_anon:0 inactive_anon:0 isolated_anon:0
[ 1.508957] active_file:0 inactive_file:0 isolated_file:0
[ 1.508957] unevictable:315 dirty:0 writeback:0 unstable:0
[ 1.508957] slab_reclaimable:0 slab_unreclaimable:215
[ 1.508957] mapped:0 shmem:0 pagetables:0 bounce:0
[ 1.508957] free:795 free_pcp:0 free_cma:0
[ 1.539593] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:1260kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[ 1.560939] DMA32 free:3180kB min:296kB low:368kB high:440kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:1260kB writepending:0kB present:8192kB managed:5528kB mlocked:0kB kernel_stack:168kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[ 1.588696] lowmem_reserve[]: 0 0 0
[ 1.592118] DMA32: 1*4kB (U) 1*8kB (M) 0*16kB 1*32kB (U) 1*64kB (U) 2*128kB (UM) 1*256kB (U) 1*512kB (M) 2*1024kB (UM) 0*2048kB 0*4096kB = 3180kB
[ 1.605162] 328 total pagecache pages
[ 1.608788] 2048 pages RAM
[ 1.611479] 0 pages HighMem/MovableOnly
[ 1.615299] 666 pages reserved
[ 1.743951] swapper/0 invoked oom-killer: gfp_mask=0x100cc2(GFP_HIGHUSER), order=0, oom_score_adj=0
[ 1.752280] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc1-00054-gd32122774dab #12
[ 1.760209] Call Trace:
[ 1.762645] [<000000008011c2f2>] 0x000000008011c2f2
[ 1.767506] [<000000008011c436>] 0x000000008011c436
[ 1.772368] [<00000000801ed86e>] 0x00000000801ed86e
[ 1.777230] [<00000000801634e2>] 0x00000000801634e2
[ 1.782092] [<00000000801633c6>] 0x00000000801633c6
[ 1.786954] [<000000008017451e>] 0x000000008017451e
[ 1.791816] [<00000000801746da>] 0x00000000801746da
[ 1.796678] [<0000000080161648>] 0x0000000080161648
[ 1.801540] [<000000008016241e>] 0x000000008016241e
[ 1.806402] [<0000000080192fc6>] 0x0000000080192fc6
[ 1.811264] [<00000000801624a6>] 0x00000000801624a6
[ 1.816127] [<000000008016262c>] 0x000000008016262c
[ 1.820989] [<000000008016267e>] 0x000000008016267e
[ 1.825851] [<0000000080178178>] 0x0000000080178178
[ 1.830713] [<00000000801781c0>] 0x00000000801781c0
[ 1.835575] [<0000000080178b5c>] 0x0000000080178b5c
[ 1.840437] [<0000000080178c82>] 0x0000000080178c82
[ 1.845299] [<0000000080001678>] 0x0000000080001678
[ 1.850161] [<0000000080001724>] 0x0000000080001724
[ 1.855023] [<000000008000145a>] 0x000000008000145a
[ 1.859885] [<00000000800014b0>] 0x00000000800014b0
[ 1.864748] [<000000008000e7cc>] 0x000000008000e7cc
[ 1.869609] [<000000008000e80c>] 0x000000008000e80c
[ 1.874472] [<0000000080001e44>] 0x0000000080001e44
[ 1.879334] [<0000000080000a80>] 0x0000000080000a80
[ 1.884196] [<0000000080000ce4>] 0x0000000080000ce4
[ 1.889058] [<00000000801fd934>] 0x00000000801fd934
[ 1.893920] [<000000008011b304>] 0x000000008011b304
[ 1.899086] Mem-Info:
[ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
[ 1.901072] active_file:0 inactive_file:0 isolated_file:0
[ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
[ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
[ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
[ 1.901072] free:417 free_pcp:0 free_cma:0
[ 1.931708] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:2820kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[ 1.953051] DMA32 free:1668kB min:4392kB low:4464kB high:4536kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:2820kB writepending:0kB present:8192kB managed:5528kB mlocked:0kB kernel_stack:168kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[ 1.981067] lowmem_reserve[]: 0 0 0
[ 1.984492] DMA32: 1*4kB (U) 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB (U) 0*256kB 1*512kB (U) 1*1024kB (U) 0*2048kB 0*4096kB = 1668kB
[ 1.995970] 704 total pagecache pages
[ 1.999599] 2048 pages RAM
[ 2.002291] 0 pages HighMem/MovableOnly
[ 2.006110] 666 pages reserved
[ 2.009131] Tasks state (memory values in pages):
[ 2.013848] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[ 2.022450] Out of memory and no killable processes...
[ 2.027562] Kernel panic - not syncing: System is deadlocked on memory
[ 2.034062] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc1-00054-gd32122774dab #12
[ 2.042036] Call Trace:
[ 2.044472] [<000000008011c2f2>] 0x000000008011c2f2
[ 2.049333] [<000000008011c436>] 0x000000008011c436
[ 2.054195] [<00000000801ed86e>] 0x00000000801ed86e
[ 2.059057] [<000000008011f4d8>] 0x000000008011f4d8
[ 2.063919] [<00000000801633ea>] 0x00000000801633ea
[ 2.068782] [<000000008017451e>] 0x000000008017451e
[ 2.073644] [<00000000801746da>] 0x00000000801746da
[ 2.078506] [<0000000080161648>] 0x0000000080161648
[ 2.083368] [<000000008016241e>] 0x000000008016241e
[ 2.088230] [<0000000080192fc6>] 0x0000000080192fc6
[ 2.093092] [<00000000801624a6>] 0x00000000801624a6
[ 2.097954] [<000000008016262c>] 0x000000008016262c
[ 2.102816] [<000000008016267e>] 0x000000008016267e
[ 2.107678] [<0000000080178178>] 0x0000000080178178
[ 2.112541] [<00000000801781c0>] 0x00000000801781c0
[ 2.117403] [<0000000080178b5c>] 0x0000000080178b5c
[ 2.122265] [<0000000080178c82>] 0x0000000080178c82
[ 2.127127] [<0000000080001678>] 0x0000000080001678
[ 2.131989] [<0000000080001724>] 0x0000000080001724
[ 2.136851] [<000000008000145a>] 0x000000008000145a
[ 2.141713] [<00000000800014b0>] 0x00000000800014b0
[ 2.146575] [<000000008000e7cc>] 0x000000008000e7cc
[ 2.151437] [<000000008000e80c>] 0x000000008000e80c
[ 2.156299] [<0000000080001e44>] 0x0000000080001e44
[ 2.161162] [<0000000080000a80>] 0x0000000080000a80
[ 2.166024] [<0000000080000ce4>] 0x0000000080000ce4
[ 2.170886] [<00000000801fd934>] 0x00000000801fd934
[ 2.175748] [<000000008011b304>] 0x000000008011b304
[ 2.180624] ---[ end Kernel panic - not syncing: System is deadlocked on memory ]---
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-28 20:32 ` Sean Anderson
@ 2020-03-02 3:01 ` Damien Le Moal
2020-03-02 3:53 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 3:01 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/02/29 5:32, Sean Anderson wrote:
> Hi,
>
> When booting from U-Boot I get an OOM. Perhaps this is related to the
> second cpu not coming up?
Unlikely. It looks like your user space needs 2MB per shell (order 9
allocation). Since you have only 5.5MB free, that may explain the allocation
failure (if init is forking another shell especially).
For the second core not coming up, an IPI needs to be sent to the non-boot core
to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
the kernel. I thought I had that in the kernel though. Will check again.
>
> => go 80000000
> ## Starting application at 0x80000000 ...
> [ 0.000000] Linux version 5.6.0-rc1-00054-gd32122774dab (sean@godwin) (gcc version 9.2.0 (GCC)) #12 SMP Fri Feb 28 14:34:45 EST 2020
> [ 0.000000] earlycon: sifive0 at MMIO 0x0000000038000000 (options '')
> [ 0.000000] printk: bootconsole [sifive0] enabled
> [ 0.000000] initrd not found or empty - disabling initrd
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] elf_hwcap is 0x112d
> [ 0.000000] percpu: max_distance=0x18000 too large for vmalloc space 0x0
> [ 0.000000] percpu: Embedded 12 pages/cpu s18272 r0 d30880 u49152
> [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020
> [ 0.000000] Kernel command line: earlycon console=ttySIF0
> [ 0.000000] Dentry cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.000000] Sorting __ex_table...
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] Memory: 5528K/8192K available (918K kernel code, 106K rwdata, 166K rodata, 1129K init, 91K bss, 2664K reserved, 0K cma-reserved)
> [ 0.000000] rcu: Hierarchical RCU implementation.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
> [ 0.000000] plic: mapped 65 interrupts with 2 handlers for 4 contexts.
> [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
> [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x3990be68b, max_idle_ns: 881590404272 ns
> [ 0.000015] sched_clock: 64 bits at 7MHz, resolution 128ns, wraps every 4398046511054ns
> [ 0.008238] Console: colour dummy device 80x25
> [ 0.012477] Calibrating delay loop (skipped), value calculated using timer frequency.. 15.60 BogoMIPS (lpj=31200)
> [ 0.022684] pid_max: default: 4096 minimum: 301
> [ 0.027302] Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.034423] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.044826] rcu: Hierarchical SRCU implementation.
> [ 0.049623] smp: Bringing up secondary CPUs ...
> [ 1.083970] CPU1: failed to come online
> [ 1.087079] smp: Brought up 1 node, 1 CPU
> [ 1.092006] devtmpfs: initialized
> [ 1.098586] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 1.107609] futex hash table entries: 16 (order: -2, 1024 bytes, linear)
> [ 1.115619] Kendryte K210 SoC sysctl
> [ 1.129362] clocksource: Switched to clocksource riscv_clocksource
> [ 1.385690] swapper/0: page allocation failure: order:9, mode:0x100cc2(GFP_HIGHUSER), nodemask=(null)
> [ 1.394224] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc1-00054-gd32122774dab #12
> [ 1.402129] Call Trace:
> [ 1.404565] [<000000008011c2f2>] 0x000000008011c2f2
> [ 1.409426] [<000000008011c436>] 0x000000008011c436
> [ 1.414287] [<00000000801ed86e>] 0x00000000801ed86e
> [ 1.419150] [<00000000801740c0>] 0x00000000801740c0
> [ 1.424012] [<00000000801743d4>] 0x00000000801743d4
> [ 1.428874] [<00000000801746da>] 0x00000000801746da
> [ 1.433736] [<00000000801ababe>] 0x00000000801ababe
> [ 1.438598] [<00000000801abbf2>] 0x00000000801abbf2
> [ 1.443460] [<000000008018b06a>] 0x000000008018b06a
> [ 1.448322] [<0000000080176de0>] 0x0000000080176de0
> [ 1.453184] [<0000000080176fd2>] 0x0000000080176fd2
> [ 1.458047] [<0000000080001b8a>] 0x0000000080001b8a
> [ 1.462909] [<000000008000145a>] 0x000000008000145a
> [ 1.467771] [<00000000800014b0>] 0x00000000800014b0
> [ 1.472633] [<000000008000e7cc>] 0x000000008000e7cc
> [ 1.477495] [<000000008000e80c>] 0x000000008000e80c
> [ 1.482357] [<0000000080001e44>] 0x0000000080001e44
> [ 1.487219] [<0000000080000a80>] 0x0000000080000a80
> [ 1.492081] [<0000000080000ce4>] 0x0000000080000ce4
> [ 1.496943] [<00000000801fd934>] 0x00000000801fd934
> [ 1.501805] [<000000008011b304>] 0x000000008011b304
> [ 1.506918] Mem-Info:
> [ 1.508957] active_anon:0 inactive_anon:0 isolated_anon:0
> [ 1.508957] active_file:0 inactive_file:0 isolated_file:0
> [ 1.508957] unevictable:315 dirty:0 writeback:0 unstable:0
> [ 1.508957] slab_reclaimable:0 slab_unreclaimable:215
> [ 1.508957] mapped:0 shmem:0 pagetables:0 bounce:0
> [ 1.508957] free:795 free_pcp:0 free_cma:0
> [ 1.539593] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:1260kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> [ 1.560939] DMA32 free:3180kB min:296kB low:368kB high:440kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:1260kB writepending:0kB present:8192kB managed:5528kB mlocked:0kB kernel_stack:168kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [ 1.588696] lowmem_reserve[]: 0 0 0
> [ 1.592118] DMA32: 1*4kB (U) 1*8kB (M) 0*16kB 1*32kB (U) 1*64kB (U) 2*128kB (UM) 1*256kB (U) 1*512kB (M) 2*1024kB (UM) 0*2048kB 0*4096kB = 3180kB
> [ 1.605162] 328 total pagecache pages
> [ 1.608788] 2048 pages RAM
> [ 1.611479] 0 pages HighMem/MovableOnly
> [ 1.615299] 666 pages reserved
> [ 1.743951] swapper/0 invoked oom-killer: gfp_mask=0x100cc2(GFP_HIGHUSER), order=0, oom_score_adj=0
> [ 1.752280] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc1-00054-gd32122774dab #12
> [ 1.760209] Call Trace:
> [ 1.762645] [<000000008011c2f2>] 0x000000008011c2f2
> [ 1.767506] [<000000008011c436>] 0x000000008011c436
> [ 1.772368] [<00000000801ed86e>] 0x00000000801ed86e
> [ 1.777230] [<00000000801634e2>] 0x00000000801634e2
> [ 1.782092] [<00000000801633c6>] 0x00000000801633c6
> [ 1.786954] [<000000008017451e>] 0x000000008017451e
> [ 1.791816] [<00000000801746da>] 0x00000000801746da
> [ 1.796678] [<0000000080161648>] 0x0000000080161648
> [ 1.801540] [<000000008016241e>] 0x000000008016241e
> [ 1.806402] [<0000000080192fc6>] 0x0000000080192fc6
> [ 1.811264] [<00000000801624a6>] 0x00000000801624a6
> [ 1.816127] [<000000008016262c>] 0x000000008016262c
> [ 1.820989] [<000000008016267e>] 0x000000008016267e
> [ 1.825851] [<0000000080178178>] 0x0000000080178178
> [ 1.830713] [<00000000801781c0>] 0x00000000801781c0
> [ 1.835575] [<0000000080178b5c>] 0x0000000080178b5c
> [ 1.840437] [<0000000080178c82>] 0x0000000080178c82
> [ 1.845299] [<0000000080001678>] 0x0000000080001678
> [ 1.850161] [<0000000080001724>] 0x0000000080001724
> [ 1.855023] [<000000008000145a>] 0x000000008000145a
> [ 1.859885] [<00000000800014b0>] 0x00000000800014b0
> [ 1.864748] [<000000008000e7cc>] 0x000000008000e7cc
> [ 1.869609] [<000000008000e80c>] 0x000000008000e80c
> [ 1.874472] [<0000000080001e44>] 0x0000000080001e44
> [ 1.879334] [<0000000080000a80>] 0x0000000080000a80
> [ 1.884196] [<0000000080000ce4>] 0x0000000080000ce4
> [ 1.889058] [<00000000801fd934>] 0x00000000801fd934
> [ 1.893920] [<000000008011b304>] 0x000000008011b304
> [ 1.899086] Mem-Info:
> [ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
> [ 1.901072] active_file:0 inactive_file:0 isolated_file:0
> [ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
> [ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
> [ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
> [ 1.901072] free:417 free_pcp:0 free_cma:0
> [ 1.931708] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:2820kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> [ 1.953051] DMA32 free:1668kB min:4392kB low:4464kB high:4536kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:2820kB writepending:0kB present:8192kB managed:5528kB mlocked:0kB kernel_stack:168kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [ 1.981067] lowmem_reserve[]: 0 0 0
> [ 1.984492] DMA32: 1*4kB (U) 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB (U) 0*256kB 1*512kB (U) 1*1024kB (U) 0*2048kB 0*4096kB = 1668kB
> [ 1.995970] 704 total pagecache pages
> [ 1.999599] 2048 pages RAM
> [ 2.002291] 0 pages HighMem/MovableOnly
> [ 2.006110] 666 pages reserved
> [ 2.009131] Tasks state (memory values in pages):
> [ 2.013848] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
> [ 2.022450] Out of memory and no killable processes...
> [ 2.027562] Kernel panic - not syncing: System is deadlocked on memory
> [ 2.034062] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc1-00054-gd32122774dab #12
> [ 2.042036] Call Trace:
> [ 2.044472] [<000000008011c2f2>] 0x000000008011c2f2
> [ 2.049333] [<000000008011c436>] 0x000000008011c436
> [ 2.054195] [<00000000801ed86e>] 0x00000000801ed86e
> [ 2.059057] [<000000008011f4d8>] 0x000000008011f4d8
> [ 2.063919] [<00000000801633ea>] 0x00000000801633ea
> [ 2.068782] [<000000008017451e>] 0x000000008017451e
> [ 2.073644] [<00000000801746da>] 0x00000000801746da
> [ 2.078506] [<0000000080161648>] 0x0000000080161648
> [ 2.083368] [<000000008016241e>] 0x000000008016241e
> [ 2.088230] [<0000000080192fc6>] 0x0000000080192fc6
> [ 2.093092] [<00000000801624a6>] 0x00000000801624a6
> [ 2.097954] [<000000008016262c>] 0x000000008016262c
> [ 2.102816] [<000000008016267e>] 0x000000008016267e
> [ 2.107678] [<0000000080178178>] 0x0000000080178178
> [ 2.112541] [<00000000801781c0>] 0x00000000801781c0
> [ 2.117403] [<0000000080178b5c>] 0x0000000080178b5c
> [ 2.122265] [<0000000080178c82>] 0x0000000080178c82
> [ 2.127127] [<0000000080001678>] 0x0000000080001678
> [ 2.131989] [<0000000080001724>] 0x0000000080001724
> [ 2.136851] [<000000008000145a>] 0x000000008000145a
> [ 2.141713] [<00000000800014b0>] 0x00000000800014b0
> [ 2.146575] [<000000008000e7cc>] 0x000000008000e7cc
> [ 2.151437] [<000000008000e80c>] 0x000000008000e80c
> [ 2.156299] [<0000000080001e44>] 0x0000000080001e44
> [ 2.161162] [<0000000080000a80>] 0x0000000080000a80
> [ 2.166024] [<0000000080000ce4>] 0x0000000080000ce4
> [ 2.170886] [<00000000801fd934>] 0x00000000801fd934
> [ 2.175748] [<000000008011b304>] 0x000000008011b304
> [ 2.180624] ---[ end Kernel panic - not syncing: System is deadlocked on memory ]---
>
>
>
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
2020-02-14 20:18 ` Sean Anderson
@ 2020-03-02 3:48 ` Anup Patel
2020-03-04 18:38 ` Palmer Dabbelt
2 siblings, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 3:48 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:04 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
> a nommu kernel. Since the sparsemem model does not make sense anyway
> for the nommu case, do not allow selecting this option to always use
> the flatmem model.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
LGTM.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> arch/riscv/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 73f029eae0cc..1a3b5a5276be 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>
> config ARCH_SPARSEMEM_ENABLE
> def_bool y
> + depends on MMU
> select SPARSEMEM_VMEMMAP_ENABLE
>
> config ARCH_SELECT_MEMORY_MODEL
> --
> 2.24.1
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 3:01 ` Damien Le Moal
@ 2020-03-02 3:53 ` Sean Anderson
2020-03-02 4:11 ` Damien Le Moal
2020-03-02 4:17 ` Anup Patel
0 siblings, 2 replies; 89+ messages in thread
From: Sean Anderson @ 2020-03-02 3:53 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 3/1/20 10:01 PM, Damien Le Moal wrote:
> On 2020/02/29 5:32, Sean Anderson wrote:
>> Hi,
>>
>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>> second cpu not coming up?
>
> Unlikely. It looks like your user space needs 2MB per shell (order 9
> allocation). Since you have only 5.5MB free, that may explain the allocation
> failure (if init is forking another shell especially).
This should be before init comes up; when comparing this to your syslog
output there are several more messages before init gets started.
> For the second core not coming up, an IPI needs to be sent to the non-boot core
> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
> the kernel. I thought I had that in the kernel though. Will check again.
I think it's a RISC-V thing. I should have U-Boot set up to start linux
on both cores, but something may be misconfigured on that end.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
@ 2020-03-02 3:57 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 3:57 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:04 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add handlers for unaligned load and stroe traps that may be generated
> by applications. Code heavily inspired from the OpenSBI project.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> ---
> arch/riscv/kernel/Makefile | 2 +-
> arch/riscv/kernel/traps.c | 27 +-
> arch/riscv/kernel/traps_misaligned.c | 371 +++++++++++++++++++++++++++
> 3 files changed, 396 insertions(+), 4 deletions(-)
> create mode 100644 arch/riscv/kernel/traps_misaligned.c
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index f40205cb9a22..97d0c35f8b37 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -28,7 +28,7 @@ obj-y += stacktrace.o
> obj-y += cacheinfo.o
> obj-$(CONFIG_MMU) += vdso.o vdso/
>
> -obj-$(CONFIG_RISCV_M_MODE) += clint.o
> +obj-$(CONFIG_RISCV_M_MODE) += clint.o traps_misaligned.o
> obj-$(CONFIG_FPU) += fpu.o
> obj-$(CONFIG_SMP) += smpboot.o
> obj-$(CONFIG_SMP) += smp.o
> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> index ffb3d94bf0cc..13e55459d7b0 100644
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -97,12 +97,33 @@ DO_ERROR_INFO(do_trap_insn_fault,
> SIGSEGV, SEGV_ACCERR, "instruction access fault");
> DO_ERROR_INFO(do_trap_insn_illegal,
> SIGILL, ILL_ILLOPC, "illegal instruction");
> -DO_ERROR_INFO(do_trap_load_misaligned,
> - SIGBUS, BUS_ADRALN, "load address misaligned");
> DO_ERROR_INFO(do_trap_load_fault,
> SIGSEGV, SEGV_ACCERR, "load access fault");
> +#ifndef CONFIG_RISCV_M_MODE
> +DO_ERROR_INFO(do_trap_load_misaligned,
> + SIGBUS, BUS_ADRALN, "Oops - load address misaligned");
> DO_ERROR_INFO(do_trap_store_misaligned,
> - SIGBUS, BUS_ADRALN, "store (or AMO) address misaligned");
> + SIGBUS, BUS_ADRALN, "Oops - store (or AMO) address misaligned");
> +#else
> +int handle_misaligned_load(struct pt_regs *regs);
> +int handle_misaligned_store(struct pt_regs *regs);
> +
> +asmlinkage void do_trap_load_misaligned(struct pt_regs *regs)
> +{
> + if (!handle_misaligned_load(regs))
> + return;
> + do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> + "Oops - load address misaligned");
> +}
> +
> +asmlinkage void do_trap_store_misaligned(struct pt_regs *regs)
> +{
> + if (!handle_misaligned_store(regs))
> + return;
> + do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> + "Oops - store (or AMO) address misaligned");
> +}
> +#endif
> DO_ERROR_INFO(do_trap_store_fault,
> SIGSEGV, SEGV_ACCERR, "store (or AMO) access fault");
> DO_ERROR_INFO(do_trap_ecall_u,
> diff --git a/arch/riscv/kernel/traps_misaligned.c b/arch/riscv/kernel/traps_misaligned.c
> new file mode 100644
> index 000000000000..a6105ee0150f
> --- /dev/null
> +++ b/arch/riscv/kernel/traps_misaligned.c
> @@ -0,0 +1,371 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/mm.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +
> +#include <asm/processor.h>
> +#include <asm/ptrace.h>
> +#include <asm/csr.h>
> +
> +#define INSN_MATCH_LB 0x3
> +#define INSN_MASK_LB 0x707f
> +#define INSN_MATCH_LH 0x1003
> +#define INSN_MASK_LH 0x707f
> +#define INSN_MATCH_LW 0x2003
> +#define INSN_MASK_LW 0x707f
> +#define INSN_MATCH_LD 0x3003
> +#define INSN_MASK_LD 0x707f
> +#define INSN_MATCH_LBU 0x4003
> +#define INSN_MASK_LBU 0x707f
> +#define INSN_MATCH_LHU 0x5003
> +#define INSN_MASK_LHU 0x707f
> +#define INSN_MATCH_LWU 0x6003
> +#define INSN_MASK_LWU 0x707f
> +#define INSN_MATCH_SB 0x23
> +#define INSN_MASK_SB 0x707f
> +#define INSN_MATCH_SH 0x1023
> +#define INSN_MASK_SH 0x707f
> +#define INSN_MATCH_SW 0x2023
> +#define INSN_MASK_SW 0x707f
> +#define INSN_MATCH_SD 0x3023
> +#define INSN_MASK_SD 0x707f
> +
> +#define INSN_MATCH_FLW 0x2007
> +#define INSN_MASK_FLW 0x707f
> +#define INSN_MATCH_FLD 0x3007
> +#define INSN_MASK_FLD 0x707f
> +#define INSN_MATCH_FLQ 0x4007
> +#define INSN_MASK_FLQ 0x707f
> +#define INSN_MATCH_FSW 0x2027
> +#define INSN_MASK_FSW 0x707f
> +#define INSN_MATCH_FSD 0x3027
> +#define INSN_MASK_FSD 0x707f
> +#define INSN_MATCH_FSQ 0x4027
> +#define INSN_MASK_FSQ 0x707f
> +
> +#define INSN_MATCH_C_LD 0x6000
> +#define INSN_MASK_C_LD 0xe003
> +#define INSN_MATCH_C_SD 0xe000
> +#define INSN_MASK_C_SD 0xe003
> +#define INSN_MATCH_C_LW 0x4000
> +#define INSN_MASK_C_LW 0xe003
> +#define INSN_MATCH_C_SW 0xc000
> +#define INSN_MASK_C_SW 0xe003
> +#define INSN_MATCH_C_LDSP 0x6002
> +#define INSN_MASK_C_LDSP 0xe003
> +#define INSN_MATCH_C_SDSP 0xe002
> +#define INSN_MASK_C_SDSP 0xe003
> +#define INSN_MATCH_C_LWSP 0x4002
> +#define INSN_MASK_C_LWSP 0xe003
> +#define INSN_MATCH_C_SWSP 0xc002
> +#define INSN_MASK_C_SWSP 0xe003
> +
> +#define INSN_MATCH_C_FLD 0x2000
> +#define INSN_MASK_C_FLD 0xe003
> +#define INSN_MATCH_C_FLW 0x6000
> +#define INSN_MASK_C_FLW 0xe003
> +#define INSN_MATCH_C_FSD 0xa000
> +#define INSN_MASK_C_FSD 0xe003
> +#define INSN_MATCH_C_FSW 0xe000
> +#define INSN_MASK_C_FSW 0xe003
> +#define INSN_MATCH_C_FLDSP 0x2002
> +#define INSN_MASK_C_FLDSP 0xe003
> +#define INSN_MATCH_C_FSDSP 0xa002
> +#define INSN_MASK_C_FSDSP 0xe003
> +#define INSN_MATCH_C_FLWSP 0x6002
> +#define INSN_MASK_C_FLWSP 0xe003
> +#define INSN_MATCH_C_FSWSP 0xe002
> +#define INSN_MASK_C_FSWSP 0xe003
> +
> +#define INSN_LEN(insn) ((((insn) & 0x3) < 0x3) ? 2 : 4)
> +
> +#if __riscv_xlen == 64
Prefer, "#if defined(CONFIG_64BIT)" instead of "#if __riscv_xlen" so
that build is dependent more on kernel config and less on compiler.
> +#define LOG_REGBYTES 3
> +#else
> +#define LOG_REGBYTES 2
> +#endif
> +#define REGBYTES (1 << LOG_REGBYTES)
> +
> +#define SH_RD 7
> +#define SH_RS1 15
> +#define SH_RS2 20
> +#define SH_RS2C 2
> +
> +#define RV_X(x, s, n) (((x) >> (s)) & ((1 << (n)) - 1))
> +#define RVC_LW_IMM(x) ((RV_X(x, 6, 1) << 2) | \
> + (RV_X(x, 10, 3) << 3) | \
> + (RV_X(x, 5, 1) << 6))
> +#define RVC_LD_IMM(x) ((RV_X(x, 10, 3) << 3) | \
> + (RV_X(x, 5, 2) << 6))
> +#define RVC_LWSP_IMM(x) ((RV_X(x, 4, 3) << 2) | \
> + (RV_X(x, 12, 1) << 5) | \
> + (RV_X(x, 2, 2) << 6))
> +#define RVC_LDSP_IMM(x) ((RV_X(x, 5, 2) << 3) | \
> + (RV_X(x, 12, 1) << 5) | \
> + (RV_X(x, 2, 3) << 6))
> +#define RVC_SWSP_IMM(x) ((RV_X(x, 9, 4) << 2) | \
> + (RV_X(x, 7, 2) << 6))
> +#define RVC_SDSP_IMM(x) ((RV_X(x, 10, 3) << 3) | \
> + (RV_X(x, 7, 3) << 6))
> +#define RVC_RS1S(insn) (8 + RV_X(insn, SH_RD, 3))
> +#define RVC_RS2S(insn) (8 + RV_X(insn, SH_RS2C, 3))
> +#define RVC_RS2(insn) RV_X(insn, SH_RS2C, 5)
> +
> +#define SHIFT_RIGHT(x, y) \
> + ((y) < 0 ? ((x) << -(y)) : ((x) >> (y)))
> +
> +#define REG_MASK \
> + ((1 << (5 + LOG_REGBYTES)) - (1 << LOG_REGBYTES))
> +
> +#define REG_OFFSET(insn, pos) \
> + (SHIFT_RIGHT((insn), (pos) - LOG_REGBYTES) & REG_MASK)
> +
> +#define REG_PTR(insn, pos, regs) \
> + (ulong *)((ulong)(regs) + REG_OFFSET(insn, pos))
> +
> +#define GET_RM(insn) (((insn) >> 12) & 7)
> +
> +#define GET_RS1(insn, regs) (*REG_PTR(insn, SH_RS1, regs))
> +#define GET_RS2(insn, regs) (*REG_PTR(insn, SH_RS2, regs))
> +#define GET_RS1S(insn, regs) (*REG_PTR(RVC_RS1S(insn), 0, regs))
> +#define GET_RS2S(insn, regs) (*REG_PTR(RVC_RS2S(insn), 0, regs))
> +#define GET_RS2C(insn, regs) (*REG_PTR(insn, SH_RS2C, regs))
> +#define GET_SP(regs) (*REG_PTR(2, 0, regs))
> +#define SET_RD(insn, regs, val) (*REG_PTR(insn, SH_RD, regs) = (val))
> +#define IMM_I(insn) ((s32)(insn) >> 20)
> +#define IMM_S(insn) (((s32)(insn) >> 25 << 5) | \
> + (s32)(((insn) >> 7) & 0x1f))
> +#define MASK_FUNCT3 0x7000
> +
> +#define GET_PRECISION(insn) (((insn) >> 25) & 3)
> +#define GET_RM(insn) (((insn) >> 12) & 7)
> +#define PRECISION_S 0
> +#define PRECISION_D 1
> +
> +#define STR(x) XSTR(x)
> +#define XSTR(x) #x
> +
> +#define DECLARE_UNPRIVILEGED_LOAD_FUNCTION(type, insn) \
> +static inline type load_##type(const type *addr) \
> +{ \
> + type val; \
> + asm (#insn " %0, %1" \
> + : "=&r" (val) : "m" (*addr)); \
> + return val; \
> +}
> +
> +#define DECLARE_UNPRIVILEGED_STORE_FUNCTION(type, insn) \
> +static inline void store_##type(type *addr, type val) \
> +{ \
> + asm volatile (#insn " %0, %1\n" \
> + : : "r" (val), "m" (*addr)); \
> +}
> +
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u8, lbu)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u16, lhu)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s8, lb)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s16, lh)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s32, lw)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u8, sb)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u16, sh)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u32, sw)
> +#if __riscv_xlen == 64
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u32, lwu)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u64, ld)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u64, sd)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(ulong, ld)
> +#else
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u32, lw)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(ulong, lw)
> +
> +static inline u64 load_u64(const u64 *addr)
> +{
> + return load_u32((u32 *)addr)
> + + ((u64)load_u32((u32 *)addr + 1) << 32);
> +}
> +
> +static inline void store_u64(u64 *addr, u64 val)
> +{
> + store_u32((u32 *)addr, val);
> + store_u32((u32 *)addr + 1, val >> 32);
> +}
> +#endif
> +
> +static inline ulong get_insn(ulong mepc)
> +{
> + register ulong __mepc asm ("a2") = mepc;
> + ulong val, rvc_mask = 3, tmp;
> +
> + asm ("and %[tmp], %[addr], 2\n"
> + "bnez %[tmp], 1f\n"
> +#if __riscv_xlen == 64
Same as above.
> + STR(LWU) " %[insn], (%[addr])\n"
> +#else
> + STR(LW) " %[insn], (%[addr])\n"
> +#endif
> + "and %[tmp], %[insn], %[rvc_mask]\n"
> + "beq %[tmp], %[rvc_mask], 2f\n"
> + "sll %[insn], %[insn], %[xlen_minus_16]\n"
> + "srl %[insn], %[insn], %[xlen_minus_16]\n"
> + "j 2f\n"
> + "1:\n"
> + "lhu %[insn], (%[addr])\n"
> + "and %[tmp], %[insn], %[rvc_mask]\n"
> + "bne %[tmp], %[rvc_mask], 2f\n"
> + "lhu %[tmp], 2(%[addr])\n"
> + "sll %[tmp], %[tmp], 16\n"
> + "add %[insn], %[insn], %[tmp]\n"
> + "2:"
> + : [insn] "=&r" (val), [tmp] "=&r" (tmp)
> + : [addr] "r" (__mepc), [rvc_mask] "r" (rvc_mask),
> + [xlen_minus_16] "i" (__riscv_xlen - 16));
> +
> + return val;
> +}
> +
> +union reg_data {
> + u8 data_bytes[8];
> + ulong data_ulong;
> + u64 data_u64;
> +};
> +
> +int handle_misaligned_load(struct pt_regs *regs)
> +{
> + union reg_data val;
> + unsigned long epc = regs->epc;
> + unsigned long insn = get_insn(epc);
> + unsigned long addr = csr_read(mtval);
> + int i, fp = 0, shift = 0, len = 0;
> +
> + regs->epc = 0;
> +
> + if ((insn & INSN_MASK_LW) == INSN_MATCH_LW) {
> + len = 4;
> + shift = 8 * (sizeof(unsigned long) - len);
> +#if __riscv_xlen == 64
Same as above.
> + } else if ((insn & INSN_MASK_LD) == INSN_MATCH_LD) {
> + len = 8;
> + shift = 8 * (sizeof(unsigned long) - len);
> + } else if ((insn & INSN_MASK_LWU) == INSN_MATCH_LWU) {
> + len = 4;
> +#endif
> + } else if ((insn & INSN_MASK_FLD) == INSN_MATCH_FLD) {
> + fp = 1;
> + len = 8;
> + } else if ((insn & INSN_MASK_FLW) == INSN_MATCH_FLW) {
> + fp = 1;
> + len = 4;
> + } else if ((insn & INSN_MASK_LH) == INSN_MATCH_LH) {
> + len = 2;
> + shift = 8 * (sizeof(unsigned long) - len);
> + } else if ((insn & INSN_MASK_LHU) == INSN_MATCH_LHU) {
> + len = 2;
> +#ifdef __riscv_compressed
Instead of "#ifdef __riscv_compressed" prefer "#if defined(CONFIG_RISCV_ISA_C)"
> +#if __riscv_xlen >= 64
Prefer, "#if defined(CONFIG_64BIT)" instead of "#if __riscv_xlen" so
that build is dependent more on kernel config and less on compiler.
> + } else if ((insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD) {
> + len = 8;
> + shift = 8 * (sizeof(unsigned long) - len);
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 8;
> + shift = 8 * (sizeof(unsigned long) - len);
> +#endif
> + } else if ((insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW) {
> + len = 4;
> + shift = 8 * (sizeof(unsigned long) - len);
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 4;
> + shift = 8 * (sizeof(unsigned long) - len);
> + } else if ((insn & INSN_MASK_C_FLD) == INSN_MATCH_C_FLD) {
> + fp = 1;
> + len = 8;
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_FLDSP) == INSN_MATCH_C_FLDSP) {
> + fp = 1;
> + len = 8;
> +#if __riscv_xlen == 32
Same as above.
> + } else if ((insn & INSN_MASK_C_FLW) == INSN_MATCH_C_FLW) {
> + fp = 1;
> + len = 4;
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_FLWSP) == INSN_MATCH_C_FLWSP) {
> + fp = 1;
> + len = 4;
> +#endif
> +#endif
> + } else {
> + regs->epc = epc;
> + return -1;
> + }
> +
> + val.data_u64 = 0;
> + for (i = 0; i < len; i++)
> + val.data_bytes[i] = load_u8((void *)(addr + i));
> +
> + if (fp)
> + return -1;
> + SET_RD(insn, regs, val.data_ulong << shift >> shift);
> +
> + regs->epc = epc + INSN_LEN(insn);
> +
> + return 0;
> +}
> +
> +int handle_misaligned_store(struct pt_regs *regs)
> +{
> + union reg_data val;
> + unsigned long epc = regs->epc;
> + unsigned long insn = get_insn(epc);
> + unsigned long addr = csr_read(mtval);
> + int i, len = 0;
> +
> + regs->epc = 0;
> +
> + val.data_ulong = GET_RS2(insn, regs);
> +
> + if ((insn & INSN_MASK_SW) == INSN_MATCH_SW) {
> + len = 4;
> +#if __riscv_xlen == 64
Same as above.
> + } else if ((insn & INSN_MASK_SD) == INSN_MATCH_SD) {
> + len = 8;
> +#endif
> + } else if ((insn & INSN_MASK_SH) == INSN_MATCH_SH) {
> + len = 2;
> +#ifdef __riscv_compressed
> +#if __riscv_xlen >= 64
Same as above
> + } else if ((insn & INSN_MASK_C_SD) == INSN_MATCH_C_SD) {
> + len = 8;
> + val.data_ulong = GET_RS2S(insn, regs);
> + } else if ((insn & INSN_MASK_C_SDSP) == INSN_MATCH_C_SDSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 8;
> + val.data_ulong = GET_RS2C(insn, regs);
> +#endif
> + } else if ((insn & INSN_MASK_C_SW) == INSN_MATCH_C_SW) {
> + len = 4;
> + val.data_ulong = GET_RS2S(insn, regs);
> + } else if ((insn & INSN_MASK_C_SWSP) == INSN_MATCH_C_SWSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 4;
> + val.data_ulong = GET_RS2C(insn, regs);
> +#endif
> + } else {
> + regs->epc = epc;
> + return -1;
> + }
> +
> + for (i = 0; i < len; i++)
> + store_u8((void *)(addr + i), val.data_bytes[i]);
> +
> + regs->epc = epc + INSN_LEN(insn);
> +
> + return 0;
> +}
> --
> 2.24.1
>
>
Apart from "#if" changes, looks good to me.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
@ 2020-03-02 3:58 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 3:58 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:05 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Enable a kernel builtin dtb for boards not capable of providing a
> device tree to the kernel.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
This is a good feature addition for Linux RISC-V kernel.
Looks good to me.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> arch/riscv/Kbuild | 1 +
> arch/riscv/Kconfig | 18 ++++++++++++++++++
> arch/riscv/boot/dts/Makefile | 4 ++++
> arch/riscv/kernel/setup.c | 6 ++++++
> arch/riscv/mm/init.c | 4 ++++
> 5 files changed, 33 insertions(+)
>
> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
> index d1d0aa70fdf1..988804e430e4 100644
> --- a/arch/riscv/Kbuild
> +++ b/arch/riscv/Kbuild
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> obj-y += kernel/ mm/ net/
> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 1a3b5a5276be..28899e15f548 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
>
> endchoice
>
> +config USE_BUILTIN_DTB
> + bool "Use builtin DTB"
> + help
> + Link a device tree blob for particular hardware into the kernel,
> + suppressing use of the DTB pointer provided by the bootloader.
> + This option should only be used with hardware or bootloaders that
> + are not capable of providing a DTB to the kernel, or for
> + experimental hardware without stable device tree bindings.
> +
> +config BUILTIN_DTB_SOURCE
> + string "Source file for builtin DTB"
> + default ""
> + depends on USE_BUILTIN_DTB
> + help
> + Base name (without suffix, relative to arch/riscv/boot/dts) for
> + the a DTS file that will be used to produce the DTB linked into
> + the kernel.
> +
> endmenu
>
> menu "Power management options"
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index dcc3ada78455..0bf2669aa12d 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -1,2 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> +else
> subdir-y += sifive
> +endif
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 0a6d415b0a5a..3e89be9d888c 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
>
> setup_bootmem();
> paging_init();
> +
> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> + unflatten_and_copy_device_tree();
> +#else
> unflatten_device_tree();
> +#endif
> +
> clint_init_boot_cpu();
>
> #ifdef CONFIG_SWIOTLB
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 965a8cf4829c..1274e889d008 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void)
> #else
> asmlinkage void __init setup_vm(uintptr_t dtb_pa)
> {
> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> + dtb_early_va = __dtb_start;
> +#else
> dtb_early_va = (void *)dtb_pa;
> +#endif
> }
>
> static inline void setup_vm_final(void)
> --
> 2.24.1
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 07/10] riscv: Select required drivers for Kendryte SOC
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
@ 2020-03-02 3:59 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 3:59 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:05 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> This patch selects drivers required for the Kendryte K210 SOC.
>
> Since K210 based boards do not provide a device tree, this patch
> also enables the BUILTIN_DTB option.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
LGTM.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> arch/riscv/Kconfig.socs | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index 4d5d4a65b2a2..8d83210467d9 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -13,6 +13,10 @@ config SOC_SIFIVE
> config SOC_KENDRYTE
> bool "Kendryte K210 SoC"
> depends on !MMU
> + select BUILTIN_DTB
> + select SERIAL_SIFIVE if TTY
> + select SERIAL_SIFIVE_CONSOLE if TTY
> + select SIFIVE_PLIC
> help
> This enables support for Kendryte K210 SoC hardware.
>
> --
> 2.24.1
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
2020-02-14 20:51 ` Sean Anderson
@ 2020-03-02 4:06 ` Anup Patel
2020-03-02 4:15 ` Damien Le Moal
2020-03-04 19:44 ` Palmer Dabbelt
2 siblings, 1 reply; 89+ messages in thread
From: Anup Patel @ 2020-03-02 4:06 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:05 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add a generic device tree for Kendryte K210 SoC based boards. This (for
> now) very simple device tree works for the Kendryte KD233 development
> board, the Sipeed MAIX M1 Dock based boards and the Sipeed MAIXDUINO
> board.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/kendryte/Makefile | 2 +
> arch/riscv/boot/dts/kendryte/k210.dts | 23 +++++
> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 +++++++++++++++++++++++++
> 4 files changed, 149 insertions(+)
> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index 0bf2669aa12d..87815557f2db 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -3,4 +3,5 @@ ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> else
> subdir-y += sifive
> +subdir-y += kendryte
> endif
> diff --git a/arch/riscv/boot/dts/kendryte/Makefile b/arch/riscv/boot/dts/kendryte/Makefile
> new file mode 100644
> index 000000000000..815444e69e89
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_SOC_KENDRYTE) += k210.dtb
> diff --git a/arch/riscv/boot/dts/kendryte/k210.dts b/arch/riscv/boot/dts/kendryte/k210.dts
> new file mode 100644
> index 000000000000..0d1f28fce6b2
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/k210.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +/dts-v1/;
> +
> +#include "k210.dtsi"
> +
> +/ {
> + model = "Kendryte K210 generic";
> + compatible = "kendryte,k210";
> +
> + chosen {
> + bootargs = "earlycon console=ttySIF0";
> + stdout-path = "serial0";
> + };
> +};
> +
> +&uarths0 {
> + status = "okay";
> +};
> +
> diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi
> new file mode 100644
> index 000000000000..4b9eeabb07f7
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +/ {
> + /*
> + * Although the K210 is a 64-bit CPU, the address bus is only 32-bits
> + * wide, and the upper half of all addresses is ignored.
> + */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "kendryte,k210";
> +
> + aliases {
> + serial0 = &uarths0;
> + };
> +
> + clocks {
> + in0: oscillator {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <26000000>;
> + };
> + };
Move the "clocks" DT node just before "soc" DT node. The usual (unsaid)
convention is to keep "cpus", "memory", "aliases", and "chosen" DT nodes
before everything else.
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <7800000>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "none";
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <64>; /* bogus */
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <64>; /* bogus */
> + clocks = <&sysctl 0>;
> + clock-frequency = <390000000>;
> + cpu0_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + reg = <1>;
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "none";
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <64>; /* bogus */
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <64>; /* bogus */
> + clocks = <&sysctl 0>;
> + clock-frequency = <390000000>;
> + cpu1_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + };
> +
> + sram0: memory@80000000 {
> + device_type = "memory";
> + reg = <0x80000000 0x400000>;
> + };
> +
> + sram1: memory@80400000 {
> + device_type = "memory";
> + reg = <0x80400000 0x200000>;
> + };
> +
> + kpu_sram: memory@80600000 {
> + device_type = "memory";
> + reg = <0x80600000 0x200000>;
> + };
No need to have separate DT node for each RAM bank. This can be
express as single DT node as follows:
sram: memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x400000>,
<0x80400000 0x200000>,
<0x80600000 0x200000>;
};
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "kendryte,k210-soc", "simple-bus";
> + ranges;
> + interrupt-parent = <&plic0>;
> +
> + sysctl: sysctl@50440000 {
> + compatible = "kendryte,k210-sysctl", "syscon";
> + reg = <0x50440000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + clint0: interrupt-controller@2000000 {
> + compatible = "riscv,clint0";
> + reg = <0x2000000 0xC000>;
> + interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
> + clocks = <&sysctl 0>;
> + };
> +
> + plic0: interrupt-controller@c000000 {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "kendryte,k210-plic0", "riscv,plic0";
> + reg = <0xC000000 0x3FFF008>;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
> + riscv,ndev = <65>;
> + riscv,max-priority = <0x07>;
> + };
> +
> + uarths0: serial@38000000 {
> + compatible = "kendryte,k210-uart0", "sifive,uart0";
> + reg = <0x38000000 0x20>;
> + interrupts = <33>;
> + clocks = <&sysctl 0>;
> + };
> + };
> +};
> --
> 2.24.1
>
>
Regards,
Anup
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 09/10] riscv: Kendryte K210 default config
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
@ 2020-03-02 4:07 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 4:07 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:05 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The patch adds defconfig to build No-MMU kernel meant for
> Kendryte K210 SoC.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
LGTM.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> arch/riscv/configs/nommu_k210_defconfig | 68 +++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 arch/riscv/configs/nommu_k210_defconfig
>
> diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
> new file mode 100644
> index 000000000000..00ded8f0bc55
> --- /dev/null
> +++ b/arch/riscv/configs/nommu_k210_defconfig
> @@ -0,0 +1,68 @@
> +# CONFIG_CPU_ISOLATION is not set
> +CONFIG_LOG_BUF_SHIFT=15
> +CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_INITRAMFS_SOURCE="k210.cpio"
> +CONFIG_INITRAMFS_FORCE=y
> +# CONFIG_RD_BZIP2 is not set
> +# CONFIG_RD_LZMA is not set
> +# CONFIG_RD_XZ is not set
> +# CONFIG_RD_LZO is not set
> +# CONFIG_RD_LZ4 is not set
> +# CONFIG_BOOT_CONFIG is not set
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +# CONFIG_SYSFS_SYSCALL is not set
> +# CONFIG_FHANDLE is not set
> +# CONFIG_BASE_FULL is not set
> +# CONFIG_EPOLL is not set
> +# CONFIG_SIGNALFD is not set
> +# CONFIG_TIMERFD is not set
> +# CONFIG_EVENTFD is not set
> +# CONFIG_AIO is not set
> +# CONFIG_IO_URING is not set
> +# CONFIG_ADVISE_SYSCALLS is not set
> +# CONFIG_MEMBARRIER is not set
> +# CONFIG_KALLSYMS is not set
> +CONFIG_EMBEDDED=y
> +# CONFIG_VM_EVENT_COUNTERS is not set
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLOB=y
> +# CONFIG_SLAB_MERGE_DEFAULT is not set
> +# CONFIG_MMU is not set
> +CONFIG_SOC_KENDRYTE=y
> +CONFIG_MAXPHYSMEM_2GB=y
> +CONFIG_SMP=y
> +CONFIG_NR_CPUS=2
> +CONFIG_CMDLINE="earlycon console=ttySIF0"
> +CONFIG_CMDLINE_FORCE=y
> +CONFIG_USE_BUILTIN_DTB=y
> +CONFIG_BUILTIN_DTB_SOURCE="kendryte/k210"
> +# CONFIG_BLOCK is not set
> +CONFIG_BINFMT_FLAT=y
> +# CONFIG_COREDUMP is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_FW_LOADER is not set
> +# CONFIG_ALLOW_DEV_COREDUMP is not set
> +# CONFIG_INPUT_KEYBOARD is not set
> +# CONFIG_INPUT_MOUSE is not set
> +# CONFIG_SERIO is not set
> +# CONFIG_LEGACY_PTYS is not set
> +# CONFIG_LDISC_AUTOLOAD is not set
> +# CONFIG_DEVMEM is not set
> +# CONFIG_HW_RANDOM is not set
> +# CONFIG_HWMON is not set
> +# CONFIG_VGA_CONSOLE is not set
> +# CONFIG_HID is not set
> +# CONFIG_USB_SUPPORT is not set
> +# CONFIG_VIRTIO_MENU is not set
> +# CONFIG_DNOTIFY is not set
> +# CONFIG_INOTIFY_USER is not set
> +# CONFIG_MISC_FILESYSTEMS is not set
> +CONFIG_LSM="[]"
> +CONFIG_PRINTK_TIME=y
> +# CONFIG_DEBUG_MISC is not set
> +# CONFIG_SCHED_DEBUG is not set
> +# CONFIG_RCU_TRACE is not set
> +# CONFIG_FTRACE is not set
> +# CONFIG_RUNTIME_TESTING_MENU is not set
> --
> 2.24.1
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
@ 2020-03-02 4:08 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 4:08 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Feb 12, 2020 at 4:05 PM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> From: Christoph Hellwig <hch@lst.de>
>
> This can be loaded into the Kendryte KD210 based boards using:
>
> kflash.py/kflash.py -t arch/riscv/boot/loader.bin
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
LGTM.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> arch/riscv/Makefile | 4 ++--
> arch/riscv/boot/Makefile | 3 +++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index b9009a2fbaf5..440969763e14 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -84,11 +84,11 @@ vdso_install:
> $(Q)$(MAKE) $(build)=arch/riscv/kernel/vdso $@
>
> ifeq ($(CONFIG_RISCV_M_MODE),y)
> -KBUILD_IMAGE := $(boot)/loader
> +KBUILD_IMAGE := $(boot)/loader.bin
> else
> KBUILD_IMAGE := $(boot)/Image.gz
> endif
> -BOOT_TARGETS := Image Image.gz loader
> +BOOT_TARGETS := Image Image.gz loader loader.bin
>
> all: $(notdir $(KBUILD_IMAGE))
>
> diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
> index 36db8145f9f4..3530c59b3ea7 100644
> --- a/arch/riscv/boot/Makefile
> +++ b/arch/riscv/boot/Makefile
> @@ -41,6 +41,9 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
> $(obj)/Image.lzo: $(obj)/Image FORCE
> $(call if_changed,lzo)
>
> +$(obj)/loader.bin: $(obj)/loader FORCE
> + $(call if_changed,objcopy)
> +
> install:
> $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
> $(obj)/Image System.map "$(INSTALL_PATH)"
> --
> 2.24.1
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 3:53 ` Sean Anderson
@ 2020-03-02 4:11 ` Damien Le Moal
2020-03-02 4:18 ` Sean Anderson
2020-03-02 4:17 ` Anup Patel
1 sibling, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 4:11 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/03/02 12:53, Sean Anderson wrote:
> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>> On 2020/02/29 5:32, Sean Anderson wrote:
>>> Hi,
>>>
>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>> second cpu not coming up?
>>
>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>> allocation). Since you have only 5.5MB free, that may explain the allocation
>> failure (if init is forking another shell especially).
>
> This should be before init comes up; when comparing this to your syslog
> output there are several more messages before init gets started.
Ah, yes. Your log shows:
[ 1.899086] Mem-Info:
[ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
[ 1.901072] active_file:0 inactive_file:0 isolated_file:0
[ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
[ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
[ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
[ 1.901072] free:417 free_pcp:0 free_cma:0
so only 417 free pages, but awapper is asking for 512 pages allocation... Weird.
Did you use the k210 default config ? Something using too much memory for the
board has been added to the config I think.
>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>> the kernel. I thought I had that in the kernel though. Will check again.
>
> I think it's a RISC-V thing. I should have U-Boot set up to start linux
> on both cores, but something may be misconfigured on that end.
May be. I would need to check the specs again :)
I think that normally, the rom boot stage is normally bringing up all cores ?
And the kendryte one does not ? Hence the need to explicitly do it for direct
boot (in the kernel) or in u-boot ?
>
> --Sean
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-02 4:06 ` Anup Patel
@ 2020-03-02 4:15 ` Damien Le Moal
2020-03-02 4:22 ` Anup Patel
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 4:15 UTC (permalink / raw)
To: Anup Patel; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 13:07, Anup Patel wrote:
[...]
>> + sram0: memory@80000000 {
>> + device_type = "memory";
>> + reg = <0x80000000 0x400000>;
>> + };
>> +
>> + sram1: memory@80400000 {
>> + device_type = "memory";
>> + reg = <0x80400000 0x200000>;
>> + };
>> +
>> + kpu_sram: memory@80600000 {
>> + device_type = "memory";
>> + reg = <0x80600000 0x200000>;
>> + };
>
> No need to have separate DT node for each RAM bank. This can be
> express as single DT node as follows:
>
> sram: memory@80000000 {
> device_type = "memory";
> reg = <0x80000000 0x400000>,
> <0x80400000 0x200000>,
> <0x80600000 0x200000>;
> };
This is to match the U-boot device tree that Sean wrote. So I would rather keep
it like this. And strictly speaking, if one wants to add a driver for the KPU,
having the kpu memory segment for it separate makes it easy to reference it from
a kpu device entry. But granted, the two sram segments can be declared with a
single memory entry.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 3:53 ` Sean Anderson
2020-03-02 4:11 ` Damien Le Moal
@ 2020-03-02 4:17 ` Anup Patel
2020-03-02 4:21 ` Sean Anderson
2020-03-02 4:48 ` Damien Le Moal
1 sibling, 2 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-02 4:17 UTC (permalink / raw)
To: Sean Anderson
Cc: Damien Le Moal, Anup Patel, Palmer Dabbelt, linux-riscv, Paul Walmsley
On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>
> On 3/1/20 10:01 PM, Damien Le Moal wrote:
> > On 2020/02/29 5:32, Sean Anderson wrote:
> >> Hi,
> >>
> >> When booting from U-Boot I get an OOM. Perhaps this is related to the
> >> second cpu not coming up?
> >
> > Unlikely. It looks like your user space needs 2MB per shell (order 9
> > allocation). Since you have only 5.5MB free, that may explain the allocation
> > failure (if init is forking another shell especially).
>
> This should be before init comes up; when comparing this to your syslog
> output there are several more messages before init gets started.
>
> > For the second core not coming up, an IPI needs to be sent to the non-boot core
> > to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
> > the kernel. I thought I had that in the kernel though. Will check again.
>
> I think it's a RISC-V thing. I should have U-Boot set up to start linux
> on both cores, but something may be misconfigured on that end.
You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
Linux NOMMU.
Based on you log, it seems the second CPU is still spinning in U-Boot
M-mode and when Linux NOMMU tries to touch memory where second
CPU is spinning everything gets corrupted.
Regards,
Anup
>
> --Sean
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:11 ` Damien Le Moal
@ 2020-03-02 4:18 ` Sean Anderson
2020-03-02 4:54 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-03-02 4:18 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 3/1/20 11:11 PM, Damien Le Moal wrote:
> On 2020/03/02 12:53, Sean Anderson wrote:
>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>> Hi,
>>>>
>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>> second cpu not coming up?
>>>
>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>> failure (if init is forking another shell especially).
>>
>> This should be before init comes up; when comparing this to your syslog
>> output there are several more messages before init gets started.
>
> Ah, yes. Your log shows:
> [ 1.899086] Mem-Info:
> [ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
> [ 1.901072] active_file:0 inactive_file:0 isolated_file:0
> [ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
> [ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
> [ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
> [ 1.901072] free:417 free_pcp:0 free_cma:0
>
> so only 417 free pages, but awapper is asking for 512 pages allocation... Weird.
> Did you use the k210 default config ? Something using too much memory for the
> board has been added to the config I think.
I am using the default config. I thought it might be the initramfs
taking too much space on decompression, but I got the same problem when
using an uncompressed initramfs.
>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>> the kernel. I thought I had that in the kernel though. Will check again.
>>
>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>> on both cores, but something may be misconfigured on that end.
>
> May be. I would need to check the specs again :)
> I think that normally, the rom boot stage is normally bringing up all cores ?
> And the kendryte one does not ? Hence the need to explicitly do it for direct
> boot (in the kernel) or in u-boot ?
The Kendryte rom brings up all the cores. However, that means that all
cores are executing the same code at the same time. So (in U-Boot) there
is a "hart lottery", which picks a hart to do booting from. All the
other harts instead jump to a loop where they wait for an IPI to tell
them what to execute. This same process also happened in the Kendryte
ROM, and will happen again when Linux comes up. The problem could be
related to my usage of the "go" command vs the full bootm process... I
will check to see if I have the same problem if I boot directly to
Linux.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:17 ` Anup Patel
@ 2020-03-02 4:21 ` Sean Anderson
2020-03-02 4:48 ` Damien Le Moal
1 sibling, 0 replies; 89+ messages in thread
From: Sean Anderson @ 2020-03-02 4:21 UTC (permalink / raw)
To: Anup Patel
Cc: Damien Le Moal, Anup Patel, Palmer Dabbelt, linux-riscv, Paul Walmsley
On 3/1/20 11:17 PM, Anup Patel wrote:
> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>
>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>> Hi,
>>>>
>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>> second cpu not coming up?
>>>
>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>> failure (if init is forking another shell especially).
>>
>> This should be before init comes up; when comparing this to your syslog
>> output there are several more messages before init gets started.
>>
>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>> the kernel. I thought I had that in the kernel though. Will check again.
>>
>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>> on both cores, but something may be misconfigured on that end.
>
> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
> Linux NOMMU.
Ah, I used just "go" for this test since bootm was having some problems
finding a place for the device tree. Perhaps I should try booting this
as a legacy standalone image...
> Based on you log, it seems the second CPU is still spinning in U-Boot
> M-mode and when Linux NOMMU tries to touch memory where second
> CPU is spinning everything gets corrupted.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-02 4:15 ` Damien Le Moal
@ 2020-03-02 4:22 ` Anup Patel
2020-03-02 4:51 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Anup Patel @ 2020-03-02 4:22 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Mon, Mar 2, 2020 at 9:46 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2020/03/02 13:07, Anup Patel wrote:
> [...]
> >> + sram0: memory@80000000 {
> >> + device_type = "memory";
> >> + reg = <0x80000000 0x400000>;
> >> + };
> >> +
> >> + sram1: memory@80400000 {
> >> + device_type = "memory";
> >> + reg = <0x80400000 0x200000>;
> >> + };
> >> +
> >> + kpu_sram: memory@80600000 {
> >> + device_type = "memory";
> >> + reg = <0x80600000 0x200000>;
> >> + };
> >
> > No need to have separate DT node for each RAM bank. This can be
> > express as single DT node as follows:
> >
> > sram: memory@80000000 {
> > device_type = "memory";
> > reg = <0x80000000 0x400000>,
> > <0x80400000 0x200000>,
> > <0x80600000 0x200000>;
> > };
>
> This is to match the U-boot device tree that Sean wrote. So I would rather keep
> it like this. And strictly speaking, if one wants to add a driver for the KPU,
> having the kpu memory segment for it separate makes it easy to reference it from
> a kpu device entry. But granted, the two sram segments can be declared with a
> single memory entry.
But, that's not the preferred way of describing memory banks on the
same machine.
Usually, we create multiple memory DT nodes for NUMA systems.
You can also refer various ARM/ARM64 DTS files.
Regards,
Anup
>
>
>
>
> --
> Damien Le Moal
> Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:17 ` Anup Patel
2020-03-02 4:21 ` Sean Anderson
@ 2020-03-02 4:48 ` Damien Le Moal
2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:02 ` Sean Anderson
1 sibling, 2 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 4:48 UTC (permalink / raw)
To: Anup Patel, Sean Anderson
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 13:17, Anup Patel wrote:
> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>
>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>> Hi,
>>>>
>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>> second cpu not coming up?
>>>
>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>> failure (if init is forking another shell especially).
>>
>> This should be before init comes up; when comparing this to your syslog
>> output there are several more messages before init gets started.
>>
>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>> the kernel. I thought I had that in the kernel though. Will check again.
>>
>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>> on both cores, but something may be misconfigured on that end.
>
> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
> Linux NOMMU.
>
> Based on you log, it seems the second CPU is still spinning in U-Boot
> M-mode and when Linux NOMMU tries to touch memory where second
> CPU is spinning everything gets corrupted.
Yes, I understand. But in the case of the K210, that last 2MB segment is really
special as by default it is not usable as regular SRAM. I think it may be better
to reflect that in the device tree. The K210 soc_early_init() call back can
probe for that special entry too to see if it has to be turned on for use as
regular memory or not (i.e. if a kpu driver will use it).
Since booting Linux with 6MB of memory will be even more challenging than with
8, I agree that we may never see the case of a kpu driver being used. But I
personally like making that special case clear in the device tree. No strong
objection to your simplification though. So if you really object, I will go with it.
Cheers.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-02 4:22 ` Anup Patel
@ 2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:05 ` Anup Patel
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 4:51 UTC (permalink / raw)
To: Anup Patel; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 13:22, Anup Patel wrote:
> On Mon, Mar 2, 2020 at 9:46 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>
>> On 2020/03/02 13:07, Anup Patel wrote:
>> [...]
>>>> + sram0: memory@80000000 {
>>>> + device_type = "memory";
>>>> + reg = <0x80000000 0x400000>;
>>>> + };
>>>> +
>>>> + sram1: memory@80400000 {
>>>> + device_type = "memory";
>>>> + reg = <0x80400000 0x200000>;
>>>> + };
>>>> +
>>>> + kpu_sram: memory@80600000 {
>>>> + device_type = "memory";
>>>> + reg = <0x80600000 0x200000>;
>>>> + };
>>>
>>> No need to have separate DT node for each RAM bank. This can be
>>> express as single DT node as follows:
>>>
>>> sram: memory@80000000 {
>>> device_type = "memory";
>>> reg = <0x80000000 0x400000>,
>>> <0x80400000 0x200000>,
>>> <0x80600000 0x200000>;
>>> };
>>
>> This is to match the U-boot device tree that Sean wrote. So I would rather keep
>> it like this. And strictly speaking, if one wants to add a driver for the KPU,
>> having the kpu memory segment for it separate makes it easy to reference it from
>> a kpu device entry. But granted, the two sram segments can be declared with a
>> single memory entry.
>
> But, that's not the preferred way of describing memory banks on the
> same machine.
> Usually, we create multiple memory DT nodes for NUMA systems.
>
> You can also refer various ARM/ARM64 DTS files.
Oops... Sent an answer to this to the wrong email... Here it is again:
Yes, I understand. But in the case of the K210, that last 2MB segment is really
special as by default it is not usable as regular SRAM. I think it may be better
to reflect that in the device tree. The K210 soc_early_init() call back can
probe for that special entry too to see if it has to be turned on for use as
regular memory or not (i.e. if a kpu driver will use it).
Since booting Linux with 6MB of memory will be even more challenging than with
8, I agree that we may never see the case of a kpu driver being used. But I
personally like making that special case clear in the device tree. No strong
objection to your simplification though. So if you really object, I will go with it.
Cheers.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:48 ` Damien Le Moal
@ 2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:02 ` Sean Anderson
1 sibling, 0 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 4:51 UTC (permalink / raw)
To: Anup Patel, Sean Anderson
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 13:48, Damien Le Moal wrote:
> On 2020/03/02 13:17, Anup Patel wrote:
>> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>
>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>> Hi,
>>>>>
>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>> second cpu not coming up?
>>>>
>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>> failure (if init is forking another shell especially).
>>>
>>> This should be before init comes up; when comparing this to your syslog
>>> output there are several more messages before init gets started.
>>>
>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>
>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>> on both cores, but something may be misconfigured on that end.
>>
>> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
>> Linux NOMMU.
>>
>> Based on you log, it seems the second CPU is still spinning in U-Boot
>> M-mode and when Linux NOMMU tries to touch memory where second
>> CPU is spinning everything gets corrupted.
>
> Yes, I understand. But in the case of the K210, that last 2MB segment is really
> special as by default it is not usable as regular SRAM. I think it may be better
> to reflect that in the device tree. The K210 soc_early_init() call back can
> probe for that special entry too to see if it has to be turned on for use as
> regular memory or not (i.e. if a kpu driver will use it).
>
> Since booting Linux with 6MB of memory will be even more challenging than with
> 8, I agree that we may never see the case of a kpu driver being used. But I
> personally like making that special case clear in the device tree. No strong
> objection to your simplification though. So if you really object, I will go with it.
Answer to the wrong email... Please ignore :)
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:18 ` Sean Anderson
@ 2020-03-02 4:54 ` Damien Le Moal
2020-03-02 4:56 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 4:54 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/03/02 13:18, Sean Anderson wrote:
> On 3/1/20 11:11 PM, Damien Le Moal wrote:
>> On 2020/03/02 12:53, Sean Anderson wrote:
>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>> Hi,
>>>>>
>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>> second cpu not coming up?
>>>>
>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>> failure (if init is forking another shell especially).
>>>
>>> This should be before init comes up; when comparing this to your syslog
>>> output there are several more messages before init gets started.
>>
>> Ah, yes. Your log shows:
>> [ 1.899086] Mem-Info:
>> [ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
>> [ 1.901072] active_file:0 inactive_file:0 isolated_file:0
>> [ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
>> [ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
>> [ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
>> [ 1.901072] free:417 free_pcp:0 free_cma:0
>>
>> so only 417 free pages, but awapper is asking for 512 pages allocation... Weird.
>> Did you use the k210 default config ? Something using too much memory for the
>> board has been added to the config I think.
>
> I am using the default config. I thought it might be the initramfs
> taking too much space on decompression, but I got the same problem when
> using an uncompressed initramfs.
Yes, that must be it. How big is your initramfs ? I generally do not see any
problem with 500-600KB initramfs. For bigger ones, I do see the OOM problem
often too. But most of the time, the OOM triggers more if the busybox executable
is too big and there are too many shell levels.
>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>
>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>> on both cores, but something may be misconfigured on that end.
>>
>> May be. I would need to check the specs again :)
>> I think that normally, the rom boot stage is normally bringing up all cores ?
>> And the kendryte one does not ? Hence the need to explicitly do it for direct
>> boot (in the kernel) or in u-boot ?
>
> The Kendryte rom brings up all the cores. However, that means that all
> cores are executing the same code at the same time. So (in U-Boot) there
> is a "hart lottery", which picks a hart to do booting from. All the
> other harts instead jump to a loop where they wait for an IPI to tell
> them what to execute. This same process also happened in the Kendryte
> ROM, and will happen again when Linux comes up. The problem could be
> related to my usage of the "go" command vs the full bootm process... I
> will check to see if I have the same problem if I boot directly to
> Linux.
>
> --Sean
>
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:54 ` Damien Le Moal
@ 2020-03-02 4:56 ` Sean Anderson
2020-03-02 5:03 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-03-02 4:56 UTC (permalink / raw)
To: Damien Le Moal, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 3/1/20 11:54 PM, Damien Le Moal wrote:
> On 2020/03/02 13:18, Sean Anderson wrote:
>> On 3/1/20 11:11 PM, Damien Le Moal wrote:
>>> On 2020/03/02 12:53, Sean Anderson wrote:
>>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>>> second cpu not coming up?
>>>>>
>>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>>> failure (if init is forking another shell especially).
>>>>
>>>> This should be before init comes up; when comparing this to your syslog
>>>> output there are several more messages before init gets started.
>>>
>>> Ah, yes. Your log shows:
>>> [ 1.899086] Mem-Info:
>>> [ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
>>> [ 1.901072] active_file:0 inactive_file:0 isolated_file:0
>>> [ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
>>> [ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
>>> [ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
>>> [ 1.901072] free:417 free_pcp:0 free_cma:0
>>>
>>> so only 417 free pages, but awapper is asking for 512 pages allocation... Weird.
>>> Did you use the k210 default config ? Something using too much memory for the
>>> board has been added to the config I think.
>>
>> I am using the default config. I thought it might be the initramfs
>> taking too much space on decompression, but I got the same problem when
>> using an uncompressed initramfs.
>
> Yes, that must be it. How big is your initramfs ? I generally do not see any
> problem with 500-600KB initramfs. For bigger ones, I do see the OOM problem
> often too. But most of the time, the OOM triggers more if the busybox executable
> is too big and there are too many shell levels.
My initramfs is 1.6M atm, so perhaps I should try with a smaller one.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:48 ` Damien Le Moal
2020-03-02 4:51 ` Damien Le Moal
@ 2020-03-02 5:02 ` Sean Anderson
2020-03-02 5:11 ` Damien Le Moal
1 sibling, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-03-02 5:02 UTC (permalink / raw)
To: Damien Le Moal, Anup Patel
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 3/1/20 11:48 PM, Damien Le Moal wrote:
> On 2020/03/02 13:17, Anup Patel wrote:
>> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>
>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>> Hi,
>>>>>
>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>> second cpu not coming up?
>>>>
>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>> failure (if init is forking another shell especially).
>>>
>>> This should be before init comes up; when comparing this to your syslog
>>> output there are several more messages before init gets started.
>>>
>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>
>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>> on both cores, but something may be misconfigured on that end.
>>
>> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
>> Linux NOMMU.
>>
>> Based on you log, it seems the second CPU is still spinning in U-Boot
>> M-mode and when Linux NOMMU tries to touch memory where second
>> CPU is spinning everything gets corrupted.
>
> Yes, I understand. But in the case of the K210, that last 2MB segment is really
> special as by default it is not usable as regular SRAM. I think it may be better
> to reflect that in the device tree. The K210 soc_early_init() call back can
> probe for that special entry too to see if it has to be turned on for use as
> regular memory or not (i.e. if a kpu driver will use it).
>
> Since booting Linux with 6MB of memory will be even more challenging than with
> 8, I agree that we may never see the case of a kpu driver being used. But I
> personally like making that special case clear in the device tree. No strong
> objection to your simplification though. So if you really object, I will go with it.
The way I have it set up is like this
sram0: memory@80000000 {
device_type = "memory";
compatible = "kendryte,k210-sram";
reg = <0x80000000 0x400000>;
clocks = <&sysclk K210_CLK_SRAM0>;
};
sram1: memory@80400000 {
device_type = "memory";
reg = <0x80400000 0x200000>;
compatible = "kendryte,k210-sram";
clocks = <&sysclk K210_CLK_SRAM1>;
};
airam: memory@80600000 {
device_type = "memory";
reg = <0x80600000 0x200000>;
compatible = "kendryte,k210-airam";
clocks = <&sysclk K210_CLK_AI>;
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
ai_reserved: ai@80600000 {
reg = <0x80600000 0x200000>;
reusable;
};
};
And then the kpu has 'memory-region = <&ai_reserved>;'. This way the
memory is documented as being used by the kpu, but also free when the
KPU is not in use.
However, I have been unable to get the AI ram to work; any time I
access it the CPU hangs. I have tried all combinations of
* Enabling/disabling the AI clock
* Enabling/disabling PLL1 (the AI clock's parent) but not the AI clock
* Asserting/deasserting the KPU reset
but I have not been able to get it working. Have you had any luck?
There's also the issue that all DMAs should happen from the uncached
memory area, but I think there is some existing infrastructure to
"translate" IO addresses, so this doesn't need to be added to the device
tree.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 4:56 ` Sean Anderson
@ 2020-03-02 5:03 ` Damien Le Moal
0 siblings, 0 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 5:03 UTC (permalink / raw)
To: Sean Anderson, linux-riscv, Palmer Dabbelt; +Cc: Anup Patel, Paul Walmsley
On 2020/03/02 13:57, Sean Anderson wrote:
> On 3/1/20 11:54 PM, Damien Le Moal wrote:
>> On 2020/03/02 13:18, Sean Anderson wrote:
>>> On 3/1/20 11:11 PM, Damien Le Moal wrote:
>>>> On 2020/03/02 12:53, Sean Anderson wrote:
>>>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>>>> second cpu not coming up?
>>>>>>
>>>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>>>> failure (if init is forking another shell especially).
>>>>>
>>>>> This should be before init comes up; when comparing this to your syslog
>>>>> output there are several more messages before init gets started.
>>>>
>>>> Ah, yes. Your log shows:
>>>> [ 1.899086] Mem-Info:
>>>> [ 1.901072] active_anon:0 inactive_anon:0 isolated_anon:0
>>>> [ 1.901072] active_file:0 inactive_file:0 isolated_file:0
>>>> [ 1.901072] unevictable:705 dirty:0 writeback:0 unstable:0
>>>> [ 1.901072] slab_reclaimable:0 slab_unreclaimable:215
>>>> [ 1.901072] mapped:0 shmem:0 pagetables:0 bounce:0
>>>> [ 1.901072] free:417 free_pcp:0 free_cma:0
>>>>
>>>> so only 417 free pages, but awapper is asking for 512 pages allocation... Weird.
>>>> Did you use the k210 default config ? Something using too much memory for the
>>>> board has been added to the config I think.
>>>
>>> I am using the default config. I thought it might be the initramfs
>>> taking too much space on decompression, but I got the same problem when
>>> using an uncompressed initramfs.
>>
>> Yes, that must be it. How big is your initramfs ? I generally do not see any
>> problem with 500-600KB initramfs. For bigger ones, I do see the OOM problem
>> often too. But most of the time, the OOM triggers more if the busybox executable
>> is too big and there are too many shell levels.
>
> My initramfs is 1.6M atm, so perhaps I should try with a smaller one.
Most likely. I never had success initially with such big initramfs. Buildroot
initramfs builds tend to be really much bigger than necessary. So I tend to
manually make my own. With a 1.6MB initramfs, you will need the order 9
allocation seen (2MB) before the 1.6MB embedded initramfs is freed. With some
memory fragmentation, that may fail easily. I do wonder though why the memory
would be so fragmented so early in the boot process. It may be interesting to
explore that to see if some optimizations cannot be added.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-02 4:51 ` Damien Le Moal
@ 2020-03-02 5:05 ` Anup Patel
2020-03-02 5:08 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Anup Patel @ 2020-03-02 5:05 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Mon, Mar 2, 2020 at 10:21 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2020/03/02 13:22, Anup Patel wrote:
> > On Mon, Mar 2, 2020 at 9:46 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>
> >> On 2020/03/02 13:07, Anup Patel wrote:
> >> [...]
> >>>> + sram0: memory@80000000 {
> >>>> + device_type = "memory";
> >>>> + reg = <0x80000000 0x400000>;
> >>>> + };
> >>>> +
> >>>> + sram1: memory@80400000 {
> >>>> + device_type = "memory";
> >>>> + reg = <0x80400000 0x200000>;
> >>>> + };
> >>>> +
> >>>> + kpu_sram: memory@80600000 {
> >>>> + device_type = "memory";
> >>>> + reg = <0x80600000 0x200000>;
> >>>> + };
> >>>
> >>> No need to have separate DT node for each RAM bank. This can be
> >>> express as single DT node as follows:
> >>>
> >>> sram: memory@80000000 {
> >>> device_type = "memory";
> >>> reg = <0x80000000 0x400000>,
> >>> <0x80400000 0x200000>,
> >>> <0x80600000 0x200000>;
> >>> };
> >>
> >> This is to match the U-boot device tree that Sean wrote. So I would rather keep
> >> it like this. And strictly speaking, if one wants to add a driver for the KPU,
> >> having the kpu memory segment for it separate makes it easy to reference it from
> >> a kpu device entry. But granted, the two sram segments can be declared with a
> >> single memory entry.
> >
> > But, that's not the preferred way of describing memory banks on the
> > same machine.
> > Usually, we create multiple memory DT nodes for NUMA systems.
> >
> > You can also refer various ARM/ARM64 DTS files.
>
> Oops... Sent an answer to this to the wrong email... Here it is again:
>
> Yes, I understand. But in the case of the K210, that last 2MB segment is really
> special as by default it is not usable as regular SRAM. I think it may be better
> to reflect that in the device tree. The K210 soc_early_init() call back can
> probe for that special entry too to see if it has to be turned on for use as
> regular memory or not (i.e. if a kpu driver will use it).
>
> Since booting Linux with 6MB of memory will be even more challenging than with
> 8, I agree that we may never see the case of a kpu driver being used. But I
> personally like making that special case clear in the device tree. No strong
> objection to your simplification though. So if you really object, I will go with it.
>
I understand that it is helping you to distinguish last 2MB segment but this is
also possible using with single memory DT node as follows:
sram: memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x400000>,
<0x80400000 0x200000>,
<0x80600000 0x200000>;
reg-names = "sram0", "sram1", "kpu_sram";
};
The K210 soc_early_init() can do the following:
1. Find memory DT node having device_type = "memory"
2. Find bank number for "kpu_sram" based on "reg-names DT property
3. Get based address of KPU SRAM from "reg" property based on bank
number found in step2 above.
The reg-names is a standard DT property used to distinguish multiple
memory regions of device. Same can be used to distinguish multiple
banks of memory DT node.
I am not adamant on having single memory DT node but just wanted
to let you know that this is not a preferred way for non-NUMA system.
Regards,
Anup
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-02 5:05 ` Anup Patel
@ 2020-03-02 5:08 ` Damien Le Moal
2020-03-07 0:18 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 5:08 UTC (permalink / raw)
To: Anup Patel; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 14:05, Anup Patel wrote:
> On Mon, Mar 2, 2020 at 10:21 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>
>> On 2020/03/02 13:22, Anup Patel wrote:
>>> On Mon, Mar 2, 2020 at 9:46 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>
>>>> On 2020/03/02 13:07, Anup Patel wrote:
>>>> [...]
>>>>>> + sram0: memory@80000000 {
>>>>>> + device_type = "memory";
>>>>>> + reg = <0x80000000 0x400000>;
>>>>>> + };
>>>>>> +
>>>>>> + sram1: memory@80400000 {
>>>>>> + device_type = "memory";
>>>>>> + reg = <0x80400000 0x200000>;
>>>>>> + };
>>>>>> +
>>>>>> + kpu_sram: memory@80600000 {
>>>>>> + device_type = "memory";
>>>>>> + reg = <0x80600000 0x200000>;
>>>>>> + };
>>>>>
>>>>> No need to have separate DT node for each RAM bank. This can be
>>>>> express as single DT node as follows:
>>>>>
>>>>> sram: memory@80000000 {
>>>>> device_type = "memory";
>>>>> reg = <0x80000000 0x400000>,
>>>>> <0x80400000 0x200000>,
>>>>> <0x80600000 0x200000>;
>>>>> };
>>>>
>>>> This is to match the U-boot device tree that Sean wrote. So I would rather keep
>>>> it like this. And strictly speaking, if one wants to add a driver for the KPU,
>>>> having the kpu memory segment for it separate makes it easy to reference it from
>>>> a kpu device entry. But granted, the two sram segments can be declared with a
>>>> single memory entry.
>>>
>>> But, that's not the preferred way of describing memory banks on the
>>> same machine.
>>> Usually, we create multiple memory DT nodes for NUMA systems.
>>>
>>> You can also refer various ARM/ARM64 DTS files.
>>
>> Oops... Sent an answer to this to the wrong email... Here it is again:
>>
>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
>> special as by default it is not usable as regular SRAM. I think it may be better
>> to reflect that in the device tree. The K210 soc_early_init() call back can
>> probe for that special entry too to see if it has to be turned on for use as
>> regular memory or not (i.e. if a kpu driver will use it).
>>
>> Since booting Linux with 6MB of memory will be even more challenging than with
>> 8, I agree that we may never see the case of a kpu driver being used. But I
>> personally like making that special case clear in the device tree. No strong
>> objection to your simplification though. So if you really object, I will go with it.
>>
>
> I understand that it is helping you to distinguish last 2MB segment but this is
> also possible using with single memory DT node as follows:
>
> sram: memory@80000000 {
> device_type = "memory";
> reg = <0x80000000 0x400000>,
> <0x80400000 0x200000>,
> <0x80600000 0x200000>;
> reg-names = "sram0", "sram1", "kpu_sram";
> };
Nice trick. I did not know about it. Will use that then !
>
> The K210 soc_early_init() can do the following:
> 1. Find memory DT node having device_type = "memory"
> 2. Find bank number for "kpu_sram" based on "reg-names DT property
> 3. Get based address of KPU SRAM from "reg" property based on bank
> number found in step2 above.
>
> The reg-names is a standard DT property used to distinguish multiple
> memory regions of device. Same can be used to distinguish multiple
> banks of memory DT node.
>
> I am not adamant on having single memory DT node but just wanted
> to let you know that this is not a preferred way for non-NUMA system.
Understood. Will use your proposed syntax.
>
> Regards,
> Anup
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 5:02 ` Sean Anderson
@ 2020-03-02 5:11 ` Damien Le Moal
2020-03-02 5:25 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 5:11 UTC (permalink / raw)
To: Sean Anderson, Anup Patel
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 14:02, Sean Anderson wrote:
> On 3/1/20 11:48 PM, Damien Le Moal wrote:
>> On 2020/03/02 13:17, Anup Patel wrote:
>>> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>
>>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>>> second cpu not coming up?
>>>>>
>>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>>> failure (if init is forking another shell especially).
>>>>
>>>> This should be before init comes up; when comparing this to your syslog
>>>> output there are several more messages before init gets started.
>>>>
>>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>>
>>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>>> on both cores, but something may be misconfigured on that end.
>>>
>>> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
>>> Linux NOMMU.
>>>
>>> Based on you log, it seems the second CPU is still spinning in U-Boot
>>> M-mode and when Linux NOMMU tries to touch memory where second
>>> CPU is spinning everything gets corrupted.
>>
>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
>> special as by default it is not usable as regular SRAM. I think it may be better
>> to reflect that in the device tree. The K210 soc_early_init() call back can
>> probe for that special entry too to see if it has to be turned on for use as
>> regular memory or not (i.e. if a kpu driver will use it).
>>
>> Since booting Linux with 6MB of memory will be even more challenging than with
>> 8, I agree that we may never see the case of a kpu driver being used. But I
>> personally like making that special case clear in the device tree. No strong
>> objection to your simplification though. So if you really object, I will go with it.
>
> The way I have it set up is like this
>
>
> sram0: memory@80000000 {
> device_type = "memory";
> compatible = "kendryte,k210-sram";
> reg = <0x80000000 0x400000>;
> clocks = <&sysclk K210_CLK_SRAM0>;
> };
>
> sram1: memory@80400000 {
> device_type = "memory";
> reg = <0x80400000 0x200000>;
> compatible = "kendryte,k210-sram";
> clocks = <&sysclk K210_CLK_SRAM1>;
> };
>
> airam: memory@80600000 {
> device_type = "memory";
> reg = <0x80600000 0x200000>;
> compatible = "kendryte,k210-airam";
> clocks = <&sysclk K210_CLK_AI>;
> };
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> ai_reserved: ai@80600000 {
> reg = <0x80600000 0x200000>;
> reusable;
> };
> };>
> And then the kpu has 'memory-region = <&ai_reserved>;'. This way the
> memory is documented as being used by the kpu, but also free when the
> KPU is not in use.
I tried to use your syntax above initially but (if I remember correctly), the
"reserved-memory" entry prevents the initial ram setup to add the kpu segment,
so you can never see it as regular memory. So I dropped that and that memory is
usable with the v1 of the series I sent. The soc_early_init() enables it by
turning on pll1.
>
> However, I have been unable to get the AI ram to work; any time I
> access it the CPU hangs. I have tried all combinations of
>
> * Enabling/disabling the AI clock
> * Enabling/disabling PLL1 (the AI clock's parent) but not the AI clock
> * Asserting/deasserting the KPU reset
>
> but I have not been able to get it working. Have you had any luck?
See k210_soc_early_init() in drivers/soc/kendryte/k210-sysctl.c. That works.
You did already point out the clock initialization that is not enough and
working only because most of the values are the default. Maybe U-boot is
changing some of them resulting in the worng clock frequencies being set in the
kernel ?
>
> There's also the issue that all DMAs should happen from the uncached
> memory area, but I think there is some existing infrastructure to
> "translate" IO addresses, so this doesn't need to be added to the device
> tree.
>
> --Sean
>
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 5:11 ` Damien Le Moal
@ 2020-03-02 5:25 ` Sean Anderson
2020-03-02 5:43 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-03-02 5:25 UTC (permalink / raw)
To: Damien Le Moal, Anup Patel
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 3/2/20 12:11 AM, Damien Le Moal wrote:
> On 2020/03/02 14:02, Sean Anderson wrote:
>> On 3/1/20 11:48 PM, Damien Le Moal wrote:
>>> On 2020/03/02 13:17, Anup Patel wrote:
>>>> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>>
>>>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>>>> second cpu not coming up?
>>>>>>
>>>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>>>> failure (if init is forking another shell especially).
>>>>>
>>>>> This should be before init comes up; when comparing this to your syslog
>>>>> output there are several more messages before init gets started.
>>>>>
>>>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>>>
>>>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>>>> on both cores, but something may be misconfigured on that end.
>>>>
>>>> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
>>>> Linux NOMMU.
>>>>
>>>> Based on you log, it seems the second CPU is still spinning in U-Boot
>>>> M-mode and when Linux NOMMU tries to touch memory where second
>>>> CPU is spinning everything gets corrupted.
>>>
>>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
>>> special as by default it is not usable as regular SRAM. I think it may be better
>>> to reflect that in the device tree. The K210 soc_early_init() call back can
>>> probe for that special entry too to see if it has to be turned on for use as
>>> regular memory or not (i.e. if a kpu driver will use it).
>>>
>>> Since booting Linux with 6MB of memory will be even more challenging than with
>>> 8, I agree that we may never see the case of a kpu driver being used. But I
>>> personally like making that special case clear in the device tree. No strong
>>> objection to your simplification though. So if you really object, I will go with it.
>>
>> The way I have it set up is like this
>>
>>
>> sram0: memory@80000000 {
>> device_type = "memory";
>> compatible = "kendryte,k210-sram";
>> reg = <0x80000000 0x400000>;
>> clocks = <&sysclk K210_CLK_SRAM0>;
>> };
>>
>> sram1: memory@80400000 {
>> device_type = "memory";
>> reg = <0x80400000 0x200000>;
>> compatible = "kendryte,k210-sram";
>> clocks = <&sysclk K210_CLK_SRAM1>;
>> };
>>
>> airam: memory@80600000 {
>> device_type = "memory";
>> reg = <0x80600000 0x200000>;
>> compatible = "kendryte,k210-airam";
>> clocks = <&sysclk K210_CLK_AI>;
>> };
>>
>> reserved-memory {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges;
>>
>> ai_reserved: ai@80600000 {
>> reg = <0x80600000 0x200000>;
>> reusable;
>> };
>> };>
>> And then the kpu has 'memory-region = <&ai_reserved>;'. This way the
>> memory is documented as being used by the kpu, but also free when the
>> KPU is not in use.
>
> I tried to use your syntax above initially but (if I remember correctly), the
> "reserved-memory" entry prevents the initial ram setup to add the kpu segment,
> so you can never see it as regular memory. So I dropped that and that memory is
> usable with the v1 of the series I sent. The soc_early_init() enables it by
> turning on pll1.
This seems like it could be fixed by writing a dummy driver for the KPU
which does nothing but release the memory region.
>
>>
>> However, I have been unable to get the AI ram to work; any time I
>> access it the CPU hangs. I have tried all combinations of
>>
>> * Enabling/disabling the AI clock
>> * Enabling/disabling PLL1 (the AI clock's parent) but not the AI clock
>> * Asserting/deasserting the KPU reset
>>
>> but I have not been able to get it working. Have you had any luck?
>
> See k210_soc_early_init() in drivers/soc/kendryte/k210-sysctl.c. That works.
> You did already point out the clock initialization that is not enough and
> working only because most of the values are the default. Maybe U-boot is
> changing some of them resulting in the worng clock frequencies being set in the
> kernel ?
My current clock setup when booted looks like
=> clk dump
Rate Id Usecnt Name
----------------------------------------------------
26000000 0 2 |-- osc
780000000 1 1 | |-- pll0
390000000 0 2 | | `-- pll0_half
390000000 42 6 | | |-- aclk
390000000 5 1 | | | |-- sram0
390000000 6 1 | | | |-- sram1
195000000 10 0 | | | |-- rom
390000000 13 0 | | | |-- dvp
195000000 7 2 | | | |-- apb0
195000000 15 0 | | | | |-- gpio
195000000 29 0 | | | | |-- uart1
195000000 30 0 | | | | |-- uart2
195000000 31 0 | | | | |-- uart3
195000000 33 1 | | | | |-- fpioa
195000000 39 0 | | | | `-- sha
195000000 8 1 | | | |-- apb1
195000000 32 0 | | | | |-- aes
195000000 40 0 | | | | `-- otp
195000000 9 1 | | | |-- apb2
390000000 4 2 | | | |-- cpu
390000000 11 0 | | | |-- dma
390000000 14 0 | | | `-- fft
97500000 19 0 | | |-- spi3
390000000 34 0 | | |-- timer0
390000000 35 0 | | |-- timer1
390000000 36 0 | | |-- timer2
390000000 16 0 | | |-- spi0
390000000 17 1 | | |-- spi1
390000000 18 0 | | |-- spi2
390000000 26 0 | | |-- i2c0
390000000 27 0 | | |-- i2c1
390000000 28 0 | | `-- i2c2
299000000 2 1 | |-- pll1
299000000 12 1 | | `-- ai
0 3 0 | |-- pll2
0 0 0 | | `-- pll2_half
0 20 0 | | |-- i2s0
0 21 0 | | |-- i2s1
0 22 0 | | |-- i2s2
0 23 0 | | |-- i2s0_m
0 24 0 | | |-- i2s1_m
0 25 0 | | `-- i2s2_m
13000000 0 0 | |-- in0_half
13000000 37 0 | | |-- wdt0
13000000 38 0 | | `-- wdt1
26000000 41 0 | `-- rtc
Perhaps I need PLL1 enabled but *not* AI. Alternatively, I have PLL1 set
to the default rate of 299 MHz. It could be a clock domain problem.
>>
>> There's also the issue that all DMAs should happen from the uncached
>> memory area, but I think there is some existing infrastructure to
>> "translate" IO addresses, so this doesn't need to be added to the device
>> tree.
>>
>> --Sean
>>
>>
>
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-03-02 5:25 ` Sean Anderson
@ 2020-03-02 5:43 ` Damien Le Moal
0 siblings, 0 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-03-02 5:43 UTC (permalink / raw)
To: Sean Anderson, Anup Patel
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 2020/03/02 14:25, Sean Anderson wrote:
> On 3/2/20 12:11 AM, Damien Le Moal wrote:
>> On 2020/03/02 14:02, Sean Anderson wrote:
>>> On 3/1/20 11:48 PM, Damien Le Moal wrote:
>>>> On 2020/03/02 13:17, Anup Patel wrote:
>>>>> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>>>
>>>>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>>>>> second cpu not coming up?
>>>>>>>
>>>>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>>>>> failure (if init is forking another shell especially).
>>>>>>
>>>>>> This should be before init comes up; when comparing this to your syslog
>>>>>> output there are several more messages before init gets started.
>>>>>>
>>>>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>>>>
>>>>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>>>>> on both cores, but something may be misconfigured on that end.
>>>>>
>>>>> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
>>>>> Linux NOMMU.
>>>>>
>>>>> Based on you log, it seems the second CPU is still spinning in U-Boot
>>>>> M-mode and when Linux NOMMU tries to touch memory where second
>>>>> CPU is spinning everything gets corrupted.
>>>>
>>>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
>>>> special as by default it is not usable as regular SRAM. I think it may be better
>>>> to reflect that in the device tree. The K210 soc_early_init() call back can
>>>> probe for that special entry too to see if it has to be turned on for use as
>>>> regular memory or not (i.e. if a kpu driver will use it).
>>>>
>>>> Since booting Linux with 6MB of memory will be even more challenging than with
>>>> 8, I agree that we may never see the case of a kpu driver being used. But I
>>>> personally like making that special case clear in the device tree. No strong
>>>> objection to your simplification though. So if you really object, I will go with it.
>>>
>>> The way I have it set up is like this
>>>
>>>
>>> sram0: memory@80000000 {
>>> device_type = "memory";
>>> compatible = "kendryte,k210-sram";
>>> reg = <0x80000000 0x400000>;
>>> clocks = <&sysclk K210_CLK_SRAM0>;
>>> };
>>>
>>> sram1: memory@80400000 {
>>> device_type = "memory";
>>> reg = <0x80400000 0x200000>;
>>> compatible = "kendryte,k210-sram";
>>> clocks = <&sysclk K210_CLK_SRAM1>;
>>> };
>>>
>>> airam: memory@80600000 {
>>> device_type = "memory";
>>> reg = <0x80600000 0x200000>;
>>> compatible = "kendryte,k210-airam";
>>> clocks = <&sysclk K210_CLK_AI>;
>>> };
>>>
>>> reserved-memory {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>>
>>> ai_reserved: ai@80600000 {
>>> reg = <0x80600000 0x200000>;
>>> reusable;
>>> };
>>> };>
>>> And then the kpu has 'memory-region = <&ai_reserved>;'. This way the
>>> memory is documented as being used by the kpu, but also free when the
>>> KPU is not in use.
>>
>> I tried to use your syntax above initially but (if I remember correctly), the
>> "reserved-memory" entry prevents the initial ram setup to add the kpu segment,
>> so you can never see it as regular memory. So I dropped that and that memory is
>> usable with the v1 of the series I sent. The soc_early_init() enables it by
>> turning on pll1.
>
> This seems like it could be fixed by writing a dummy driver for the KPU
> which does nothing but release the memory region.
>
>>
>>>
>>> However, I have been unable to get the AI ram to work; any time I
>>> access it the CPU hangs. I have tried all combinations of
>>>
>>> * Enabling/disabling the AI clock
>>> * Enabling/disabling PLL1 (the AI clock's parent) but not the AI clock
>>> * Asserting/deasserting the KPU reset
>>>
>>> but I have not been able to get it working. Have you had any luck?
>>
>> See k210_soc_early_init() in drivers/soc/kendryte/k210-sysctl.c. That works.
>> You did already point out the clock initialization that is not enough and
>> working only because most of the values are the default. Maybe U-boot is
>> changing some of them resulting in the worng clock frequencies being set in the
>> kernel ?
>
> My current clock setup when booted looks like
>
> => clk dump
> Rate Id Usecnt Name
> ----------------------------------------------------
> 26000000 0 2 |-- osc
> 780000000 1 1 | |-- pll0
> 390000000 0 2 | | `-- pll0_half
> 390000000 42 6 | | |-- aclk
> 390000000 5 1 | | | |-- sram0
> 390000000 6 1 | | | |-- sram1
> 195000000 10 0 | | | |-- rom
> 390000000 13 0 | | | |-- dvp
> 195000000 7 2 | | | |-- apb0
> 195000000 15 0 | | | | |-- gpio
> 195000000 29 0 | | | | |-- uart1
> 195000000 30 0 | | | | |-- uart2
> 195000000 31 0 | | | | |-- uart3
> 195000000 33 1 | | | | |-- fpioa
> 195000000 39 0 | | | | `-- sha
> 195000000 8 1 | | | |-- apb1
> 195000000 32 0 | | | | |-- aes
> 195000000 40 0 | | | | `-- otp
> 195000000 9 1 | | | |-- apb2
> 390000000 4 2 | | | |-- cpu
> 390000000 11 0 | | | |-- dma
> 390000000 14 0 | | | `-- fft
> 97500000 19 0 | | |-- spi3
> 390000000 34 0 | | |-- timer0
> 390000000 35 0 | | |-- timer1
> 390000000 36 0 | | |-- timer2
> 390000000 16 0 | | |-- spi0
> 390000000 17 1 | | |-- spi1
> 390000000 18 0 | | |-- spi2
> 390000000 26 0 | | |-- i2c0
> 390000000 27 0 | | |-- i2c1
> 390000000 28 0 | | `-- i2c2
> 299000000 2 1 | |-- pll1
> 299000000 12 1 | | `-- ai
> 0 3 0 | |-- pll2
> 0 0 0 | | `-- pll2_half
> 0 20 0 | | |-- i2s0
> 0 21 0 | | |-- i2s1
> 0 22 0 | | |-- i2s2
> 0 23 0 | | |-- i2s0_m
> 0 24 0 | | |-- i2s1_m
> 0 25 0 | | `-- i2s2_m
> 13000000 0 0 | |-- in0_half
> 13000000 37 0 | | |-- wdt0
> 13000000 38 0 | | `-- wdt1
> 26000000 41 0 | `-- rtc
>
> Perhaps I need PLL1 enabled but *not* AI. Alternatively, I have PLL1 set
> to the default rate of 299 MHz. It could be a clock domain problem.
I kind of remember reading that if you enable the AI clock, then the SRAM is not
usable as regular SRAM anymore and becomes reserved for the KPU. You need to
enable pll1 only for using it as regular mem. However, you mentioned that you
tried that already... Not sure what is going on.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 02/10] riscv: Force flat memory model with no-mmu
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
2020-02-14 20:18 ` Sean Anderson
2020-03-02 3:48 ` Anup Patel
@ 2020-03-04 18:38 ` Palmer Dabbelt
2 siblings, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 18:38 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:24 PST (-0800), Damien Le Moal wrote:
> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
> a nommu kernel. Since the sparsemem model does not make sense anyway
> for the nommu case, do not allow selecting this option to always use
> the flatmem model.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 73f029eae0cc..1a3b5a5276be 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE
>
> config ARCH_SPARSEMEM_ENABLE
> def_bool y
> + depends on MMU
> select SPARSEMEM_VMEMMAP_ENABLE
>
> config ARCH_SELECT_MEMORY_MODEL
Oh, this should go in fixes too. Thanks!
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
2020-03-02 3:57 ` Anup Patel
@ 2020-03-04 19:28 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:28 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:25 PST (-0800), Damien Le Moal wrote:
> Add handlers for unaligned load and stroe traps that may be generated
> by applications. Code heavily inspired from the OpenSBI project.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> ---
> arch/riscv/kernel/Makefile | 2 +-
> arch/riscv/kernel/traps.c | 27 +-
> arch/riscv/kernel/traps_misaligned.c | 371 +++++++++++++++++++++++++++
> 3 files changed, 396 insertions(+), 4 deletions(-)
> create mode 100644 arch/riscv/kernel/traps_misaligned.c
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index f40205cb9a22..97d0c35f8b37 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -28,7 +28,7 @@ obj-y += stacktrace.o
> obj-y += cacheinfo.o
> obj-$(CONFIG_MMU) += vdso.o vdso/
>
> -obj-$(CONFIG_RISCV_M_MODE) += clint.o
> +obj-$(CONFIG_RISCV_M_MODE) += clint.o traps_misaligned.o
> obj-$(CONFIG_FPU) += fpu.o
> obj-$(CONFIG_SMP) += smpboot.o
> obj-$(CONFIG_SMP) += smp.o
> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> index ffb3d94bf0cc..13e55459d7b0 100644
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -97,12 +97,33 @@ DO_ERROR_INFO(do_trap_insn_fault,
> SIGSEGV, SEGV_ACCERR, "instruction access fault");
> DO_ERROR_INFO(do_trap_insn_illegal,
> SIGILL, ILL_ILLOPC, "illegal instruction");
> -DO_ERROR_INFO(do_trap_load_misaligned,
> - SIGBUS, BUS_ADRALN, "load address misaligned");
> DO_ERROR_INFO(do_trap_load_fault,
> SIGSEGV, SEGV_ACCERR, "load access fault");
> +#ifndef CONFIG_RISCV_M_MODE
> +DO_ERROR_INFO(do_trap_load_misaligned,
> + SIGBUS, BUS_ADRALN, "Oops - load address misaligned");
> DO_ERROR_INFO(do_trap_store_misaligned,
> - SIGBUS, BUS_ADRALN, "store (or AMO) address misaligned");
> + SIGBUS, BUS_ADRALN, "Oops - store (or AMO) address misaligned");
> +#else
> +int handle_misaligned_load(struct pt_regs *regs);
> +int handle_misaligned_store(struct pt_regs *regs);
> +
> +asmlinkage void do_trap_load_misaligned(struct pt_regs *regs)
> +{
> + if (!handle_misaligned_load(regs))
> + return;
> + do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> + "Oops - load address misaligned");
> +}
> +
> +asmlinkage void do_trap_store_misaligned(struct pt_regs *regs)
> +{
> + if (!handle_misaligned_store(regs))
> + return;
> + do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> + "Oops - store (or AMO) address misaligned");
> +}
> +#endif
> DO_ERROR_INFO(do_trap_store_fault,
> SIGSEGV, SEGV_ACCERR, "store (or AMO) access fault");
> DO_ERROR_INFO(do_trap_ecall_u,
> diff --git a/arch/riscv/kernel/traps_misaligned.c b/arch/riscv/kernel/traps_misaligned.c
> new file mode 100644
> index 000000000000..a6105ee0150f
> --- /dev/null
> +++ b/arch/riscv/kernel/traps_misaligned.c
> @@ -0,0 +1,371 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/mm.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +
> +#include <asm/processor.h>
> +#include <asm/ptrace.h>
> +#include <asm/csr.h>
> +
> +#define INSN_MATCH_LB 0x3
> +#define INSN_MASK_LB 0x707f
> +#define INSN_MATCH_LH 0x1003
> +#define INSN_MASK_LH 0x707f
> +#define INSN_MATCH_LW 0x2003
> +#define INSN_MASK_LW 0x707f
> +#define INSN_MATCH_LD 0x3003
> +#define INSN_MASK_LD 0x707f
> +#define INSN_MATCH_LBU 0x4003
> +#define INSN_MASK_LBU 0x707f
> +#define INSN_MATCH_LHU 0x5003
> +#define INSN_MASK_LHU 0x707f
> +#define INSN_MATCH_LWU 0x6003
> +#define INSN_MASK_LWU 0x707f
> +#define INSN_MATCH_SB 0x23
> +#define INSN_MASK_SB 0x707f
> +#define INSN_MATCH_SH 0x1023
> +#define INSN_MASK_SH 0x707f
> +#define INSN_MATCH_SW 0x2023
> +#define INSN_MASK_SW 0x707f
> +#define INSN_MATCH_SD 0x3023
> +#define INSN_MASK_SD 0x707f
> +
> +#define INSN_MATCH_FLW 0x2007
> +#define INSN_MASK_FLW 0x707f
> +#define INSN_MATCH_FLD 0x3007
> +#define INSN_MASK_FLD 0x707f
> +#define INSN_MATCH_FLQ 0x4007
> +#define INSN_MASK_FLQ 0x707f
> +#define INSN_MATCH_FSW 0x2027
> +#define INSN_MASK_FSW 0x707f
> +#define INSN_MATCH_FSD 0x3027
> +#define INSN_MASK_FSD 0x707f
> +#define INSN_MATCH_FSQ 0x4027
> +#define INSN_MASK_FSQ 0x707f
> +
> +#define INSN_MATCH_C_LD 0x6000
> +#define INSN_MASK_C_LD 0xe003
> +#define INSN_MATCH_C_SD 0xe000
> +#define INSN_MASK_C_SD 0xe003
> +#define INSN_MATCH_C_LW 0x4000
> +#define INSN_MASK_C_LW 0xe003
> +#define INSN_MATCH_C_SW 0xc000
> +#define INSN_MASK_C_SW 0xe003
> +#define INSN_MATCH_C_LDSP 0x6002
> +#define INSN_MASK_C_LDSP 0xe003
> +#define INSN_MATCH_C_SDSP 0xe002
> +#define INSN_MASK_C_SDSP 0xe003
> +#define INSN_MATCH_C_LWSP 0x4002
> +#define INSN_MASK_C_LWSP 0xe003
> +#define INSN_MATCH_C_SWSP 0xc002
> +#define INSN_MASK_C_SWSP 0xe003
> +
> +#define INSN_MATCH_C_FLD 0x2000
> +#define INSN_MASK_C_FLD 0xe003
> +#define INSN_MATCH_C_FLW 0x6000
> +#define INSN_MASK_C_FLW 0xe003
> +#define INSN_MATCH_C_FSD 0xa000
> +#define INSN_MASK_C_FSD 0xe003
> +#define INSN_MATCH_C_FSW 0xe000
> +#define INSN_MASK_C_FSW 0xe003
> +#define INSN_MATCH_C_FLDSP 0x2002
> +#define INSN_MASK_C_FLDSP 0xe003
> +#define INSN_MATCH_C_FSDSP 0xa002
> +#define INSN_MASK_C_FSDSP 0xe003
> +#define INSN_MATCH_C_FLWSP 0x6002
> +#define INSN_MASK_C_FLWSP 0xe003
> +#define INSN_MATCH_C_FSWSP 0xe002
> +#define INSN_MASK_C_FSWSP 0xe003
> +
> +#define INSN_LEN(insn) ((((insn) & 0x3) < 0x3) ? 2 : 4)
> +
> +#if __riscv_xlen == 64
> +#define LOG_REGBYTES 3
> +#else
> +#define LOG_REGBYTES 2
> +#endif
> +#define REGBYTES (1 << LOG_REGBYTES)
> +
> +#define SH_RD 7
> +#define SH_RS1 15
> +#define SH_RS2 20
> +#define SH_RS2C 2
> +
> +#define RV_X(x, s, n) (((x) >> (s)) & ((1 << (n)) - 1))
> +#define RVC_LW_IMM(x) ((RV_X(x, 6, 1) << 2) | \
> + (RV_X(x, 10, 3) << 3) | \
> + (RV_X(x, 5, 1) << 6))
> +#define RVC_LD_IMM(x) ((RV_X(x, 10, 3) << 3) | \
> + (RV_X(x, 5, 2) << 6))
> +#define RVC_LWSP_IMM(x) ((RV_X(x, 4, 3) << 2) | \
> + (RV_X(x, 12, 1) << 5) | \
> + (RV_X(x, 2, 2) << 6))
> +#define RVC_LDSP_IMM(x) ((RV_X(x, 5, 2) << 3) | \
> + (RV_X(x, 12, 1) << 5) | \
> + (RV_X(x, 2, 3) << 6))
> +#define RVC_SWSP_IMM(x) ((RV_X(x, 9, 4) << 2) | \
> + (RV_X(x, 7, 2) << 6))
> +#define RVC_SDSP_IMM(x) ((RV_X(x, 10, 3) << 3) | \
> + (RV_X(x, 7, 3) << 6))
> +#define RVC_RS1S(insn) (8 + RV_X(insn, SH_RD, 3))
> +#define RVC_RS2S(insn) (8 + RV_X(insn, SH_RS2C, 3))
> +#define RVC_RS2(insn) RV_X(insn, SH_RS2C, 5)
> +
> +#define SHIFT_RIGHT(x, y) \
> + ((y) < 0 ? ((x) << -(y)) : ((x) >> (y)))
> +
> +#define REG_MASK \
> + ((1 << (5 + LOG_REGBYTES)) - (1 << LOG_REGBYTES))
> +
> +#define REG_OFFSET(insn, pos) \
> + (SHIFT_RIGHT((insn), (pos) - LOG_REGBYTES) & REG_MASK)
> +
> +#define REG_PTR(insn, pos, regs) \
> + (ulong *)((ulong)(regs) + REG_OFFSET(insn, pos))
> +
> +#define GET_RM(insn) (((insn) >> 12) & 7)
> +
> +#define GET_RS1(insn, regs) (*REG_PTR(insn, SH_RS1, regs))
> +#define GET_RS2(insn, regs) (*REG_PTR(insn, SH_RS2, regs))
> +#define GET_RS1S(insn, regs) (*REG_PTR(RVC_RS1S(insn), 0, regs))
> +#define GET_RS2S(insn, regs) (*REG_PTR(RVC_RS2S(insn), 0, regs))
> +#define GET_RS2C(insn, regs) (*REG_PTR(insn, SH_RS2C, regs))
> +#define GET_SP(regs) (*REG_PTR(2, 0, regs))
> +#define SET_RD(insn, regs, val) (*REG_PTR(insn, SH_RD, regs) = (val))
> +#define IMM_I(insn) ((s32)(insn) >> 20)
> +#define IMM_S(insn) (((s32)(insn) >> 25 << 5) | \
> + (s32)(((insn) >> 7) & 0x1f))
> +#define MASK_FUNCT3 0x7000
> +
> +#define GET_PRECISION(insn) (((insn) >> 25) & 3)
> +#define GET_RM(insn) (((insn) >> 12) & 7)
> +#define PRECISION_S 0
> +#define PRECISION_D 1
> +
> +#define STR(x) XSTR(x)
> +#define XSTR(x) #x
> +
> +#define DECLARE_UNPRIVILEGED_LOAD_FUNCTION(type, insn) \
> +static inline type load_##type(const type *addr) \
> +{ \
> + type val; \
> + asm (#insn " %0, %1" \
> + : "=&r" (val) : "m" (*addr)); \
> + return val; \
> +}
> +
> +#define DECLARE_UNPRIVILEGED_STORE_FUNCTION(type, insn) \
> +static inline void store_##type(type *addr, type val) \
> +{ \
> + asm volatile (#insn " %0, %1\n" \
> + : : "r" (val), "m" (*addr)); \
> +}
> +
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u8, lbu)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u16, lhu)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s8, lb)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s16, lh)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(s32, lw)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u8, sb)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u16, sh)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u32, sw)
> +#if __riscv_xlen == 64
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u32, lwu)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u64, ld)
> +DECLARE_UNPRIVILEGED_STORE_FUNCTION(u64, sd)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(ulong, ld)
> +#else
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(u32, lw)
> +DECLARE_UNPRIVILEGED_LOAD_FUNCTION(ulong, lw)
> +
> +static inline u64 load_u64(const u64 *addr)
> +{
> + return load_u32((u32 *)addr)
> + + ((u64)load_u32((u32 *)addr + 1) << 32);
> +}
> +
> +static inline void store_u64(u64 *addr, u64 val)
> +{
> + store_u32((u32 *)addr, val);
> + store_u32((u32 *)addr + 1, val >> 32);
> +}
> +#endif
> +
> +static inline ulong get_insn(ulong mepc)
> +{
> + register ulong __mepc asm ("a2") = mepc;
> + ulong val, rvc_mask = 3, tmp;
> +
> + asm ("and %[tmp], %[addr], 2\n"
> + "bnez %[tmp], 1f\n"
> +#if __riscv_xlen == 64
> + STR(LWU) " %[insn], (%[addr])\n"
> +#else
> + STR(LW) " %[insn], (%[addr])\n"
> +#endif
> + "and %[tmp], %[insn], %[rvc_mask]\n"
> + "beq %[tmp], %[rvc_mask], 2f\n"
> + "sll %[insn], %[insn], %[xlen_minus_16]\n"
> + "srl %[insn], %[insn], %[xlen_minus_16]\n"
> + "j 2f\n"
> + "1:\n"
> + "lhu %[insn], (%[addr])\n"
> + "and %[tmp], %[insn], %[rvc_mask]\n"
> + "bne %[tmp], %[rvc_mask], 2f\n"
> + "lhu %[tmp], 2(%[addr])\n"
> + "sll %[tmp], %[tmp], 16\n"
> + "add %[insn], %[insn], %[tmp]\n"
> + "2:"
> + : [insn] "=&r" (val), [tmp] "=&r" (tmp)
> + : [addr] "r" (__mepc), [rvc_mask] "r" (rvc_mask),
> + [xlen_minus_16] "i" (__riscv_xlen - 16));
> +
> + return val;
> +}
> +
> +union reg_data {
> + u8 data_bytes[8];
> + ulong data_ulong;
> + u64 data_u64;
> +};
> +
> +int handle_misaligned_load(struct pt_regs *regs)
> +{
> + union reg_data val;
> + unsigned long epc = regs->epc;
> + unsigned long insn = get_insn(epc);
> + unsigned long addr = csr_read(mtval);
> + int i, fp = 0, shift = 0, len = 0;
> +
> + regs->epc = 0;
> +
> + if ((insn & INSN_MASK_LW) == INSN_MATCH_LW) {
> + len = 4;
> + shift = 8 * (sizeof(unsigned long) - len);
> +#if __riscv_xlen == 64
> + } else if ((insn & INSN_MASK_LD) == INSN_MATCH_LD) {
> + len = 8;
> + shift = 8 * (sizeof(unsigned long) - len);
> + } else if ((insn & INSN_MASK_LWU) == INSN_MATCH_LWU) {
> + len = 4;
> +#endif
> + } else if ((insn & INSN_MASK_FLD) == INSN_MATCH_FLD) {
> + fp = 1;
> + len = 8;
> + } else if ((insn & INSN_MASK_FLW) == INSN_MATCH_FLW) {
> + fp = 1;
> + len = 4;
> + } else if ((insn & INSN_MASK_LH) == INSN_MATCH_LH) {
> + len = 2;
> + shift = 8 * (sizeof(unsigned long) - len);
> + } else if ((insn & INSN_MASK_LHU) == INSN_MATCH_LHU) {
> + len = 2;
> +#ifdef __riscv_compressed
> +#if __riscv_xlen >= 64
> + } else if ((insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD) {
> + len = 8;
> + shift = 8 * (sizeof(unsigned long) - len);
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 8;
> + shift = 8 * (sizeof(unsigned long) - len);
> +#endif
> + } else if ((insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW) {
> + len = 4;
> + shift = 8 * (sizeof(unsigned long) - len);
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 4;
> + shift = 8 * (sizeof(unsigned long) - len);
> + } else if ((insn & INSN_MASK_C_FLD) == INSN_MATCH_C_FLD) {
> + fp = 1;
> + len = 8;
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_FLDSP) == INSN_MATCH_C_FLDSP) {
> + fp = 1;
> + len = 8;
> +#if __riscv_xlen == 32
> + } else if ((insn & INSN_MASK_C_FLW) == INSN_MATCH_C_FLW) {
> + fp = 1;
> + len = 4;
> + insn = RVC_RS2S(insn) << SH_RD;
> + } else if ((insn & INSN_MASK_C_FLWSP) == INSN_MATCH_C_FLWSP) {
> + fp = 1;
> + len = 4;
> +#endif
> +#endif
> + } else {
> + regs->epc = epc;
> + return -1;
> + }
> +
> + val.data_u64 = 0;
> + for (i = 0; i < len; i++)
> + val.data_bytes[i] = load_u8((void *)(addr + i));
> +
> + if (fp)
> + return -1;
> + SET_RD(insn, regs, val.data_ulong << shift >> shift);
> +
> + regs->epc = epc + INSN_LEN(insn);
> +
> + return 0;
> +}
> +
> +int handle_misaligned_store(struct pt_regs *regs)
> +{
> + union reg_data val;
> + unsigned long epc = regs->epc;
> + unsigned long insn = get_insn(epc);
> + unsigned long addr = csr_read(mtval);
> + int i, len = 0;
> +
> + regs->epc = 0;
> +
> + val.data_ulong = GET_RS2(insn, regs);
> +
> + if ((insn & INSN_MASK_SW) == INSN_MATCH_SW) {
> + len = 4;
> +#if __riscv_xlen == 64
> + } else if ((insn & INSN_MASK_SD) == INSN_MATCH_SD) {
> + len = 8;
> +#endif
> + } else if ((insn & INSN_MASK_SH) == INSN_MATCH_SH) {
> + len = 2;
> +#ifdef __riscv_compressed
CONFIG_RISCV_ISA_C (which sets __riscv_compressed) selects the ISA that the
kernel is compiled for, not the ISA userspace is compiled for. As such it is
expected that !CONFIG_RISCV_ISA_C kernels can run C userspace, and breaking
that assumption in such a subtle way seems like a bad idea.
Having some sort of "block C from userspace" sort of Kconfig seems reasonable,
but that should be some different option. We could fake this now by filtering
the ELF auxvec, and we should probably add an SBI call that attempts to disable
an ISA extension for a hart sooner rather than later.
I know it's a bit pedantic as M-mode kernels mean NOMMU kernels, but I'm still
hoping to break that coupling.
> +#if __riscv_xlen >= 64
> + } else if ((insn & INSN_MASK_C_SD) == INSN_MATCH_C_SD) {
> + len = 8;
> + val.data_ulong = GET_RS2S(insn, regs);
> + } else if ((insn & INSN_MASK_C_SDSP) == INSN_MATCH_C_SDSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 8;
> + val.data_ulong = GET_RS2C(insn, regs);
> +#endif
> + } else if ((insn & INSN_MASK_C_SW) == INSN_MATCH_C_SW) {
> + len = 4;
> + val.data_ulong = GET_RS2S(insn, regs);
> + } else if ((insn & INSN_MASK_C_SWSP) == INSN_MATCH_C_SWSP &&
> + ((insn >> SH_RD) & 0x1f)) {
> + len = 4;
> + val.data_ulong = GET_RS2C(insn, regs);
> +#endif
> + } else {
> + regs->epc = epc;
> + return -1;
> + }
> +
> + for (i = 0; i < len; i++)
> + store_u8((void *)(addr + i), val.data_bytes[i]);
> +
> + regs->epc = epc + INSN_LEN(insn);
> +
> + return 0;
> +}
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 05/10] riscv: Add SOC early init support
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
@ 2020-03-04 19:28 ` Palmer Dabbelt
0 siblings, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:28 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:27 PST (-0800), Damien Le Moal wrote:
> Add a mechanism for early SoC initialization for platforms that need
> additional hardware initialization not possible through the regular
> device tree and drivers mechanism. With this, a SoC specific
> initialization function can be called very early, before DTB parsing
> is done by parse_dtb() in Linux RISC-V kernel setup code.
>
> This can be very useful for early hardware initialization for No-MMU
> kernels booted directly in M-mode because it is quite likely that no
> other booting stage exist prior to the No-MMU kernel.
>
> Example use of a SoC early initialization is as follows:
>
> static void vendor_abc_early_init(const void *fdt)
> {
> /*
> * some early init code here that can use simple matches
> * against the flat device tree file.
> */
> }
> SOC_EARLY_INIT_DECLARE("vendor,abc", abc_early_init);
>
> This early initialization function is executed only if the flat device
> tree for the board has a 'compatible = "vendor,abc"' entry;
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> ---
> arch/riscv/include/asm/soc.h | 23 +++++++++++++++++++++++
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/head.S | 1 +
> arch/riscv/kernel/soc.c | 28 ++++++++++++++++++++++++++++
> arch/riscv/kernel/vmlinux.lds.S | 6 ++++++
> 5 files changed, 59 insertions(+)
> create mode 100644 arch/riscv/include/asm/soc.h
> create mode 100644 arch/riscv/kernel/soc.c
>
> diff --git a/arch/riscv/include/asm/soc.h b/arch/riscv/include/asm/soc.h
> new file mode 100644
> index 000000000000..9b8c332cbe76
> --- /dev/null
> +++ b/arch/riscv/include/asm/soc.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +#ifndef _ASM_RISCV_SOC_H
> +#define _ASM_RISCV_SOC_H
> +
> +#include <linux/of.h>
> +#include <linux/linkage.h>
> +#include <linux/types.h>
> +
> +#define SOC_EARLY_INIT_DECLARE(compat, fn) \
> + static const struct of_device_id __soc_early_init \
> + __used __section(__soc_early_init_table) \
> + = { .compatible = compat, .data = fn }
> +
> +void soc_early_init(void);
> +
> +extern unsigned long __soc_early_init_table_start;
> +extern unsigned long __soc_early_init_table_end;
> +
> +#endif
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index 97d0c35f8b37..e4a22999dbc6 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -10,6 +10,7 @@ endif
> extra-y += head.o
> extra-y += vmlinux.lds
>
> +obj-y += soc.o
> obj-y += cpu.o
> obj-y += cpufeature.o
> obj-y += entry.o
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index 271860fc2c3f..a7768d6165d4 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -125,6 +125,7 @@ clear_bss_done:
> call kasan_early_init
> #endif
> /* Start the kernel */
> + call soc_early_init
> call parse_dtb
> tail start_kernel
>
> diff --git a/arch/riscv/kernel/soc.c b/arch/riscv/kernel/soc.c
> new file mode 100644
> index 000000000000..0b3b3dc9ad0f
> --- /dev/null
> +++ b/arch/riscv/kernel/soc.c
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/init.h>
> +#include <linux/libfdt.h>
> +#include <asm/pgtable.h>
> +#include <asm/soc.h>
> +
> +/*
> + * This is called extremly early, before parse_dtb(), to allow initializing
> + * SoC hardware before memory or any device driver initialization.
> + */
> +void __init soc_early_init(void)
> +{
> + void (*early_fn)(const void *fdt);
> + const struct of_device_id *s;
> + const void *fdt = dtb_early_va;
> +
> + for (s = (void *)&__soc_early_init_table_start;
> + (void *)s < (void *)&__soc_early_init_table_end; s++) {
> + if (!fdt_node_check_compatible(fdt, 0, s->compatible)) {
> + early_fn = s->data;
> + early_fn(fdt);
> + return;
> + }
> + }
> +}
> diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
> index 1e0193ded420..32b160942f40 100644
> --- a/arch/riscv/kernel/vmlinux.lds.S
> +++ b/arch/riscv/kernel/vmlinux.lds.S
> @@ -24,6 +24,12 @@ SECTIONS
> HEAD_TEXT_SECTION
> INIT_TEXT_SECTION(PAGE_SIZE)
> INIT_DATA_SECTION(16)
> + . = ALIGN(8);
> + __soc_early_init_table : {
> + __soc_early_init_table_start = .;
> + KEEP(*(__soc_early_init_table))
> + __soc_early_init_table_end = .;
> + }
> /* we have to discard exit text and such at runtime, not link time */
> .exit.text :
> {
I suppose my only worry here is that __init isn't going to be sufficient for
these sorts of fixups on all systems so we'll need something more special, but
that's just speculation so let's cross that bridge when we come to it.
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Thanks!
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
2020-03-02 3:58 ` Anup Patel
@ 2020-03-04 19:28 ` Palmer Dabbelt
2020-03-05 4:58 ` Anup Patel
1 sibling, 1 reply; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:28 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
> Enable a kernel builtin dtb for boards not capable of providing a
> device tree to the kernel.
I'd prefer if we picked a mechanism that allows a single kernel binary to be
run on multiple systems. I think there's two use cases here:
* Bootloaders that provide no DTB at all.
* Bootloaders that provied a DTB that, for some reason, isn't usable.
Given those constraints, could we do something similar to the early fixups?
I'm thinking we could build a mapping between a hardware identifier and a DTB,
then look up the DTB we want to use. Users that want a kernel that only runs
on a single device can do so by configuring only a single DTB, users that want
a more portable kernel can select a bunch -- that's essentially the same as how
we're treating everything else (for example, the CONFIG_SOC_* stuff).
For the hardware ID, could we do something like:
* Check for the top-level DT compatible string, on systems where we have a
provided DTB.
* Check for a matching mimpid/marchid/mvendorid tuple, maybe with some sort of
masking functionality if we later need one. These are availiable via SBI
calls, but I'd be inclined to restrict them to M-mode boot and just say the
SBI must provide a device tree with at least a suitable compatible string.
While I suppose we could put together a tool for generating these tables, for
now we could probably just stick the mappings in a table for now given that
there's only one of them.
That said, I'm not sure what to do about the different Kendryte boards -- is
there any way to poke the hardware to see which is which?
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kbuild | 1 +
> arch/riscv/Kconfig | 18 ++++++++++++++++++
> arch/riscv/boot/dts/Makefile | 4 ++++
> arch/riscv/kernel/setup.c | 6 ++++++
> arch/riscv/mm/init.c | 4 ++++
> 5 files changed, 33 insertions(+)
>
> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
> index d1d0aa70fdf1..988804e430e4 100644
> --- a/arch/riscv/Kbuild
> +++ b/arch/riscv/Kbuild
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> obj-y += kernel/ mm/ net/
> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 1a3b5a5276be..28899e15f548 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
>
> endchoice
>
> +config USE_BUILTIN_DTB
> + bool "Use builtin DTB"
> + help
> + Link a device tree blob for particular hardware into the kernel,
> + suppressing use of the DTB pointer provided by the bootloader.
> + This option should only be used with hardware or bootloaders that
> + are not capable of providing a DTB to the kernel, or for
> + experimental hardware without stable device tree bindings.
> +
> +config BUILTIN_DTB_SOURCE
> + string "Source file for builtin DTB"
> + default ""
> + depends on USE_BUILTIN_DTB
> + help
> + Base name (without suffix, relative to arch/riscv/boot/dts) for
> + the a DTS file that will be used to produce the DTB linked into
> + the kernel.
> +
> endmenu
>
> menu "Power management options"
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index dcc3ada78455..0bf2669aa12d 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -1,2 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> +else
> subdir-y += sifive
> +endif
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 0a6d415b0a5a..3e89be9d888c 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
>
> setup_bootmem();
> paging_init();
> +
> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> + unflatten_and_copy_device_tree();
> +#else
> unflatten_device_tree();
> +#endif
> +
> clint_init_boot_cpu();
>
> #ifdef CONFIG_SWIOTLB
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 965a8cf4829c..1274e889d008 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void)
> #else
> asmlinkage void __init setup_vm(uintptr_t dtb_pa)
> {
> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> + dtb_early_va = __dtb_start;
> +#else
> dtb_early_va = (void *)dtb_pa;
> +#endif
> }
>
> static inline void setup_vm_final(void)
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 06/10] riscv: Add Kendryte K210 SoC support
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
2020-02-14 20:31 ` Sean Anderson
@ 2020-03-04 19:38 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:38 UTC (permalink / raw)
To: Damien Le Moal, Olof Johansson, Arnd Bergmann, tglx, gregkh
Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:28 PST (-0800), Damien Le Moal wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> Add support for the Kendryte K210 RISC-V SoC. For now, this support
> only provides a simple sysctl driver allowing to setup the CPU and
> uart clock. This support is enabled through the new Kconfig option
> SOC_KENDRYTE and defines the config option CONFIG_K210_SYSCTL
> to enable the K210 SoC sysctl driver compilation.
>
> The sysctl driver also registers an early SoC initialization function
> allowing enabling the general purpose use of the 2MB of SRAM normally
> reserved for the SoC AI engine. This initialization function is
> automatically called before the dt early initialization using the flat
> dt root node compatible property matching the value "kendryte,k210".
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig.socs | 6 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/kendryte/Kconfig | 14 ++
> drivers/soc/kendryte/Makefile | 3 +
> drivers/soc/kendryte/k210-sysctl.c | 245 +++++++++++++++++++++++++++++
> 6 files changed, 270 insertions(+)
> create mode 100644 drivers/soc/kendryte/Kconfig
> create mode 100644 drivers/soc/kendryte/Makefile
> create mode 100644 drivers/soc/kendryte/k210-sysctl.c
+Olof, Arnd, Thomas, and Greg (from get-maintainers)
LMK if you want this to go in through the RISC-V tree -- I can keep it
building, but I don't have hardware to test on. If you want to take it,
otherwise
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
either way
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Thanks!
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index d325b67d00df..4d5d4a65b2a2 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -10,4 +10,10 @@ config SOC_SIFIVE
> help
> This enables support for SiFive SoC platform hardware.
>
> +config SOC_KENDRYTE
> + bool "Kendryte K210 SoC"
> + depends on !MMU
> + help
> + This enables support for Kendryte K210 SoC hardware.
> +
> endmenu
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 1778f8c62861..425ab6f7e375 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -22,5 +22,6 @@ source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> source "drivers/soc/xilinx/Kconfig"
> source "drivers/soc/zte/Kconfig"
> +source "drivers/soc/kendryte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 8b49d782a1ab..af58063bb989 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> obj-y += xilinx/
> obj-$(CONFIG_ARCH_ZX) += zte/
> +obj-$(CONFIG_SOC_KENDRYTE) += kendryte/
> diff --git a/drivers/soc/kendryte/Kconfig b/drivers/soc/kendryte/Kconfig
> new file mode 100644
> index 000000000000..49785b1b0217
> --- /dev/null
> +++ b/drivers/soc/kendryte/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_KENDRYTE
> +
> +config K210_SYSCTL
> + bool "Kendryte K210 system controller"
> + default y
> + depends on RISCV
> + help
> + Enables controlling the K210 various clocks and to enable
> + general purpose use of the extra 2MB of SRAM normally
> + reserved for the AI engine.
> +
> +endif
> diff --git a/drivers/soc/kendryte/Makefile b/drivers/soc/kendryte/Makefile
> new file mode 100644
> index 000000000000..002d9ce95c0d
> --- /dev/null
> +++ b/drivers/soc/kendryte/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_K210_SYSCTL) += k210-sysctl.o
> diff --git a/drivers/soc/kendryte/k210-sysctl.c b/drivers/soc/kendryte/k210-sysctl.c
> new file mode 100644
> index 000000000000..7d4ecd954af0
> --- /dev/null
> +++ b/drivers/soc/kendryte/k210-sysctl.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2019 Christoph Hellwig.
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/types.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <asm/soc.h>
> +
> +#define K210_SYSCTL_CLK0_FREQ 26000000UL
> +
> +/* Registers base address */
> +#define K210_SYSCTL_SYSCTL_BASE_ADDR 0x50440000ULL
> +
> +/* Registers */
> +#define K210_SYSCTL_PLL0 0x08
> +#define K210_SYSCTL_PLL1 0x0c
> +/* clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
> +#define PLL_RESET (1 << 20)
> +#define PLL_PWR (1 << 21)
> +#define PLL_INTFB (1 << 22)
> +#define PLL_BYPASS (1 << 23)
> +#define PLL_TEST (1 << 24)
> +#define PLL_OUT_EN (1 << 25)
> +#define PLL_TEST_EN (1 << 26)
> +#define K210_SYSCTL_PLL_LOCK 0x18
> +#define PLL0_LOCK1 (1 << 0)
> +#define PLL0_LOCK2 (1 << 1)
> +#define PLL0_SLIP_CLEAR (1 << 2)
> +#define PLL0_TEST_CLK_OUT (1 << 3)
> +#define PLL1_LOCK1 (1 << 8)
> +#define PLL1_LOCK2 (1 << 9)
> +#define PLL1_SLIP_CLEAR (1 << 10)
> +#define PLL1_TEST_CLK_OUT (1 << 11)
> +#define PLL2_LOCK1 (1 << 16)
> +#define PLL2_LOCK2 (1 << 16)
> +#define PLL2_SLIP_CLEAR (1 << 18)
> +#define PLL2_TEST_CLK_OUT (1 << 19)
> +#define K210_SYSCTL_CLKSEL0 0x20
> +#define CLKSEL_ACLK (1 << 0)
> +#define K210_SYSCTL_CLKEN_CENT 0x28
> +#define CLKEN_CPU (1 << 0)
> +#define CLKEN_SRAM0 (1 << 1)
> +#define CLKEN_SRAM1 (1 << 2)
> +#define CLKEN_APB0 (1 << 3)
> +#define CLKEN_APB1 (1 << 4)
> +#define CLKEN_APB2 (1 << 5)
> +#define K210_SYSCTL_CLKEN_PERI 0x2c
> +#define CLKEN_ROM (1 << 0)
> +#define CLKEN_DMA (1 << 1)
> +#define CLKEN_AI (1 << 2)
> +#define CLKEN_DVP (1 << 3)
> +#define CLKEN_FFT (1 << 4)
> +#define CLKEN_GPIO (1 << 5)
> +#define CLKEN_SPI0 (1 << 6)
> +#define CLKEN_SPI1 (1 << 7)
> +#define CLKEN_SPI2 (1 << 8)
> +#define CLKEN_SPI3 (1 << 9)
> +#define CLKEN_I2S0 (1 << 10)
> +#define CLKEN_I2S1 (1 << 11)
> +#define CLKEN_I2S2 (1 << 12)
> +#define CLKEN_I2C0 (1 << 13)
> +#define CLKEN_I2C1 (1 << 14)
> +#define CLKEN_I2C2 (1 << 15)
> +#define CLKEN_UART1 (1 << 16)
> +#define CLKEN_UART2 (1 << 17)
> +#define CLKEN_UART3 (1 << 18)
> +#define CLKEN_AES (1 << 19)
> +#define CLKEN_FPIO (1 << 20)
> +#define CLKEN_TIMER0 (1 << 21)
> +#define CLKEN_TIMER1 (1 << 22)
> +#define CLKEN_TIMER2 (1 << 23)
> +#define CLKEN_WDT0 (1 << 24)
> +#define CLKEN_WDT1 (1 << 25)
> +#define CLKEN_SHA (1 << 26)
> +#define CLKEN_OTP (1 << 27)
> +#define CLKEN_RTC (1 << 29)
> +
> +struct k210_sysctl {
> + void __iomem *regs;
> + struct clk_hw hw;
> +};
> +
> +static void k210_set_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) | val, reg);
> +}
> +
> +static void k210_clear_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) & ~val, reg);
> +}
> +
> +static void k210_pll1_enable(void __iomem *regs)
> +{
> + u32 val;
> +
> + val = readl(regs + K210_SYSCTL_PLL1);
> + val &= ~0xfffff;
> + val |= (59 << 4) | (3 << 10) | (59 << 15);
> + writel(val, regs + K210_SYSCTL_PLL1);
> +
> + k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
> +
> + /*
> + * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
> + */
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + nop();
> + nop();
I don't actually have one of these to test this on.
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> +
> + for (;;) {
> + val = readl(regs + K210_SYSCTL_PLL_LOCK);
> + if (val & PLL1_LOCK2)
> + break;
> + writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
> + }
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
> +}
> +
> +static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
> + u32 clksel0, pll0;
> + u64 pll0_freq, clkr0, clkf0, clkod0;
> +
> + /*
> + * If the clock selector is not set, use the base frequency.
> + * Otherwise, use PLL0 frequency with a frequency divisor.
> + */
> + clksel0 = readl(s->regs + K210_SYSCTL_CLKSEL0);
> + if (!(clksel0 & CLKSEL_ACLK))
> + return K210_SYSCTL_CLK0_FREQ;
> +
> + /*
> + * Get PLL0 frequency:
> + * freq = base frequency * clkf0 / (clkr0 * clkod0)
> + */
> + pll0 = readl(s->regs + K210_SYSCTL_PLL0);
> + clkr0 = 1 + (pll0 & 0x0000000f);
> + clkf0 = 1 + ((pll0 & 0x000003f0) >> 4);
> + clkod0 = 1 + ((pll0 & 0x00003c00) >> 10);
> + pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
> +
> + /* Get the frequency divisor from the clock selector */
> + return pll0_freq / (2ULL << ((clksel0 & 0x00000006) >> 1));
> +}
> +
> +static const struct clk_ops k210_sysctl_clk_ops = {
> + .recalc_rate = k210_sysctl_clk_recalc_rate,
> +};
> +
> +static const struct clk_init_data k210_clk_init_data = {
> + .name = "k210-sysctl-pll1",
> + .ops = &k210_sysctl_clk_ops,
> +};
> +
> +static int k210_sysctl_probe(struct platform_device *pdev)
> +{
> + struct k210_sysctl *s;
> + int error;
> +
> + pr_info("Kendryte K210 SoC sysctl\n");
> +
> + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> + if (!s)
> + return -ENOMEM;
> +
> + s->regs = devm_ioremap_resource(&pdev->dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> + if (IS_ERR(s->regs))
> + return PTR_ERR(s->regs);
> +
> + s->hw.init = &k210_clk_init_data;
> + error = devm_clk_hw_register(&pdev->dev, &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "failed to register clk");
> + return error;
> + }
> +
> + error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
> + &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "adding clk provider failed\n");
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id k210_sysctl_of_match[] = {
> + { .compatible = "kendryte,k210-sysctl", },
> + {}
> +};
> +
> +static struct platform_driver k210_sysctl_driver = {
> + .driver = {
> + .name = "k210-sysctl",
> + .of_match_table = k210_sysctl_of_match,
> + },
> + .probe = k210_sysctl_probe,
> +};
> +
> +static int __init k210_sysctl_init(void)
> +{
> + return platform_driver_register(&k210_sysctl_driver);
> +}
> +core_initcall(k210_sysctl_init);
> +
> +/*
> + * This needs to be called very early during initialization, given that
> + * PLL1 needs to be enabled to be able to use all SRAM.
> + */
> +static void __init k210_soc_early_init(const void *fdt)
> +{
> + void __iomem *regs;
> +
> + regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
> + if (!regs)
> + panic("K210 sysctl ioremap");
> +
> + /* Enable PLL1 to make the KPU SRAM useable */
> + k210_pll1_enable(regs);
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
> +
> + k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
> + regs + K210_SYSCTL_CLKEN_CENT);
> + k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
> + regs + K210_SYSCTL_CLKEN_PERI);
> +
> + k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_CLKSEL0);
> +
> + iounmap(regs);
> +}
> +SOC_EARLY_INIT_DECLARE("kendryte,k210", k210_soc_early_init);
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 07/10] riscv: Select required drivers for Kendryte SOC
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
2020-03-02 3:59 ` Anup Patel
@ 2020-03-04 19:44 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:44 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:29 PST (-0800), Damien Le Moal wrote:
> This patch selects drivers required for the Kendryte K210 SOC.
>
> Since K210 based boards do not provide a device tree, this patch
> also enables the BUILTIN_DTB option.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig.socs | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index 4d5d4a65b2a2..8d83210467d9 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -13,6 +13,10 @@ config SOC_SIFIVE
> config SOC_KENDRYTE
> bool "Kendryte K210 SoC"
> depends on !MMU
> + select BUILTIN_DTB
> + select SERIAL_SIFIVE if TTY
> + select SERIAL_SIFIVE_CONSOLE if TTY
> + select SIFIVE_PLIC
> help
> This enables support for Kendryte K210 SoC hardware.
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
(modulo that option actually existing :))
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
2020-02-14 20:51 ` Sean Anderson
2020-03-02 4:06 ` Anup Patel
@ 2020-03-04 19:44 ` Palmer Dabbelt
2 siblings, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:44 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:30 PST (-0800), Damien Le Moal wrote:
> Add a generic device tree for Kendryte K210 SoC based boards. This (for
> now) very simple device tree works for the Kendryte KD233 development
> board, the Sipeed MAIX M1 Dock based boards and the Sipeed MAIXDUINO
> board.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/kendryte/Makefile | 2 +
> arch/riscv/boot/dts/kendryte/k210.dts | 23 +++++
> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 +++++++++++++++++++++++++
> 4 files changed, 149 insertions(+)
> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
OK, so if the same DTB works for all of these anyway then that at least lets us
kick the can down the road on the "how to look up a DT for a board" problem.
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index 0bf2669aa12d..87815557f2db 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -3,4 +3,5 @@ ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> else
> subdir-y += sifive
> +subdir-y += kendryte
> endif
> diff --git a/arch/riscv/boot/dts/kendryte/Makefile b/arch/riscv/boot/dts/kendryte/Makefile
> new file mode 100644
> index 000000000000..815444e69e89
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_SOC_KENDRYTE) += k210.dtb
> diff --git a/arch/riscv/boot/dts/kendryte/k210.dts b/arch/riscv/boot/dts/kendryte/k210.dts
> new file mode 100644
> index 000000000000..0d1f28fce6b2
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/k210.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +/dts-v1/;
> +
> +#include "k210.dtsi"
> +
> +/ {
> + model = "Kendryte K210 generic";
> + compatible = "kendryte,k210";
> +
> + chosen {
> + bootargs = "earlycon console=ttySIF0";
> + stdout-path = "serial0";
> + };
> +};
> +
> +&uarths0 {
> + status = "okay";
> +};
> +
> diff --git a/arch/riscv/boot/dts/kendryte/k210.dtsi b/arch/riscv/boot/dts/kendryte/k210.dtsi
> new file mode 100644
> index 000000000000..4b9eeabb07f7
> --- /dev/null
> +++ b/arch/riscv/boot/dts/kendryte/k210.dtsi
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> + */
> +
> +/ {
> + /*
> + * Although the K210 is a 64-bit CPU, the address bus is only 32-bits
> + * wide, and the upper half of all addresses is ignored.
> + */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "kendryte,k210";
> +
> + aliases {
> + serial0 = &uarths0;
> + };
> +
> + clocks {
> + in0: oscillator {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <26000000>;
> + };
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <7800000>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "none";
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <64>; /* bogus */
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <64>; /* bogus */
> + clocks = <&sysctl 0>;
> + clock-frequency = <390000000>;
> + cpu0_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + reg = <1>;
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "none";
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <64>; /* bogus */
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <64>; /* bogus */
> + clocks = <&sysctl 0>;
> + clock-frequency = <390000000>;
> + cpu1_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + };
> +
> + sram0: memory@80000000 {
> + device_type = "memory";
> + reg = <0x80000000 0x400000>;
> + };
> +
> + sram1: memory@80400000 {
> + device_type = "memory";
> + reg = <0x80400000 0x200000>;
> + };
> +
> + kpu_sram: memory@80600000 {
> + device_type = "memory";
> + reg = <0x80600000 0x200000>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "kendryte,k210-soc", "simple-bus";
> + ranges;
> + interrupt-parent = <&plic0>;
> +
> + sysctl: sysctl@50440000 {
> + compatible = "kendryte,k210-sysctl", "syscon";
> + reg = <0x50440000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + clint0: interrupt-controller@2000000 {
> + compatible = "riscv,clint0";
> + reg = <0x2000000 0xC000>;
> + interrupts-extended = <&cpu0_intc 3>, <&cpu1_intc 3>;
> + clocks = <&sysctl 0>;
> + };
> +
> + plic0: interrupt-controller@c000000 {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "kendryte,k210-plic0", "riscv,plic0";
> + reg = <0xC000000 0x3FFF008>;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
> + <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
> + riscv,ndev = <65>;
> + riscv,max-priority = <0x07>;
> + };
> +
> + uarths0: serial@38000000 {
> + compatible = "kendryte,k210-uart0", "sifive,uart0";
> + reg = <0x38000000 0x20>;
> + interrupts = <33>;
> + clocks = <&sysctl 0>;
> + };
> + };
> +};
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 09/10] riscv: Kendryte K210 default config
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
2020-03-02 4:07 ` Anup Patel
@ 2020-03-04 19:44 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:44 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:31 PST (-0800), Damien Le Moal wrote:
> The patch adds defconfig to build No-MMU kernel meant for
> Kendryte K210 SoC.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/configs/nommu_k210_defconfig | 68 +++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 arch/riscv/configs/nommu_k210_defconfig
>
> diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
> new file mode 100644
> index 000000000000..00ded8f0bc55
> --- /dev/null
> +++ b/arch/riscv/configs/nommu_k210_defconfig
> @@ -0,0 +1,68 @@
> +# CONFIG_CPU_ISOLATION is not set
> +CONFIG_LOG_BUF_SHIFT=15
> +CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_INITRAMFS_SOURCE="k210.cpio"
> +CONFIG_INITRAMFS_FORCE=y
> +# CONFIG_RD_BZIP2 is not set
> +# CONFIG_RD_LZMA is not set
> +# CONFIG_RD_XZ is not set
> +# CONFIG_RD_LZO is not set
> +# CONFIG_RD_LZ4 is not set
> +# CONFIG_BOOT_CONFIG is not set
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +# CONFIG_SYSFS_SYSCALL is not set
> +# CONFIG_FHANDLE is not set
> +# CONFIG_BASE_FULL is not set
> +# CONFIG_EPOLL is not set
> +# CONFIG_SIGNALFD is not set
> +# CONFIG_TIMERFD is not set
> +# CONFIG_EVENTFD is not set
> +# CONFIG_AIO is not set
> +# CONFIG_IO_URING is not set
> +# CONFIG_ADVISE_SYSCALLS is not set
> +# CONFIG_MEMBARRIER is not set
> +# CONFIG_KALLSYMS is not set
> +CONFIG_EMBEDDED=y
> +# CONFIG_VM_EVENT_COUNTERS is not set
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLOB=y
> +# CONFIG_SLAB_MERGE_DEFAULT is not set
> +# CONFIG_MMU is not set
> +CONFIG_SOC_KENDRYTE=y
> +CONFIG_MAXPHYSMEM_2GB=y
> +CONFIG_SMP=y
> +CONFIG_NR_CPUS=2
> +CONFIG_CMDLINE="earlycon console=ttySIF0"
> +CONFIG_CMDLINE_FORCE=y
> +CONFIG_USE_BUILTIN_DTB=y
> +CONFIG_BUILTIN_DTB_SOURCE="kendryte/k210"
> +# CONFIG_BLOCK is not set
> +CONFIG_BINFMT_FLAT=y
> +# CONFIG_COREDUMP is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_FW_LOADER is not set
> +# CONFIG_ALLOW_DEV_COREDUMP is not set
> +# CONFIG_INPUT_KEYBOARD is not set
> +# CONFIG_INPUT_MOUSE is not set
> +# CONFIG_SERIO is not set
> +# CONFIG_LEGACY_PTYS is not set
> +# CONFIG_LDISC_AUTOLOAD is not set
> +# CONFIG_DEVMEM is not set
> +# CONFIG_HW_RANDOM is not set
> +# CONFIG_HWMON is not set
> +# CONFIG_VGA_CONSOLE is not set
> +# CONFIG_HID is not set
> +# CONFIG_USB_SUPPORT is not set
> +# CONFIG_VIRTIO_MENU is not set
> +# CONFIG_DNOTIFY is not set
> +# CONFIG_INOTIFY_USER is not set
> +# CONFIG_MISC_FILESYSTEMS is not set
> +CONFIG_LSM="[]"
> +CONFIG_PRINTK_TIME=y
> +# CONFIG_DEBUG_MISC is not set
> +# CONFIG_SCHED_DEBUG is not set
> +# CONFIG_RCU_TRACE is not set
> +# CONFIG_FTRACE is not set
> +# CONFIG_RUNTIME_TESTING_MENU is not set
I'd like to refactor these defconfigs so we can share the RISC-V options and
have these only select what's actually relevant, but I don't see any reason to
block this patch on doing that.
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
2020-03-02 4:08 ` Anup Patel
@ 2020-03-04 19:44 ` Palmer Dabbelt
1 sibling, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:44 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:32 PST (-0800), Damien Le Moal wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> This can be loaded into the Kendryte KD210 based boards using:
>
> kflash.py/kflash.py -t arch/riscv/boot/loader.bin
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Makefile | 4 ++--
> arch/riscv/boot/Makefile | 3 +++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index b9009a2fbaf5..440969763e14 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -84,11 +84,11 @@ vdso_install:
> $(Q)$(MAKE) $(build)=arch/riscv/kernel/vdso $@
>
> ifeq ($(CONFIG_RISCV_M_MODE),y)
> -KBUILD_IMAGE := $(boot)/loader
> +KBUILD_IMAGE := $(boot)/loader.bin
> else
> KBUILD_IMAGE := $(boot)/Image.gz
> endif
> -BOOT_TARGETS := Image Image.gz loader
> +BOOT_TARGETS := Image Image.gz loader loader.bin
>
> all: $(notdir $(KBUILD_IMAGE))
>
> diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
> index 36db8145f9f4..3530c59b3ea7 100644
> --- a/arch/riscv/boot/Makefile
> +++ b/arch/riscv/boot/Makefile
> @@ -41,6 +41,9 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
> $(obj)/Image.lzo: $(obj)/Image FORCE
> $(call if_changed,lzo)
>
> +$(obj)/loader.bin: $(obj)/loader FORCE
> + $(call if_changed,objcopy)
> +
> install:
> $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
> $(obj)/Image System.map "$(INSTALL_PATH)"
I'm a bit worried about having a big pile of odd formats floating around in
here, but given that there are very few RISC-V boards around I think it's OK to
err on the side of just collecting everything in one place and organizing it
later -- it's kind of hard to organize two things :)
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 00/10] Kendryte k210 SoC boards support
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
` (11 preceding siblings ...)
2020-02-28 20:32 ` Sean Anderson
@ 2020-03-04 19:44 ` Palmer Dabbelt
12 siblings, 0 replies; 89+ messages in thread
From: Palmer Dabbelt @ 2020-03-04 19:44 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Paul Walmsley
On Wed, 12 Feb 2020 02:34:22 PST (-0800), Damien Le Moal wrote:
> This series adds support to boot nommu Linux on Kendryte K210 SoC based
> boards. This is all based on initial work done by Christoph Hellwig.
>
> The first 2 patches fix riscv gitignore and a potential nommu
> compilation error. These patches are not specific to the Kendryte
> support.
Thanks, I put #2 on fixes (after having already put #1 there earlier).
>
> Patch 3 adds unaligned load/store trap handlers for M-mode.
>
> Patch 4 enables a builtin DTB to allow passing a device tree to the
> kernel when the board bootchain is enabled to pass one.
I had some comments on that one, but otherwise this looks good. LMK if you
want to re-spin this or if you'd like me to deal with it.
Thanks!
>
> Patch 5 introduces an early SoC initialization enabling very early
> hardware initialization not possible with device tree entries pointing
> to drivers. This is used in patch 6 which introduces a sysctl driver for
> the K210 SoC. The early SoC initialization is used to enable the
> additional 2MB of SRAM normally reserved to the SoC AI chip.
>
> Patch 7 to 9 add necessary Kconfig changes, a defconfig and a generic
> device tree suitable for many K210 boards.
>
> Finally, patch 10 adds compilation of a bootable image file (bin file)
> that can be used to flash the board ROM.
>
> This series was tested on the Kendryte KD233 development board, the
> Sipeed MAIX dan dock board and the Sipeed MAIXDUINO board. The userspace
> used was built using a modified buildroot tree for the toolchain part
> and an unmodified busybox tree for the initramfs image (embedded in the
> kernel as a cpio file). The folowwing github project contains the
> modified buildroot tree:
>
> https://github.com/damien-lemoal/riscv64-nommu-buildroot
>
> This is based on work from Christoph Hellwig, with additional changes
> and updates to the latest upstream versions for buildroot and uClibc.
>
> Precompiled versions of the toolchain (gcc 9.2) and initramfs file tree
> and cpio file can be found in this project under the directory:
>
> buildroot/riscv64-uclibc-nommu/
>
> Flashing the file arch/riscv/boot/loader.bin to a board can be done
> using the Sipeed kflash.py tool with the command:
>
> kflash.py/kflash.py -p /dev/ttyUSB0 -b 1500000 -t loader.bin
>
> The kflash.py tool can be found here:
>
> https://github.com/sipeed/kflash.py
>
> For reference, using the Sipeed MAIXDUINO board, here is the boot
> output:
>
> [INFO] Rebooting...
> --- forcing DTR inactive
> --- forcing RTS inactive
> --- Miniterm on /dev/ttyUSB0 115200,8,N,1 ---
> --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
> [ 0.000000] Linux version 5.6.0-rc1-00011-ga2b5be1c4374 (damien@yyy) (gcc version 8.2.0 (Buildroot 2018.11-rc2-00003-ga0787e9)) #610 SMP Wed Feb 12 18:53:50 JST 2020
> [ 0.000000] earlycon: sifive0 at MMIO 0x0000000038000000 (options '')
> [ 0.000000] printk: bootconsole [sifive0] enabled
> [ 0.000000] initrd not found or empty - disabling initrd
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000807fffff]
> [ 0.000000] elf_hwcap is 0x112d
> [ 0.000000] percpu: max_distance=0x18000 too large for vmalloc space 0x0
> [ 0.000000] percpu: Embedded 12 pages/cpu s18272 r0 d30880 u49152
> [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020
> [ 0.000000] Kernel command line: earlycon console=ttySIF0
> [ 0.000000] Dentry cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.000000] Sorting __ex_table...
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] Memory: 6328K/8192K available (924K kernel code, 110K rwdata, 164K rodata, 321K init, 91K bss, 1864K reserved, 0K cma-reserved)
> [ 0.000000] rcu: Hierarchical RCU implementation.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
> [ 0.000000] plic: mapped 65 interrupts with 2 handlers for 4 contexts.
> [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
> [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x3990be68b, max_idle_ns: 881590404272 ns
> [ 0.000014] sched_clock: 64 bits at 7MHz, resolution 128ns, wraps every 4398046511054ns
> [ 0.008232] Console: colour dummy device 80x25
> [ 0.012474] Calibrating delay loop (skipped), value calculated using timer frequency.. 15.60 BogoMIPS (lpj=31200)
> [ 0.022678] pid_max: default: 4096 minimum: 301
> [ 0.027288] Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.034414] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
> [ 0.044796] rcu: Hierarchical SRCU implementation.
> [ 0.049602] smp: Bringing up secondary CPUs ...
> [ 0.054746] smp: Brought up 1 node, 2 CPUs
> [ 0.059093] devtmpfs: initialized
> [ 0.065523] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 0.074544] futex hash table entries: 16 (order: -2, 1024 bytes, linear)
> [ 0.082512] Kendryte K210 SoC sysctl
> [ 0.096010] clocksource: Switched to clocksource riscv_clocksource
> [ 0.178581] workingset: timestamp_bits=62 max_order=11 bucket_order=0
> [ 0.185846] 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 0) is a SiFive UART v0
> [ 0.194344] printk: console [ttySIF0] enabled
> [ 0.194344] printk: console [ttySIF0] enabled
> [ 0.202929] printk: bootconsole [sifive0] disabled
> [ 0.202929] printk: bootconsole [sifive0] disabled
> [ 0.214853] random: get_random_bytes called from 0x0000000080055178 with crng_init=0
> [ 0.223606] devtmpfs: mounted
> [ 0.226861] Freeing unused kernel memory: 320K
> [ 0.230574] This architecture does not have kernel memory protection.
> [ 0.236987] Run /sbin/init as init process
> [ 0.241181] Run /etc/init as init process
> [ 0.245178] Run /bin/init as init process
>
> -----------------------------
> | Kendryte K210 NOMMU Linux |
> -----------------------------
> Mounting /proc
> Starting shell
>
>
> BusyBox v1.32.0.git (2020-02-12 17:51:45 JST) hush - the humble shell
> Enter 'help' for a list of built-in commands.
>
> / # cat /proc/cpuinfo
> processor : 0
> hart : 0
> isa : rv64imafdc
>
> processor : 1
> hart : 1
> isa : rv64imafdc
>
> / #
> / # ls -l /
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 bin
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 dev
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 etc
> dr-xr-xr-x 58 0 0 0 Jan 1 00:00 proc
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 root
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 sbin
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 sys
> drwxrwxr-x 2 1000 1000 0 Feb 12 2020 tmp
> drwxrwxr-x 4 1000 1000 0 Feb 12 2020 usr
> / #
> / # cat /proc/vmstat
> nr_free_pages 1148
> ...
> / #
>
> The K210 SoC has more devices (GPIO, SD-card, LCD, etc) that likely can
> be enabled and used. For this, the sysctl driver will need further
> improvements as each device uses a different clock. To share the fun,
> supporting these is left as an exercise for the hobbyist and hackers
> interested in this SoC/boards :)
>
> Christoph Hellwig (2):
> riscv: Add Kendryte K210 SoC support
> riscv: create a loader.bin for the kendryte kflash.py tool
>
> Damien Le Moal (8):
> riscv: Fix gitignore
> riscv: Force flat memory model with no-mmu
> riscv: Unaligned load/store handling for M_MODE
> riscv: Add BUILTIN_DTB support
> riscv: Add SOC early init support
> riscv: Select required drivers for Kendryte SOC
> riscv: Add Kendryte K210 device tree
> riscv: Kendryte K210 default config
>
> arch/riscv/Kbuild | 1 +
> arch/riscv/Kconfig | 19 ++
> arch/riscv/Kconfig.socs | 10 +
> arch/riscv/Makefile | 4 +-
> arch/riscv/boot/.gitignore | 2 +
> arch/riscv/boot/Makefile | 3 +
> arch/riscv/boot/dts/Makefile | 5 +
> arch/riscv/boot/dts/kendryte/Makefile | 2 +
> arch/riscv/boot/dts/kendryte/k210.dts | 23 ++
> arch/riscv/boot/dts/kendryte/k210.dtsi | 123 ++++++++
> arch/riscv/configs/nommu_k210_defconfig | 68 +++++
> arch/riscv/include/asm/soc.h | 23 ++
> arch/riscv/kernel/Makefile | 3 +-
> arch/riscv/kernel/head.S | 1 +
> arch/riscv/kernel/setup.c | 6 +
> arch/riscv/kernel/soc.c | 28 ++
> arch/riscv/kernel/traps.c | 27 +-
> arch/riscv/kernel/traps_misaligned.c | 371 ++++++++++++++++++++++++
> arch/riscv/kernel/vmlinux.lds.S | 6 +
> arch/riscv/mm/init.c | 4 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/kendryte/Kconfig | 14 +
> drivers/soc/kendryte/Makefile | 3 +
> drivers/soc/kendryte/k210-sysctl.c | 245 ++++++++++++++++
> 25 files changed, 987 insertions(+), 6 deletions(-)
> create mode 100644 arch/riscv/boot/dts/kendryte/Makefile
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dts
> create mode 100644 arch/riscv/boot/dts/kendryte/k210.dtsi
> create mode 100644 arch/riscv/configs/nommu_k210_defconfig
> create mode 100644 arch/riscv/include/asm/soc.h
> create mode 100644 arch/riscv/kernel/soc.c
> create mode 100644 arch/riscv/kernel/traps_misaligned.c
> create mode 100644 drivers/soc/kendryte/Kconfig
> create mode 100644 drivers/soc/kendryte/Makefile
> create mode 100644 drivers/soc/kendryte/k210-sysctl.c
^ permalink raw reply [flat|nested] 89+ messages in thread
* RE: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-04 19:28 ` Palmer Dabbelt
@ 2020-03-05 4:58 ` Anup Patel
2020-03-05 5:14 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Anup Patel @ 2020-03-05 4:58 UTC (permalink / raw)
To: Palmer Dabbelt, Damien Le Moal; +Cc: linux-riscv, Paul Walmsley
> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: 05 March 2020 00:59
> To: Damien Le Moal <Damien.LeMoal@wdc.com>
> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>
> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
> > Enable a kernel builtin dtb for boards not capable of providing a
> > device tree to the kernel.
>
> I'd prefer if we picked a mechanism that allows a single kernel binary to be
> run on multiple systems. I think there's two use cases here:
I strongly support "single kernel binary for multiple systems" but it's for
different purpose here.
>
> * Bootloaders that provide no DTB at all.
> * Bootloaders that provied a DTB that, for some reason, isn't usable.
>
> Given those constraints, could we do something similar to the early fixups?
> I'm thinking we could build a mapping between a hardware identifier and a
> DTB, then look up the DTB we want to use. Users that want a kernel that
> only runs on a single device can do so by configuring only a single DTB, users
> that want a more portable kernel can select a bunch -- that's essentially the
> same as how we're treating everything else (for example, the
> CONFIG_SOC_* stuff).
There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
boots directly. The BUILTIN_DTB is only applicable to cases where there is
no bootloader before kernel.
The Linux RISC-V NOMMU will tend be used in cases where:
1. There is no bootloader and kernel boots directly hence we need
builtin DTB feature.
2. There is very less RAM so we will have to build kernel specific to
a particular platform with bare minimum drivers. Due to this, we will
have separate defconfig for NOMMU platforms.
I think point1 can be tackled if we enforce having bootloader (such as U-Boot)
for NOMMU systems and drop this patch.
For point2 above, we don't have much alternatives other than reducing
kernel binary size by disabling unwanted drivers.
>
> For the hardware ID, could we do something like:
>
> * Check for the top-level DT compatible string, on systems where we have a
> provided DTB.
> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some
> sort of
> masking functionality if we later need one. These are availiable via SBI
> calls, but I'd be inclined to restrict them to M-mode boot and just say the
> SBI must provide a device tree with at least a suitable compatible string.
>
> While I suppose we could put together a tool for generating these tables, for
> now we could probably just stick the mappings in a table for now given that
> there's only one of them.
>
> That said, I'm not sure what to do about the different Kendryte boards -- is
> there any way to poke the hardware to see which is which?
I am sure there are two three different boards out there. Don't know exact
differences between these boards.
Regards,
Anup
>
> > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > ---
> > arch/riscv/Kbuild | 1 +
> > arch/riscv/Kconfig | 18 ++++++++++++++++++
> > arch/riscv/boot/dts/Makefile | 4 ++++
> > arch/riscv/kernel/setup.c | 6 ++++++
> > arch/riscv/mm/init.c | 4 ++++
> > 5 files changed, 33 insertions(+)
> >
> > diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index
> > d1d0aa70fdf1..988804e430e4 100644
> > --- a/arch/riscv/Kbuild
> > +++ b/arch/riscv/Kbuild
> > @@ -1,3 +1,4 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> >
> > obj-y += kernel/ mm/ net/
> > +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > 1a3b5a5276be..28899e15f548 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -355,6 +355,24 @@ config CMDLINE_FORCE
> >
> > endchoice
> >
> > +config USE_BUILTIN_DTB
> > + bool "Use builtin DTB"
> > + help
> > + Link a device tree blob for particular hardware into the kernel,
> > + suppressing use of the DTB pointer provided by the bootloader.
> > + This option should only be used with hardware or bootloaders that
> > + are not capable of providing a DTB to the kernel, or for
> > + experimental hardware without stable device tree bindings.
> > +
> > +config BUILTIN_DTB_SOURCE
> > + string "Source file for builtin DTB"
> > + default ""
> > + depends on USE_BUILTIN_DTB
> > + help
> > + Base name (without suffix, relative to arch/riscv/boot/dts) for
> > + the a DTS file that will be used to produce the DTB linked into
> > + the kernel.
> > +
> > endmenu
> >
> > menu "Power management options"
> > diff --git a/arch/riscv/boot/dts/Makefile
> > b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,2 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0
> > +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> > +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst
> > +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> > +else
> > subdir-y += sifive
> > +endif
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 0a6d415b0a5a..3e89be9d888c 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
> >
> > setup_bootmem();
> > paging_init();
> > +
> > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> > + unflatten_and_copy_device_tree();
> > +#else
> > unflatten_device_tree();
> > +#endif
> > +
> > clint_init_boot_cpu();
> >
> > #ifdef CONFIG_SWIOTLB
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index
> > 965a8cf4829c..1274e889d008 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else
> > asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
> > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> > + dtb_early_va = __dtb_start;
> > +#else
> > dtb_early_va = (void *)dtb_pa;
> > +#endif
> > }
> >
> > static inline void setup_vm_final(void)
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 4:58 ` Anup Patel
@ 2020-03-05 5:14 ` Damien Le Moal
2020-03-05 5:37 ` Anup Patel
` (2 more replies)
0 siblings, 3 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-03-05 5:14 UTC (permalink / raw)
To: Anup Patel, Palmer Dabbelt; +Cc: linux-riscv, Paul Walmsley
On 2020/03/05 13:58, Anup Patel wrote:
>
>
>> -----Original Message-----
>> From: Palmer Dabbelt <palmer@dabbelt.com>
>> Sent: 05 March 2020 00:59
>> To: Damien Le Moal <Damien.LeMoal@wdc.com>
>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>>
>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
>>> Enable a kernel builtin dtb for boards not capable of providing a
>>> device tree to the kernel.
>>
>> I'd prefer if we picked a mechanism that allows a single kernel binary to be
>> run on multiple systems. I think there's two use cases here:
>
> I strongly support "single kernel binary for multiple systems" but it's for
> different purpose here.
>
>>
>> * Bootloaders that provide no DTB at all.
>> * Bootloaders that provied a DTB that, for some reason, isn't usable.
Sure, but as Anup mentions below, the current use case it to not even use any
bootloader at all for the K210 since that brings no value at all (in my
opinion). More on this below.
>>
>> Given those constraints, could we do something similar to the early fixups?
>> I'm thinking we could build a mapping between a hardware identifier and a
>> DTB, then look up the DTB we want to use. Users that want a kernel that
>> only runs on a single device can do so by configuring only a single DTB, users
>> that want a more portable kernel can select a bunch -- that's essentially the
>> same as how we're treating everything else (for example, the
>> CONFIG_SOC_* stuff).
>
> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
> boots directly. The BUILTIN_DTB is only applicable to cases where there is
> no bootloader before kernel.
>
> The Linux RISC-V NOMMU will tend be used in cases where:
> 1. There is no bootloader and kernel boots directly hence we need
> builtin DTB feature.
> 2. There is very less RAM so we will have to build kernel specific to
> a particular platform with bare minimum drivers. Due to this, we will
> have separate defconfig for NOMMU platforms.
>
> I think point1 can be tackled if we enforce having bootloader (such as U-Boot)
> for NOMMU systems and drop this patch.
But that would go against point 2 as that will use more memory... By "drop this
patch", may be you meant to say "not use this config option" ?
> For point2 above, we don't have much alternatives other than reducing
> kernel binary size by disabling unwanted drivers.
And not using a boot loader. Sean got U-boot working with Kendryte, so it is not
that we cannot make it work. It is only that it may be less optimal due to the
memory used by the boot loader itself. Unless we can recover it if the kernel
relocate itself over it ? Surely doable, but it does sound to me like an
overkill for this particular use case, i.e. a tiny, hyper-embedded board where
running Linux is probably not the best choice in the first place, at least when
looking at real applications. The story is different for "hobbyist" level. My
on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
case after all :)
>
>>
>> For the hardware ID, could we do something like:
>>
>> * Check for the top-level DT compatible string, on systems where we have a
>> provided DTB.
>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some
>> sort of
>> masking functionality if we later need one. These are availiable via SBI
>> calls, but I'd be inclined to restrict them to M-mode boot and just say the
>> SBI must provide a device tree with at least a suitable compatible string.
>>
>> While I suppose we could put together a tool for generating these tables, for
>> now we could probably just stick the mappings in a table for now given that
>> there's only one of them.
>>
>> That said, I'm not sure what to do about the different Kendryte boards -- is
>> there any way to poke the hardware to see which is which?
>
> I am sure there are two three different boards out there. Don't know exact
> differences between these boards.
As far as I can tell, all the boards use the exact same SoC. No differences that
I can detect nor aware of. What differs between the different flavors of boards
are the perypherals attached: some have WiFi, different LCDs and different
cameras. The device tree is able to describe that of course, but the core dtsi
part for the SoC itself seem to be OK at least for the 4 different boards I have
(Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan Dock).
>
> Regards,
> Anup
>
>>
>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>> ---
>>> arch/riscv/Kbuild | 1 +
>>> arch/riscv/Kconfig | 18 ++++++++++++++++++
>>> arch/riscv/boot/dts/Makefile | 4 ++++
>>> arch/riscv/kernel/setup.c | 6 ++++++
>>> arch/riscv/mm/init.c | 4 ++++
>>> 5 files changed, 33 insertions(+)
>>>
>>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index
>>> d1d0aa70fdf1..988804e430e4 100644
>>> --- a/arch/riscv/Kbuild
>>> +++ b/arch/riscv/Kbuild
>>> @@ -1,3 +1,4 @@
>>> # SPDX-License-Identifier: GPL-2.0-only
>>>
>>> obj-y += kernel/ mm/ net/
>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
>>> 1a3b5a5276be..28899e15f548 100644
>>> --- a/arch/riscv/Kconfig
>>> +++ b/arch/riscv/Kconfig
>>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
>>>
>>> endchoice
>>>
>>> +config USE_BUILTIN_DTB
>>> + bool "Use builtin DTB"
>>> + help
>>> + Link a device tree blob for particular hardware into the kernel,
>>> + suppressing use of the DTB pointer provided by the bootloader.
>>> + This option should only be used with hardware or bootloaders that
>>> + are not capable of providing a DTB to the kernel, or for
>>> + experimental hardware without stable device tree bindings.
>>> +
>>> +config BUILTIN_DTB_SOURCE
>>> + string "Source file for builtin DTB"
>>> + default ""
>>> + depends on USE_BUILTIN_DTB
>>> + help
>>> + Base name (without suffix, relative to arch/riscv/boot/dts) for
>>> + the a DTS file that will be used to produce the DTB linked into
>>> + the kernel.
>>> +
>>> endmenu
>>>
>>> menu "Power management options"
>>> diff --git a/arch/riscv/boot/dts/Makefile
>>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644
>>> --- a/arch/riscv/boot/dts/Makefile
>>> +++ b/arch/riscv/boot/dts/Makefile
>>> @@ -1,2 +1,6 @@
>>> # SPDX-License-Identifier: GPL-2.0
>>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst
>>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
>>> +else
>>> subdir-y += sifive
>>> +endif
>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>>> index 0a6d415b0a5a..3e89be9d888c 100644
>>> --- a/arch/riscv/kernel/setup.c
>>> +++ b/arch/riscv/kernel/setup.c
>>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
>>>
>>> setup_bootmem();
>>> paging_init();
>>> +
>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
>>> + unflatten_and_copy_device_tree();
>>> +#else
>>> unflatten_device_tree();
>>> +#endif
>>> +
>>> clint_init_boot_cpu();
>>>
>>> #ifdef CONFIG_SWIOTLB
>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index
>>> 965a8cf4829c..1274e889d008 100644
>>> --- a/arch/riscv/mm/init.c
>>> +++ b/arch/riscv/mm/init.c
>>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else
>>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
>>> + dtb_early_va = __dtb_start;
>>> +#else
>>> dtb_early_va = (void *)dtb_pa;
>>> +#endif
>>> }
>>>
>>> static inline void setup_vm_final(void)
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* RE: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 5:14 ` Damien Le Moal
@ 2020-03-05 5:37 ` Anup Patel
2020-03-05 6:13 ` Damien Le Moal
2020-03-05 8:18 ` Atish Patra
2020-03-06 23:56 ` Sean Anderson
2 siblings, 1 reply; 89+ messages in thread
From: Anup Patel @ 2020-03-05 5:37 UTC (permalink / raw)
To: Damien Le Moal, Palmer Dabbelt; +Cc: linux-riscv, Paul Walmsley
> -----Original Message-----
> From: Damien Le Moal
> Sent: 05 March 2020 10:44
> To: Anup Patel <Anup.Patel@wdc.com>; Palmer Dabbelt
> <palmer@dabbelt.com>
> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> <paul.walmsley@sifive.com>
> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>
> On 2020/03/05 13:58, Anup Patel wrote:
> >
> >
> >> -----Original Message-----
> >> From: Palmer Dabbelt <palmer@dabbelt.com>
> >> Sent: 05 March 2020 00:59
> >> To: Damien Le Moal <Damien.LeMoal@wdc.com>
> >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> >> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
> >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
> >>
> >> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
> >>> Enable a kernel builtin dtb for boards not capable of providing a
> >>> device tree to the kernel.
> >>
> >> I'd prefer if we picked a mechanism that allows a single kernel
> >> binary to be run on multiple systems. I think there's two use cases here:
> >
> > I strongly support "single kernel binary for multiple systems" but
> > it's for different purpose here.
> >
> >>
> >> * Bootloaders that provide no DTB at all.
> >> * Bootloaders that provied a DTB that, for some reason, isn't usable.
>
> Sure, but as Anup mentions below, the current use case it to not even use
> any bootloader at all for the K210 since that brings no value at all (in my
> opinion). More on this below.
>
> >>
> >> Given those constraints, could we do something similar to the early
> fixups?
> >> I'm thinking we could build a mapping between a hardware identifier
> >> and a DTB, then look up the DTB we want to use. Users that want a
> >> kernel that only runs on a single device can do so by configuring
> >> only a single DTB, users that want a more portable kernel can select
> >> a bunch -- that's essentially the same as how we're treating
> >> everything else (for example, the
> >> CONFIG_SOC_* stuff).
> >
> > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
> > boots directly. The BUILTIN_DTB is only applicable to cases where
> > there is no bootloader before kernel.
> >
> > The Linux RISC-V NOMMU will tend be used in cases where:
> > 1. There is no bootloader and kernel boots directly hence we need
> > builtin DTB feature.
> > 2. There is very less RAM so we will have to build kernel specific to
> > a particular platform with bare minimum drivers. Due to this, we will
> > have separate defconfig for NOMMU platforms.
> >
> > I think point1 can be tackled if we enforce having bootloader (such as
> > U-Boot) for NOMMU systems and drop this patch.
>
> But that would go against point 2 as that will use more memory... By "drop
> this patch", may be you meant to say "not use this config option" ?
I meant to use U-Boot on Kendryte to launch kernel.
>
> > For point2 above, we don't have much alternatives other than reducing
> > kernel binary size by disabling unwanted drivers.
>
> And not using a boot loader. Sean got U-boot working with Kendryte, so it is
> not that we cannot make it work. It is only that it may be less optimal due to
> the memory used by the boot loader itself. Unless we can recover it if the
> kernel relocate itself over it ? Surely doable, but it does sound to me like an
> overkill for this particular use case, i.e. a tiny, hyper-embedded board where
> running Linux is probably not the best choice in the first place, at least when
> looking at real applications. The story is different for "hobbyist" level. My on-
> going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
> case after all :)
Dropping BUILTIN DTB feature will be more like a Linux RISC-V policy thingy.
My suggestion was more about discouraging Linux S-mode users to use the
BUILTIN DTB feature.
I agree that it is difficult to fit a proper boot-flow (having proper bootloader)
due to limited RAM. If we don't link DTB to Linux RISC-V NOMMU then some
thing else need to provide it hence bootloader suggestion.
Apart from the Linux RISC-V NOMMU use-case, the BUILTIN DTB feature can
be useful in environments such as FPGAs/Palladium where proper bootloader
is not available.
Regards,
Anup
>
> >
> >>
> >> For the hardware ID, could we do something like:
> >>
> >> * Check for the top-level DT compatible string, on systems where we
> have a
> >> provided DTB.
> >> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with
> >> some sort of
> >> masking functionality if we later need one. These are availiable via SBI
> >> calls, but I'd be inclined to restrict them to M-mode boot and just say the
> >> SBI must provide a device tree with at least a suitable compatible string.
> >>
> >> While I suppose we could put together a tool for generating these
> >> tables, for now we could probably just stick the mappings in a table
> >> for now given that there's only one of them.
> >>
> >> That said, I'm not sure what to do about the different Kendryte
> >> boards -- is there any way to poke the hardware to see which is which?
> >
> > I am sure there are two three different boards out there. Don't know
> > exact differences between these boards.
>
> As far as I can tell, all the boards use the exact same SoC. No differences that
> I can detect nor aware of. What differs between the different flavors of
> boards are the perypherals attached: some have WiFi, different LCDs and
> different cameras. The device tree is able to describe that of course, but the
> core dtsi part for the SoC itself seem to be OK at least for the 4 different
> boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan
> Dock).
>
> >
> > Regards,
> > Anup
> >
> >>
> >>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >>> ---
> >>> arch/riscv/Kbuild | 1 +
> >>> arch/riscv/Kconfig | 18 ++++++++++++++++++
> >>> arch/riscv/boot/dts/Makefile | 4 ++++
> >>> arch/riscv/kernel/setup.c | 6 ++++++
> >>> arch/riscv/mm/init.c | 4 ++++
> >>> 5 files changed, 33 insertions(+)
> >>>
> >>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index
> >>> d1d0aa70fdf1..988804e430e4 100644
> >>> --- a/arch/riscv/Kbuild
> >>> +++ b/arch/riscv/Kbuild
> >>> @@ -1,3 +1,4 @@
> >>> # SPDX-License-Identifier: GPL-2.0-only
> >>>
> >>> obj-y += kernel/ mm/ net/
> >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
> >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> >>> 1a3b5a5276be..28899e15f548 100644
> >>> --- a/arch/riscv/Kconfig
> >>> +++ b/arch/riscv/Kconfig
> >>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
> >>>
> >>> endchoice
> >>>
> >>> +config USE_BUILTIN_DTB
> >>> + bool "Use builtin DTB"
> >>> + help
> >>> + Link a device tree blob for particular hardware into the kernel,
> >>> + suppressing use of the DTB pointer provided by the bootloader.
> >>> + This option should only be used with hardware or bootloaders that
> >>> + are not capable of providing a DTB to the kernel, or for
> >>> + experimental hardware without stable device tree bindings.
> >>> +
> >>> +config BUILTIN_DTB_SOURCE
> >>> + string "Source file for builtin DTB"
> >>> + default ""
> >>> + depends on USE_BUILTIN_DTB
> >>> + help
> >>> + Base name (without suffix, relative to arch/riscv/boot/dts) for
> >>> + the a DTS file that will be used to produce the DTB linked into
> >>> + the kernel.
> >>> +
> >>> endmenu
> >>>
> >>> menu "Power management options"
> >>> diff --git a/arch/riscv/boot/dts/Makefile
> >>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d
> >>> 100644
> >>> --- a/arch/riscv/boot/dts/Makefile
> >>> +++ b/arch/riscv/boot/dts/Makefile
> >>> @@ -1,2 +1,6 @@
> >>> # SPDX-License-Identifier: GPL-2.0
> >>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst
> >>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> >>> +else
> >>> subdir-y += sifive
> >>> +endif
> >>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> >>> index 0a6d415b0a5a..3e89be9d888c 100644
> >>> --- a/arch/riscv/kernel/setup.c
> >>> +++ b/arch/riscv/kernel/setup.c
> >>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
> >>>
> >>> setup_bootmem();
> >>> paging_init();
> >>> +
> >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> >>> + unflatten_and_copy_device_tree();
> >>> +#else
> >>> unflatten_device_tree();
> >>> +#endif
> >>> +
> >>> clint_init_boot_cpu();
> >>>
> >>> #ifdef CONFIG_SWIOTLB
> >>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index
> >>> 965a8cf4829c..1274e889d008 100644
> >>> --- a/arch/riscv/mm/init.c
> >>> +++ b/arch/riscv/mm/init.c
> >>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else
> >>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
> >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> >>> + dtb_early_va = __dtb_start;
> >>> +#else
> >>> dtb_early_va = (void *)dtb_pa;
> >>> +#endif
> >>> }
> >>>
> >>> static inline void setup_vm_final(void)
> >
>
>
> --
> Damien Le Moal
> Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 5:37 ` Anup Patel
@ 2020-03-05 6:13 ` Damien Le Moal
2020-03-08 6:10 ` Anup Patel
0 siblings, 1 reply; 89+ messages in thread
From: Damien Le Moal @ 2020-03-05 6:13 UTC (permalink / raw)
To: Anup Patel, Palmer Dabbelt; +Cc: linux-riscv, Paul Walmsley
On 2020/03/05 14:37, Anup Patel wrote:
>
>
>> -----Original Message-----
>> From: Damien Le Moal
>> Sent: 05 March 2020 10:44
>> To: Anup Patel <Anup.Patel@wdc.com>; Palmer Dabbelt
>> <palmer@dabbelt.com>
>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
>> <paul.walmsley@sifive.com>
>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>>
>> On 2020/03/05 13:58, Anup Patel wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Palmer Dabbelt <palmer@dabbelt.com>
>>>> Sent: 05 March 2020 00:59
>>>> To: Damien Le Moal <Damien.LeMoal@wdc.com>
>>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
>>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
>>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>>>>
>>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
>>>>> Enable a kernel builtin dtb for boards not capable of providing a
>>>>> device tree to the kernel.
>>>>
>>>> I'd prefer if we picked a mechanism that allows a single kernel
>>>> binary to be run on multiple systems. I think there's two use cases here:
>>>
>>> I strongly support "single kernel binary for multiple systems" but
>>> it's for different purpose here.
>>>
>>>>
>>>> * Bootloaders that provide no DTB at all.
>>>> * Bootloaders that provied a DTB that, for some reason, isn't usable.
>>
>> Sure, but as Anup mentions below, the current use case it to not even use
>> any bootloader at all for the K210 since that brings no value at all (in my
>> opinion). More on this below.
>>
>>>>
>>>> Given those constraints, could we do something similar to the early
>> fixups?
>>>> I'm thinking we could build a mapping between a hardware identifier
>>>> and a DTB, then look up the DTB we want to use. Users that want a
>>>> kernel that only runs on a single device can do so by configuring
>>>> only a single DTB, users that want a more portable kernel can select
>>>> a bunch -- that's essentially the same as how we're treating
>>>> everything else (for example, the
>>>> CONFIG_SOC_* stuff).
>>>
>>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
>>> boots directly. The BUILTIN_DTB is only applicable to cases where
>>> there is no bootloader before kernel.
>>>
>>> The Linux RISC-V NOMMU will tend be used in cases where:
>>> 1. There is no bootloader and kernel boots directly hence we need
>>> builtin DTB feature.
>>> 2. There is very less RAM so we will have to build kernel specific to
>>> a particular platform with bare minimum drivers. Due to this, we will
>>> have separate defconfig for NOMMU platforms.
>>>
>>> I think point1 can be tackled if we enforce having bootloader (such as
>>> U-Boot) for NOMMU systems and drop this patch.
>>
>> But that would go against point 2 as that will use more memory... By "drop
>> this patch", may be you meant to say "not use this config option" ?
>
> I meant to use U-Boot on Kendryte to launch kernel.
>
>>
>>> For point2 above, we don't have much alternatives other than reducing
>>> kernel binary size by disabling unwanted drivers.
>>
>> And not using a boot loader. Sean got U-boot working with Kendryte, so it is
>> not that we cannot make it work. It is only that it may be less optimal due to
>> the memory used by the boot loader itself. Unless we can recover it if the
>> kernel relocate itself over it ? Surely doable, but it does sound to me like an
>> overkill for this particular use case, i.e. a tiny, hyper-embedded board where
>> running Linux is probably not the best choice in the first place, at least when
>> looking at real applications. The story is different for "hobbyist" level. My on-
>> going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
>> case after all :)
>
> Dropping BUILTIN DTB feature will be more like a Linux RISC-V policy thingy.
> My suggestion was more about discouraging Linux S-mode users to use the
> BUILTIN DTB feature.
Got it. For now, we could tie BUILTIN DTB config to !MMU case only. If there is
a valid use case that pops up for regular MMU/S-mode Linux, it is easy to change.
> I agree that it is difficult to fit a proper boot-flow (having proper bootloader)
> due to limited RAM. If we don't link DTB to Linux RISC-V NOMMU then some
> thing else need to provide it hence bootloader suggestion.
OK. Understood and I agree.
>
> Apart from the Linux RISC-V NOMMU use-case, the BUILTIN DTB feature can
> be useful in environments such as FPGAs/Palladium where proper bootloader
> is not available.
OK. But we do not have to enable it for this right away, no ? So should I just
not allow BUILTIN DTB for MMU==true case for now ?
>
> Regards,
> Anup
>
>>
>>>
>>>>
>>>> For the hardware ID, could we do something like:
>>>>
>>>> * Check for the top-level DT compatible string, on systems where we
>> have a
>>>> provided DTB.
>>>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with
>>>> some sort of
>>>> masking functionality if we later need one. These are availiable via SBI
>>>> calls, but I'd be inclined to restrict them to M-mode boot and just say the
>>>> SBI must provide a device tree with at least a suitable compatible string.
>>>>
>>>> While I suppose we could put together a tool for generating these
>>>> tables, for now we could probably just stick the mappings in a table
>>>> for now given that there's only one of them.
>>>>
>>>> That said, I'm not sure what to do about the different Kendryte
>>>> boards -- is there any way to poke the hardware to see which is which?
>>>
>>> I am sure there are two three different boards out there. Don't know
>>> exact differences between these boards.
>>
>> As far as I can tell, all the boards use the exact same SoC. No differences that
>> I can detect nor aware of. What differs between the different flavors of
>> boards are the perypherals attached: some have WiFi, different LCDs and
>> different cameras. The device tree is able to describe that of course, but the
>> core dtsi part for the SoC itself seem to be OK at least for the 4 different
>> boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan
>> Dock).
>>
>>>
>>> Regards,
>>> Anup
>>>
>>>>
>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>> ---
>>>>> arch/riscv/Kbuild | 1 +
>>>>> arch/riscv/Kconfig | 18 ++++++++++++++++++
>>>>> arch/riscv/boot/dts/Makefile | 4 ++++
>>>>> arch/riscv/kernel/setup.c | 6 ++++++
>>>>> arch/riscv/mm/init.c | 4 ++++
>>>>> 5 files changed, 33 insertions(+)
>>>>>
>>>>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index
>>>>> d1d0aa70fdf1..988804e430e4 100644
>>>>> --- a/arch/riscv/Kbuild
>>>>> +++ b/arch/riscv/Kbuild
>>>>> @@ -1,3 +1,4 @@
>>>>> # SPDX-License-Identifier: GPL-2.0-only
>>>>>
>>>>> obj-y += kernel/ mm/ net/
>>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
>>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
>>>>> 1a3b5a5276be..28899e15f548 100644
>>>>> --- a/arch/riscv/Kconfig
>>>>> +++ b/arch/riscv/Kconfig
>>>>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
>>>>>
>>>>> endchoice
>>>>>
>>>>> +config USE_BUILTIN_DTB
>>>>> + bool "Use builtin DTB"
>>>>> + help
>>>>> + Link a device tree blob for particular hardware into the kernel,
>>>>> + suppressing use of the DTB pointer provided by the bootloader.
>>>>> + This option should only be used with hardware or bootloaders that
>>>>> + are not capable of providing a DTB to the kernel, or for
>>>>> + experimental hardware without stable device tree bindings.
>>>>> +
>>>>> +config BUILTIN_DTB_SOURCE
>>>>> + string "Source file for builtin DTB"
>>>>> + default ""
>>>>> + depends on USE_BUILTIN_DTB
>>>>> + help
>>>>> + Base name (without suffix, relative to arch/riscv/boot/dts) for
>>>>> + the a DTS file that will be used to produce the DTB linked into
>>>>> + the kernel.
>>>>> +
>>>>> endmenu
>>>>>
>>>>> menu "Power management options"
>>>>> diff --git a/arch/riscv/boot/dts/Makefile
>>>>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d
>>>>> 100644
>>>>> --- a/arch/riscv/boot/dts/Makefile
>>>>> +++ b/arch/riscv/boot/dts/Makefile
>>>>> @@ -1,2 +1,6 @@
>>>>> # SPDX-License-Identifier: GPL-2.0
>>>>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
>>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst
>>>>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
>>>>> +else
>>>>> subdir-y += sifive
>>>>> +endif
>>>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>>>>> index 0a6d415b0a5a..3e89be9d888c 100644
>>>>> --- a/arch/riscv/kernel/setup.c
>>>>> +++ b/arch/riscv/kernel/setup.c
>>>>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
>>>>>
>>>>> setup_bootmem();
>>>>> paging_init();
>>>>> +
>>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
>>>>> + unflatten_and_copy_device_tree();
>>>>> +#else
>>>>> unflatten_device_tree();
>>>>> +#endif
>>>>> +
>>>>> clint_init_boot_cpu();
>>>>>
>>>>> #ifdef CONFIG_SWIOTLB
>>>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index
>>>>> 965a8cf4829c..1274e889d008 100644
>>>>> --- a/arch/riscv/mm/init.c
>>>>> +++ b/arch/riscv/mm/init.c
>>>>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else
>>>>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
>>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
>>>>> + dtb_early_va = __dtb_start;
>>>>> +#else
>>>>> dtb_early_va = (void *)dtb_pa;
>>>>> +#endif
>>>>> }
>>>>>
>>>>> static inline void setup_vm_final(void)
>>>
>>
>>
>> --
>> Damien Le Moal
>> Western Digital Research
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 5:14 ` Damien Le Moal
2020-03-05 5:37 ` Anup Patel
@ 2020-03-05 8:18 ` Atish Patra
2020-03-07 0:02 ` Sean Anderson
2020-03-06 23:56 ` Sean Anderson
2 siblings, 1 reply; 89+ messages in thread
From: Atish Patra @ 2020-03-05 8:18 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2020/03/05 13:58, Anup Patel wrote:
> >
> >
> >> -----Original Message-----
> >> From: Palmer Dabbelt <palmer@dabbelt.com>
> >> Sent: 05 March 2020 00:59
> >> To: Damien Le Moal <Damien.LeMoal@wdc.com>
> >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> >> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
> >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
> >>
> >> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
> >>> Enable a kernel builtin dtb for boards not capable of providing a
> >>> device tree to the kernel.
> >>
> >> I'd prefer if we picked a mechanism that allows a single kernel binary to be
> >> run on multiple systems. I think there's two use cases here:
> >
> > I strongly support "single kernel binary for multiple systems" but it's for
> > different purpose here.
> >
> >>
> >> * Bootloaders that provide no DTB at all.
> >> * Bootloaders that provied a DTB that, for some reason, isn't usable.
>
> Sure, but as Anup mentions below, the current use case it to not even use any
> bootloader at all for the K210 since that brings no value at all (in my
> opinion). More on this below.
>
> >>
> >> Given those constraints, could we do something similar to the early fixups?
> >> I'm thinking we could build a mapping between a hardware identifier and a
> >> DTB, then look up the DTB we want to use. Users that want a kernel that
> >> only runs on a single device can do so by configuring only a single DTB, users
> >> that want a more portable kernel can select a bunch -- that's essentially the
> >> same as how we're treating everything else (for example, the
> >> CONFIG_SOC_* stuff).
> >
> > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
> > boots directly. The BUILTIN_DTB is only applicable to cases where there is
> > no bootloader before kernel.
> >
> > The Linux RISC-V NOMMU will tend be used in cases where:
> > 1. There is no bootloader and kernel boots directly hence we need
> > builtin DTB feature.
> > 2. There is very less RAM so we will have to build kernel specific to
> > a particular platform with bare minimum drivers. Due to this, we will
> > have separate defconfig for NOMMU platforms.
> >
> > I think point1 can be tackled if we enforce having bootloader (such as U-Boot)
> > for NOMMU systems and drop this patch.
>
> But that would go against point 2 as that will use more memory... By "drop this
> patch", may be you meant to say "not use this config option" ?
>
> > For point2 above, we don't have much alternatives other than reducing
> > kernel binary size by disabling unwanted drivers.
>
> And not using a boot loader. Sean got U-boot working with Kendryte, so it is not
> that we cannot make it work. It is only that it may be less optimal due to the
> memory used by the boot loader itself. Unless we can recover it if the kernel
> relocate itself over it ? Surely doable, but it does sound to me like an
> overkill for this particular use case, i.e. a tiny, hyper-embedded board where
> running Linux is probably not the best choice in the first place, at least when
> looking at real applications. The story is different for "hobbyist" level. My
> on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
> case after all :)
>
Just a thought: How about keeping the loader out of kernel as a
separate project as a tinyloader ?
That tinyloader project can host the DTB and pass it to kernel in a1
register. This tinyloader can be used for
any M-mode only platforms with memory constraints. If platform has
sufficient memory and supports U-boot, users can use that as well.
That will allow single kernel image to boot all the platforms and we
can mandate one booting protocol for all platforms.
Otherwise, we have to specify different booting protocol for
M-Mode/NoMMU linux and S-mode Linux.
In future, there may be more platforms with Builtin DTB request as well.
> >
> >>
> >> For the hardware ID, could we do something like:
> >>
> >> * Check for the top-level DT compatible string, on systems where we have a
> >> provided DTB.
> >> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some
> >> sort of
> >> masking functionality if we later need one. These are availiable via SBI
> >> calls, but I'd be inclined to restrict them to M-mode boot and just say the
> >> SBI must provide a device tree with at least a suitable compatible string.
> >>
> >> While I suppose we could put together a tool for generating these tables, for
> >> now we could probably just stick the mappings in a table for now given that
> >> there's only one of them.
> >>
> >> That said, I'm not sure what to do about the different Kendryte boards -- is
> >> there any way to poke the hardware to see which is which?
> >
> > I am sure there are two three different boards out there. Don't know exact
> > differences between these boards.
>
> As far as I can tell, all the boards use the exact same SoC. No differences that
> I can detect nor aware of. What differs between the different flavors of boards
> are the perypherals attached: some have WiFi, different LCDs and different
> cameras. The device tree is able to describe that of course, but the core dtsi
> part for the SoC itself seem to be OK at least for the 4 different boards I have
> (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan Dock).
>
> >
> > Regards,
> > Anup
> >
> >>
> >>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >>> ---
> >>> arch/riscv/Kbuild | 1 +
> >>> arch/riscv/Kconfig | 18 ++++++++++++++++++
> >>> arch/riscv/boot/dts/Makefile | 4 ++++
> >>> arch/riscv/kernel/setup.c | 6 ++++++
> >>> arch/riscv/mm/init.c | 4 ++++
> >>> 5 files changed, 33 insertions(+)
> >>>
> >>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index
> >>> d1d0aa70fdf1..988804e430e4 100644
> >>> --- a/arch/riscv/Kbuild
> >>> +++ b/arch/riscv/Kbuild
> >>> @@ -1,3 +1,4 @@
> >>> # SPDX-License-Identifier: GPL-2.0-only
> >>>
> >>> obj-y += kernel/ mm/ net/
> >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
> >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> >>> 1a3b5a5276be..28899e15f548 100644
> >>> --- a/arch/riscv/Kconfig
> >>> +++ b/arch/riscv/Kconfig
> >>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
> >>>
> >>> endchoice
> >>>
> >>> +config USE_BUILTIN_DTB
> >>> + bool "Use builtin DTB"
> >>> + help
> >>> + Link a device tree blob for particular hardware into the kernel,
> >>> + suppressing use of the DTB pointer provided by the bootloader.
> >>> + This option should only be used with hardware or bootloaders that
> >>> + are not capable of providing a DTB to the kernel, or for
> >>> + experimental hardware without stable device tree bindings.
> >>> +
> >>> +config BUILTIN_DTB_SOURCE
> >>> + string "Source file for builtin DTB"
> >>> + default ""
> >>> + depends on USE_BUILTIN_DTB
> >>> + help
> >>> + Base name (without suffix, relative to arch/riscv/boot/dts) for
> >>> + the a DTS file that will be used to produce the DTB linked into
> >>> + the kernel.
> >>> +
> >>> endmenu
> >>>
> >>> menu "Power management options"
> >>> diff --git a/arch/riscv/boot/dts/Makefile
> >>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644
> >>> --- a/arch/riscv/boot/dts/Makefile
> >>> +++ b/arch/riscv/boot/dts/Makefile
> >>> @@ -1,2 +1,6 @@
> >>> # SPDX-License-Identifier: GPL-2.0
> >>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst
> >>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> >>> +else
> >>> subdir-y += sifive
> >>> +endif
> >>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> >>> index 0a6d415b0a5a..3e89be9d888c 100644
> >>> --- a/arch/riscv/kernel/setup.c
> >>> +++ b/arch/riscv/kernel/setup.c
> >>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
> >>>
> >>> setup_bootmem();
> >>> paging_init();
> >>> +
> >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> >>> + unflatten_and_copy_device_tree();
> >>> +#else
> >>> unflatten_device_tree();
> >>> +#endif
> >>> +
> >>> clint_init_boot_cpu();
> >>>
> >>> #ifdef CONFIG_SWIOTLB
> >>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index
> >>> 965a8cf4829c..1274e889d008 100644
> >>> --- a/arch/riscv/mm/init.c
> >>> +++ b/arch/riscv/mm/init.c
> >>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else
> >>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
> >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> >>> + dtb_early_va = __dtb_start;
> >>> +#else
> >>> dtb_early_va = (void *)dtb_pa;
> >>> +#endif
> >>> }
> >>>
> >>> static inline void setup_vm_final(void)
> >
>
>
> --
> Damien Le Moal
> Western Digital Research
>
--
Regards,
Atish
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 5:14 ` Damien Le Moal
2020-03-05 5:37 ` Anup Patel
2020-03-05 8:18 ` Atish Patra
@ 2020-03-06 23:56 ` Sean Anderson
2 siblings, 0 replies; 89+ messages in thread
From: Sean Anderson @ 2020-03-06 23:56 UTC (permalink / raw)
To: Damien Le Moal, Anup Patel, Palmer Dabbelt; +Cc: linux-riscv, Paul Walmsley
On 3/5/20 12:14 AM, Damien Le Moal wrote:
> On 2020/03/05 13:58, Anup Patel wrote:
>>
>>
>>> -----Original Message-----
>>> From: Palmer Dabbelt <palmer@dabbelt.com>
>>> Sent: 05 March 2020 00:59
>>> To: Damien Le Moal <Damien.LeMoal@wdc.com>
>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>>>
>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
>>>> Enable a kernel builtin dtb for boards not capable of providing a
>>>> device tree to the kernel.
>>>
>>> I'd prefer if we picked a mechanism that allows a single kernel binary to be
>>> run on multiple systems. I think there's two use cases here:
>>
>> I strongly support "single kernel binary for multiple systems" but it's for
>> different purpose here.
>>
>>>
>>> * Bootloaders that provide no DTB at all.
>>> * Bootloaders that provied a DTB that, for some reason, isn't usable.
>
> Sure, but as Anup mentions below, the current use case it to not even use any
> bootloader at all for the K210 since that brings no value at all (in my
> opinion). More on this below.
>
>>>
>>> Given those constraints, could we do something similar to the early fixups?
>>> I'm thinking we could build a mapping between a hardware identifier and a
>>> DTB, then look up the DTB we want to use. Users that want a kernel that
>>> only runs on a single device can do so by configuring only a single DTB, users
>>> that want a more portable kernel can select a bunch -- that's essentially the
>>> same as how we're treating everything else (for example, the
>>> CONFIG_SOC_* stuff).
>>
>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
>> boots directly. The BUILTIN_DTB is only applicable to cases where there is
>> no bootloader before kernel.
>>
>> The Linux RISC-V NOMMU will tend be used in cases where:
>> 1. There is no bootloader and kernel boots directly hence we need
>> builtin DTB feature.
>> 2. There is very less RAM so we will have to build kernel specific to
>> a particular platform with bare minimum drivers. Due to this, we will
>> have separate defconfig for NOMMU platforms.
>>
>> I think point1 can be tackled if we enforce having bootloader (such as U-Boot)
>> for NOMMU systems and drop this patch.
>
> But that would go against point 2 as that will use more memory... By "drop this
> patch", may be you meant to say "not use this config option" ?
>
>> For point2 above, we don't have much alternatives other than reducing
>> kernel binary size by disabling unwanted drivers.
>
> And not using a boot loader. Sean got U-boot working with Kendryte, so it is not
> that we cannot make it work. It is only that it may be less optimal due to the
> memory used by the boot loader itself. Unless we can recover it if the kernel
> relocate itself over it ? Surely doable, but it does sound to me like an
> overkill for this particular use case, i.e. a tiny, hyper-embedded board where
> running Linux is probably not the best choice in the first place, at least when
> looking at real applications. The story is different for "hobbyist" level. My
> on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
> case after all :)
At the moment there is not too much reason to use a bootloader outside
of helping debugging/experimenting. I would like to get support to where
one can boot off the MMC slot, or perhaps over the network via the ESP32
chip on some boards. This is something that the built-in firmware cannot
do.
>>>
>>> For the hardware ID, could we do something like:
>>>
>>> * Check for the top-level DT compatible string, on systems where we have a
>>> provided DTB.
>>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some
>>> sort of
>>> masking functionality if we later need one. These are availiable via SBI
>>> calls, but I'd be inclined to restrict them to M-mode boot and just say the
>>> SBI must provide a device tree with at least a suitable compatible string.
>>>
>>> While I suppose we could put together a tool for generating these tables, for
>>> now we could probably just stick the mappings in a table for now given that
>>> there's only one of them.
>>>
>>> That said, I'm not sure what to do about the different Kendryte boards -- is
>>> there any way to poke the hardware to see which is which?
>>
>> I am sure there are two three different boards out there. Don't know exact
>> differences between these boards.
>
> As far as I can tell, all the boards use the exact same SoC. No differences that
> I can detect nor aware of. What differs between the different flavors of boards
> are the perypherals attached: some have WiFi, different LCDs and different
> cameras. The device tree is able to describe that of course, but the core dtsi
> part for the SoC itself seem to be OK at least for the 4 different boards I have
> (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan Dock).
Yeah, as far as I can tell the only difference is in peripherals.
Perhaps there are some differences in the firmware? There are some
hardware descriptions at 0x88001C00 and up, but they only describe the
SoC. We could try and compare dumps of the firmware. I currently have a
Maix BitM and a Maixduino.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 8:18 ` Atish Patra
@ 2020-03-07 0:02 ` Sean Anderson
2020-03-07 1:51 ` Atish Patra
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-03-07 0:02 UTC (permalink / raw)
To: Atish Patra, Damien Le Moal
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 3/5/20 3:18 AM, Atish Patra wrote:
> On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>
>> On 2020/03/05 13:58, Anup Patel wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Palmer Dabbelt <palmer@dabbelt.com>
>>>> Sent: 05 March 2020 00:59
>>>> To: Damien Le Moal <Damien.LeMoal@wdc.com>
>>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
>>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
>>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
>>>>
>>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
>>>>> Enable a kernel builtin dtb for boards not capable of providing a
>>>>> device tree to the kernel.
>>>>
>>>> I'd prefer if we picked a mechanism that allows a single kernel binary to be
>>>> run on multiple systems. I think there's two use cases here:
>>>
>>> I strongly support "single kernel binary for multiple systems" but it's for
>>> different purpose here.
>>>
>>>>
>>>> * Bootloaders that provide no DTB at all.
>>>> * Bootloaders that provied a DTB that, for some reason, isn't usable.
>>
>> Sure, but as Anup mentions below, the current use case it to not even use any
>> bootloader at all for the K210 since that brings no value at all (in my
>> opinion). More on this below.
>>
>>>>
>>>> Given those constraints, could we do something similar to the early fixups?
>>>> I'm thinking we could build a mapping between a hardware identifier and a
>>>> DTB, then look up the DTB we want to use. Users that want a kernel that
>>>> only runs on a single device can do so by configuring only a single DTB, users
>>>> that want a more portable kernel can select a bunch -- that's essentially the
>>>> same as how we're treating everything else (for example, the
>>>> CONFIG_SOC_* stuff).
>>>
>>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
>>> boots directly. The BUILTIN_DTB is only applicable to cases where there is
>>> no bootloader before kernel.
>>>
>>> The Linux RISC-V NOMMU will tend be used in cases where:
>>> 1. There is no bootloader and kernel boots directly hence we need
>>> builtin DTB feature.
>>> 2. There is very less RAM so we will have to build kernel specific to
>>> a particular platform with bare minimum drivers. Due to this, we will
>>> have separate defconfig for NOMMU platforms.
>>>
>>> I think point1 can be tackled if we enforce having bootloader (such as U-Boot)
>>> for NOMMU systems and drop this patch.
>>
>> But that would go against point 2 as that will use more memory... By "drop this
>> patch", may be you meant to say "not use this config option" ?
>>
>>> For point2 above, we don't have much alternatives other than reducing
>>> kernel binary size by disabling unwanted drivers.
>>
>> And not using a boot loader. Sean got U-boot working with Kendryte, so it is not
>> that we cannot make it work. It is only that it may be less optimal due to the
>> memory used by the boot loader itself. Unless we can recover it if the kernel
>> relocate itself over it ? Surely doable, but it does sound to me like an
>> overkill for this particular use case, i.e. a tiny, hyper-embedded board where
>> running Linux is probably not the best choice in the first place, at least when
>> looking at real applications. The story is different for "hobbyist" level. My
>> on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
>> case after all :)
>>
>
> Just a thought: How about keeping the loader out of kernel as a
> separate project as a tinyloader ?
> That tinyloader project can host the DTB and pass it to kernel in a1
> register. This tinyloader can be used for
> any M-mode only platforms with memory constraints. If platform has
> sufficient memory and supports U-boot, users can use that as well.
> That will allow single kernel image to boot all the platforms and we
> can mandate one booting protocol for all platforms.
> Otherwise, we have to specify different booting protocol for
> M-Mode/NoMMU linux and S-mode Linux.
> In future, there may be more platforms with Builtin DTB request as well.
Couldn't this sort of thing be done by SBI? OpenSBI currently has a port
for the K210. The only issue with SBI in general is that there is no way
to set the VM mode, since it is stored in mstatus and not satp on older
priv spec versions. There used to be a proposal related to this, but
they chose to change the location of the VM mode rather than have SBI or
some other bootloader set it. I think one of the ideas was for SBI to
set the mode based off the mmu-type property.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-02 5:08 ` Damien Le Moal
@ 2020-03-07 0:18 ` Sean Anderson
2020-03-07 4:11 ` Anup Patel
0 siblings, 1 reply; 89+ messages in thread
From: Sean Anderson @ 2020-03-07 0:18 UTC (permalink / raw)
To: Damien Le Moal, Anup Patel
Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On 3/2/20 12:08 AM, Damien Le Moal wrote:
> On 2020/03/02 14:05, Anup Patel wrote:
>> On Mon, Mar 2, 2020 at 10:21 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>
>>> On 2020/03/02 13:22, Anup Patel wrote:
>>>> On Mon, Mar 2, 2020 at 9:46 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>
>>>>> On 2020/03/02 13:07, Anup Patel wrote:
>>>>> [...]
>>>>>>> + sram0: memory@80000000 {
>>>>>>> + device_type = "memory";
>>>>>>> + reg = <0x80000000 0x400000>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + sram1: memory@80400000 {
>>>>>>> + device_type = "memory";
>>>>>>> + reg = <0x80400000 0x200000>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + kpu_sram: memory@80600000 {
>>>>>>> + device_type = "memory";
>>>>>>> + reg = <0x80600000 0x200000>;
>>>>>>> + };
>>>>>>
>>>>>> No need to have separate DT node for each RAM bank. This can be
>>>>>> express as single DT node as follows:
>>>>>>
>>>>>> sram: memory@80000000 {
>>>>>> device_type = "memory";
>>>>>> reg = <0x80000000 0x400000>,
>>>>>> <0x80400000 0x200000>,
>>>>>> <0x80600000 0x200000>;
>>>>>> };
>>>>>
>>>>> This is to match the U-boot device tree that Sean wrote. So I would rather keep
>>>>> it like this. And strictly speaking, if one wants to add a driver for the KPU,
>>>>> having the kpu memory segment for it separate makes it easy to reference it from
>>>>> a kpu device entry. But granted, the two sram segments can be declared with a
>>>>> single memory entry.
There is no clear documentation on how to do this, so I have been mostly
just trying things until they work. In U-Boot, separate memory device
nodes are treated as different "banks".
>>>>
>>>> But, that's not the preferred way of describing memory banks on the
>>>> same machine.
>>>> Usually, we create multiple memory DT nodes for NUMA systems.
>>>>
>>>> You can also refer various ARM/ARM64 DTS files.
>>>
>>> Oops... Sent an answer to this to the wrong email... Here it is again:
>>>
>>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
>>> special as by default it is not usable as regular SRAM. I think it may be better
>>> to reflect that in the device tree. The K210 soc_early_init() call back can
>>> probe for that special entry too to see if it has to be turned on for use as
>>> regular memory or not (i.e. if a kpu driver will use it).
>>>
>>> Since booting Linux with 6MB of memory will be even more challenging than with
>>> 8, I agree that we may never see the case of a kpu driver being used. But I
>>> personally like making that special case clear in the device tree. No strong
>>> objection to your simplification though. So if you really object, I will go with it.
>>>
>>
>> I understand that it is helping you to distinguish last 2MB segment but this is
>> also possible using with single memory DT node as follows:
>>
>> sram: memory@80000000 {
>> device_type = "memory";
>> reg = <0x80000000 0x400000>,
>> <0x80400000 0x200000>,
>> <0x80600000 0x200000>;
>> reg-names = "sram0", "sram1", "kpu_sram";
>> };
>
> Nice trick. I did not know about it. Will use that then !
>>
>> The K210 soc_early_init() can do the following:
>> 1. Find memory DT node having device_type = "memory"
>> 2. Find bank number for "kpu_sram" based on "reg-names DT property
>> 3. Get based address of KPU SRAM from "reg" property based on bank
>> number found in step2 above.
>>
>> The reg-names is a standard DT property used to distinguish multiple
>> memory regions of device. Same can be used to distinguish multiple
>> banks of memory DT node.
>>
>> I am not adamant on having single memory DT node but just wanted
>> to let you know that this is not a preferred way for non-NUMA system.
Anup, do you have any suggestions on how to describe clocks for each
bank? I think the kpu sram may need some clock manipulation to work
properly. Perhaps something like
sram: memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x400000>,
<0x80400000 0x200000>,
<0x80600000 0x200000>;
reg-names = "sram0", "sram1", "kpu_sram";
clocks = <&sysclk K210_CLK_SRAM0>,
<&sysclk K210_CLK_SRAM1>,
<&sysclk K210_CLK_PLL1>;
clock-names = "sram0", "sram1", "kpu";
};
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-07 0:02 ` Sean Anderson
@ 2020-03-07 1:51 ` Atish Patra
2020-03-07 2:08 ` Sean Anderson
0 siblings, 1 reply; 89+ messages in thread
From: Atish Patra @ 2020-03-07 1:51 UTC (permalink / raw)
To: atishp, Damien Le Moal, seanga2
Cc: linux-riscv, Anup Patel, palmer, paul.walmsley
On Fri, 2020-03-06 at 19:02 -0500, Sean Anderson wrote:
> On 3/5/20 3:18 AM, Atish Patra wrote:
> > On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal <
> > Damien.LeMoal@wdc.com> wrote:
> > > On 2020/03/05 13:58, Anup Patel wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Palmer Dabbelt <palmer@dabbelt.com>
> > > > > Sent: 05 March 2020 00:59
> > > > > To: Damien Le Moal <Damien.LeMoal@wdc.com>
> > > > > Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> > > > > <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
> > > > > Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
> > > > >
> > > > > On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal
> > > > > wrote:
> > > > > > Enable a kernel builtin dtb for boards not capable of
> > > > > > providing a
> > > > > > device tree to the kernel.
> > > > >
> > > > > I'd prefer if we picked a mechanism that allows a single
> > > > > kernel binary to be
> > > > > run on multiple systems. I think there's two use cases here:
> > > >
> > > > I strongly support "single kernel binary for multiple systems"
> > > > but it's for
> > > > different purpose here.
> > > >
> > > > > * Bootloaders that provide no DTB at all.
> > > > > * Bootloaders that provied a DTB that, for some reason, isn't
> > > > > usable.
> > >
> > > Sure, but as Anup mentions below, the current use case it to not
> > > even use any
> > > bootloader at all for the K210 since that brings no value at all
> > > (in my
> > > opinion). More on this below.
> > >
> > > > > Given those constraints, could we do something similar to the
> > > > > early fixups?
> > > > > I'm thinking we could build a mapping between a hardware
> > > > > identifier and a
> > > > > DTB, then look up the DTB we want to use. Users that want a
> > > > > kernel that
> > > > > only runs on a single device can do so by configuring only a
> > > > > single DTB, users
> > > > > that want a more portable kernel can select a bunch -- that's
> > > > > essentially the
> > > > > same as how we're treating everything else (for example, the
> > > > > CONFIG_SOC_* stuff).
> > > >
> > > > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU
> > > > kernel
> > > > boots directly. The BUILTIN_DTB is only applicable to cases
> > > > where there is
> > > > no bootloader before kernel.
> > > >
> > > > The Linux RISC-V NOMMU will tend be used in cases where:
> > > > 1. There is no bootloader and kernel boots directly hence we
> > > > need
> > > > builtin DTB feature.
> > > > 2. There is very less RAM so we will have to build kernel
> > > > specific to
> > > > a particular platform with bare minimum drivers. Due to this,
> > > > we will
> > > > have separate defconfig for NOMMU platforms.
> > > >
> > > > I think point1 can be tackled if we enforce having bootloader
> > > > (such as U-Boot)
> > > > for NOMMU systems and drop this patch.
> > >
> > > But that would go against point 2 as that will use more memory...
> > > By "drop this
> > > patch", may be you meant to say "not use this config option" ?
> > >
> > > > For point2 above, we don't have much alternatives other than
> > > > reducing
> > > > kernel binary size by disabling unwanted drivers.
> > >
> > > And not using a boot loader. Sean got U-boot working with
> > > Kendryte, so it is not
> > > that we cannot make it work. It is only that it may be less
> > > optimal due to the
> > > memory used by the boot loader itself. Unless we can recover it
> > > if the kernel
> > > relocate itself over it ? Surely doable, but it does sound to me
> > > like an
> > > overkill for this particular use case, i.e. a tiny, hyper-
> > > embedded board where
> > > running Linux is probably not the best choice in the first place,
> > > at least when
> > > looking at real applications. The story is different for
> > > "hobbyist" level. My
> > > on-going 6 DoF robotic arm project controlled with Linux on K210
> > > is a valid use
> > > case after all :)
> > >
> >
> > Just a thought: How about keeping the loader out of kernel as a
> > separate project as a tinyloader ?
> > That tinyloader project can host the DTB and pass it to kernel in
> > a1
> > register. This tinyloader can be used for
> > any M-mode only platforms with memory constraints. If platform has
> > sufficient memory and supports U-boot, users can use that as well.
> > That will allow single kernel image to boot all the platforms and
> > we
> > can mandate one booting protocol for all platforms.
> > Otherwise, we have to specify different booting protocol for
> > M-Mode/NoMMU linux and S-mode Linux.
> > In future, there may be more platforms with Builtin DTB request as
> > well.
>
> Couldn't this sort of thing be done by SBI? OpenSBI currently has a
> port
> for the K210. The only issue with SBI in general is that there is no
> way
> to set the VM mode, since it is stored in mstatus and not satp on
> older
> priv spec versions. There used to be a proposal related to this, but
> they chose to change the location of the VM mode rather than have SBI
> or
> some other bootloader set it. I think one of the ideas was for SBI to
> set the mode based off the mmu-type property.
>
Just to avoid confusion: SBI is the specification and OpenSBI is the
implementation. I think you meant OpenSBI here. It is possible but the
question is whether it should be done by OpenSBI. Because OpenSBI is
supposed to provide the SBI implementation. As NOMMU Linux doesn't need
any of the SBI, I think it would be unnecessary to keep the OpenSBI
code resident after Linux boots.
I think U-Boot or a separate loader is an ideal solution but I see
your U-Boot patches mention that loading an Image still is an issue.
However, everybody needs to agree that booting single Linux kernel
image on all boards(at least supported in upstream Linux)
can be documented as a hard requirement before we discuss more on this
topic. If that is possible, it is easier to enforce booting protocol
(a0 - hartid, a1 - DTB and no builtin DTB) as well. I am not sure if
that is the best approach but that's what we have currently.
> --Sean
>
--
Regards,
Atish
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-07 1:51 ` Atish Patra
@ 2020-03-07 2:08 ` Sean Anderson
0 siblings, 0 replies; 89+ messages in thread
From: Sean Anderson @ 2020-03-07 2:08 UTC (permalink / raw)
To: Atish Patra, atishp, Damien Le Moal
Cc: linux-riscv, Anup Patel, palmer, paul.walmsley
> Just to avoid confusion: SBI is the specification and OpenSBI is the
> implementation. I think you meant OpenSBI here. It is possible but the
> question is whether it should be done by OpenSBI. Because OpenSBI is
> supposed to provide the SBI implementation. As NOMMU Linux doesn't need
> any of the SBI, I think it would be unnecessary to keep the OpenSBI
> code resident after Linux boots.
I mean OpenSBI when I talk about it having support. I mean SBI when I
talk about setting up the MMU. You're right that M-mode linux doesn't
need it, though these are some issues we will need to deal with when
looking at an S-mode port.
>
> I think U-Boot or a separate loader is an ideal solution but I see
> your U-Boot patches mention that loading an Image still is an issue.
Yeah, I suspect it's just a memory layout problem. Hopefully I can
figure out how to get everything working.
> However, everybody needs to agree that booting single Linux kernel
> image on all boards(at least supported in upstream Linux)
> can be documented as a hard requirement before we discuss more on this
> topic. If that is possible, it is easier to enforce booting protocol
> (a0 - hartid, a1 - DTB and no builtin DTB) as well. I am not sure if
> that is the best approach but that's what we have currently.
I think it is a good goal to have one kernel for all the K210 boards,
and just have different device trees.
--Sean
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-03-07 0:18 ` Sean Anderson
@ 2020-03-07 4:11 ` Anup Patel
0 siblings, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-07 4:11 UTC (permalink / raw)
To: Sean Anderson
Cc: Damien Le Moal, Anup Patel, Palmer Dabbelt, linux-riscv, Paul Walmsley
On Sat, Mar 7, 2020 at 5:48 AM Sean Anderson <seanga2@gmail.com> wrote:
>
> On 3/2/20 12:08 AM, Damien Le Moal wrote:
> > On 2020/03/02 14:05, Anup Patel wrote:
> >> On Mon, Mar 2, 2020 at 10:21 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>>
> >>> On 2020/03/02 13:22, Anup Patel wrote:
> >>>> On Mon, Mar 2, 2020 at 9:46 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>>>>
> >>>>> On 2020/03/02 13:07, Anup Patel wrote:
> >>>>> [...]
> >>>>>>> + sram0: memory@80000000 {
> >>>>>>> + device_type = "memory";
> >>>>>>> + reg = <0x80000000 0x400000>;
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + sram1: memory@80400000 {
> >>>>>>> + device_type = "memory";
> >>>>>>> + reg = <0x80400000 0x200000>;
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + kpu_sram: memory@80600000 {
> >>>>>>> + device_type = "memory";
> >>>>>>> + reg = <0x80600000 0x200000>;
> >>>>>>> + };
> >>>>>>
> >>>>>> No need to have separate DT node for each RAM bank. This can be
> >>>>>> express as single DT node as follows:
> >>>>>>
> >>>>>> sram: memory@80000000 {
> >>>>>> device_type = "memory";
> >>>>>> reg = <0x80000000 0x400000>,
> >>>>>> <0x80400000 0x200000>,
> >>>>>> <0x80600000 0x200000>;
> >>>>>> };
> >>>>>
> >>>>> This is to match the U-boot device tree that Sean wrote. So I would rather keep
> >>>>> it like this. And strictly speaking, if one wants to add a driver for the KPU,
> >>>>> having the kpu memory segment for it separate makes it easy to reference it from
> >>>>> a kpu device entry. But granted, the two sram segments can be declared with a
> >>>>> single memory entry.
>
> There is no clear documentation on how to do this, so I have been mostly
> just trying things until they work. In U-Boot, separate memory device
> nodes are treated as different "banks".
>
> >>>>
> >>>> But, that's not the preferred way of describing memory banks on the
> >>>> same machine.
> >>>> Usually, we create multiple memory DT nodes for NUMA systems.
> >>>>
> >>>> You can also refer various ARM/ARM64 DTS files.
> >>>
> >>> Oops... Sent an answer to this to the wrong email... Here it is again:
> >>>
> >>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
> >>> special as by default it is not usable as regular SRAM. I think it may be better
> >>> to reflect that in the device tree. The K210 soc_early_init() call back can
> >>> probe for that special entry too to see if it has to be turned on for use as
> >>> regular memory or not (i.e. if a kpu driver will use it).
> >>>
> >>> Since booting Linux with 6MB of memory will be even more challenging than with
> >>> 8, I agree that we may never see the case of a kpu driver being used. But I
> >>> personally like making that special case clear in the device tree. No strong
> >>> objection to your simplification though. So if you really object, I will go with it.
> >>>
> >>
> >> I understand that it is helping you to distinguish last 2MB segment but this is
> >> also possible using with single memory DT node as follows:
> >>
> >> sram: memory@80000000 {
> >> device_type = "memory";
> >> reg = <0x80000000 0x400000>,
> >> <0x80400000 0x200000>,
> >> <0x80600000 0x200000>;
> >> reg-names = "sram0", "sram1", "kpu_sram";
> >> };
> >
> > Nice trick. I did not know about it. Will use that then !
> >>
> >> The K210 soc_early_init() can do the following:
> >> 1. Find memory DT node having device_type = "memory"
> >> 2. Find bank number for "kpu_sram" based on "reg-names DT property
> >> 3. Get based address of KPU SRAM from "reg" property based on bank
> >> number found in step2 above.
> >>
> >> The reg-names is a standard DT property used to distinguish multiple
> >> memory regions of device. Same can be used to distinguish multiple
> >> banks of memory DT node.
> >>
> >> I am not adamant on having single memory DT node but just wanted
> >> to let you know that this is not a preferred way for non-NUMA system.
>
> Anup, do you have any suggestions on how to describe clocks for each
> bank? I think the kpu sram may need some clock manipulation to work
> properly. Perhaps something like
>
> sram: memory@80000000 {
> device_type = "memory";
> reg = <0x80000000 0x400000>,
> <0x80400000 0x200000>,
> <0x80600000 0x200000>;
> reg-names = "sram0", "sram1", "kpu_sram";
> clocks = <&sysclk K210_CLK_SRAM0>,
> <&sysclk K210_CLK_SRAM1>,
> <&sysclk K210_CLK_PLL1>;
> clock-names = "sram0", "sram1", "kpu";
Yes, using "clock-names" to distinguish different clocks
of same device is the right way.
Regards,
Anup
> };
>
> --Sean
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
2020-03-05 6:13 ` Damien Le Moal
@ 2020-03-08 6:10 ` Anup Patel
0 siblings, 0 replies; 89+ messages in thread
From: Anup Patel @ 2020-03-08 6:10 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv, Anup Patel, Palmer Dabbelt, Paul Walmsley
On Thu, Mar 5, 2020 at 11:43 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2020/03/05 14:37, Anup Patel wrote:
> >
> >
> >> -----Original Message-----
> >> From: Damien Le Moal
> >> Sent: 05 March 2020 10:44
> >> To: Anup Patel <Anup.Patel@wdc.com>; Palmer Dabbelt
> >> <palmer@dabbelt.com>
> >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> >> <paul.walmsley@sifive.com>
> >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
> >>
> >> On 2020/03/05 13:58, Anup Patel wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Palmer Dabbelt <palmer@dabbelt.com>
> >>>> Sent: 05 March 2020 00:59
> >>>> To: Damien Le Moal <Damien.LeMoal@wdc.com>
> >>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> >>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
> >>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
> >>>>
> >>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote:
> >>>>> Enable a kernel builtin dtb for boards not capable of providing a
> >>>>> device tree to the kernel.
> >>>>
> >>>> I'd prefer if we picked a mechanism that allows a single kernel
> >>>> binary to be run on multiple systems. I think there's two use cases here:
> >>>
> >>> I strongly support "single kernel binary for multiple systems" but
> >>> it's for different purpose here.
> >>>
> >>>>
> >>>> * Bootloaders that provide no DTB at all.
> >>>> * Bootloaders that provied a DTB that, for some reason, isn't usable.
> >>
> >> Sure, but as Anup mentions below, the current use case it to not even use
> >> any bootloader at all for the K210 since that brings no value at all (in my
> >> opinion). More on this below.
> >>
> >>>>
> >>>> Given those constraints, could we do something similar to the early
> >> fixups?
> >>>> I'm thinking we could build a mapping between a hardware identifier
> >>>> and a DTB, then look up the DTB we want to use. Users that want a
> >>>> kernel that only runs on a single device can do so by configuring
> >>>> only a single DTB, users that want a more portable kernel can select
> >>>> a bunch -- that's essentially the same as how we're treating
> >>>> everything else (for example, the
> >>>> CONFIG_SOC_* stuff).
> >>>
> >>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel
> >>> boots directly. The BUILTIN_DTB is only applicable to cases where
> >>> there is no bootloader before kernel.
> >>>
> >>> The Linux RISC-V NOMMU will tend be used in cases where:
> >>> 1. There is no bootloader and kernel boots directly hence we need
> >>> builtin DTB feature.
> >>> 2. There is very less RAM so we will have to build kernel specific to
> >>> a particular platform with bare minimum drivers. Due to this, we will
> >>> have separate defconfig for NOMMU platforms.
> >>>
> >>> I think point1 can be tackled if we enforce having bootloader (such as
> >>> U-Boot) for NOMMU systems and drop this patch.
> >>
> >> But that would go against point 2 as that will use more memory... By "drop
> >> this patch", may be you meant to say "not use this config option" ?
> >
> > I meant to use U-Boot on Kendryte to launch kernel.
> >
> >>
> >>> For point2 above, we don't have much alternatives other than reducing
> >>> kernel binary size by disabling unwanted drivers.
> >>
> >> And not using a boot loader. Sean got U-boot working with Kendryte, so it is
> >> not that we cannot make it work. It is only that it may be less optimal due to
> >> the memory used by the boot loader itself. Unless we can recover it if the
> >> kernel relocate itself over it ? Surely doable, but it does sound to me like an
> >> overkill for this particular use case, i.e. a tiny, hyper-embedded board where
> >> running Linux is probably not the best choice in the first place, at least when
> >> looking at real applications. The story is different for "hobbyist" level. My on-
> >> going 6 DoF robotic arm project controlled with Linux on K210 is a valid use
> >> case after all :)
> >
> > Dropping BUILTIN DTB feature will be more like a Linux RISC-V policy thingy.
> > My suggestion was more about discouraging Linux S-mode users to use the
> > BUILTIN DTB feature.
>
> Got it. For now, we could tie BUILTIN DTB config to !MMU case only. If there is
> a valid use case that pops up for regular MMU/S-mode Linux, it is easy to change.
>
> > I agree that it is difficult to fit a proper boot-flow (having proper bootloader)
> > due to limited RAM. If we don't link DTB to Linux RISC-V NOMMU then some
> > thing else need to provide it hence bootloader suggestion.
>
> OK. Understood and I agree.
>
> >
> > Apart from the Linux RISC-V NOMMU use-case, the BUILTIN DTB feature can
> > be useful in environments such as FPGAs/Palladium where proper bootloader
> > is not available.
>
> OK. But we do not have to enable it for this right away, no ? So should I just
> not allow BUILTIN DTB for MMU==true case for now ?
Making kconfig option BUILTIN_DTB depends on !MMU looks reasonable
to me. Maybe you can send v2 with this change ?
Regards,
Anup
>
> >
> > Regards,
> > Anup
> >
> >>
> >>>
> >>>>
> >>>> For the hardware ID, could we do something like:
> >>>>
> >>>> * Check for the top-level DT compatible string, on systems where we
> >> have a
> >>>> provided DTB.
> >>>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with
> >>>> some sort of
> >>>> masking functionality if we later need one. These are availiable via SBI
> >>>> calls, but I'd be inclined to restrict them to M-mode boot and just say the
> >>>> SBI must provide a device tree with at least a suitable compatible string.
> >>>>
> >>>> While I suppose we could put together a tool for generating these
> >>>> tables, for now we could probably just stick the mappings in a table
> >>>> for now given that there's only one of them.
> >>>>
> >>>> That said, I'm not sure what to do about the different Kendryte
> >>>> boards -- is there any way to poke the hardware to see which is which?
> >>>
> >>> I am sure there are two three different boards out there. Don't know
> >>> exact differences between these boards.
> >>
> >> As far as I can tell, all the boards use the exact same SoC. No differences that
> >> I can detect nor aware of. What differs between the different flavors of
> >> boards are the perypherals attached: some have WiFi, different LCDs and
> >> different cameras. The device tree is able to describe that of course, but the
> >> core dtsi part for the SoC itself seem to be OK at least for the 4 different
> >> boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan
> >> Dock).
> >>
> >>>
> >>> Regards,
> >>> Anup
> >>>
> >>>>
> >>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >>>>> ---
> >>>>> arch/riscv/Kbuild | 1 +
> >>>>> arch/riscv/Kconfig | 18 ++++++++++++++++++
> >>>>> arch/riscv/boot/dts/Makefile | 4 ++++
> >>>>> arch/riscv/kernel/setup.c | 6 ++++++
> >>>>> arch/riscv/mm/init.c | 4 ++++
> >>>>> 5 files changed, 33 insertions(+)
> >>>>>
> >>>>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index
> >>>>> d1d0aa70fdf1..988804e430e4 100644
> >>>>> --- a/arch/riscv/Kbuild
> >>>>> +++ b/arch/riscv/Kbuild
> >>>>> @@ -1,3 +1,4 @@
> >>>>> # SPDX-License-Identifier: GPL-2.0-only
> >>>>>
> >>>>> obj-y += kernel/ mm/ net/
> >>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/
> >>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> >>>>> 1a3b5a5276be..28899e15f548 100644
> >>>>> --- a/arch/riscv/Kconfig
> >>>>> +++ b/arch/riscv/Kconfig
> >>>>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE
> >>>>>
> >>>>> endchoice
> >>>>>
> >>>>> +config USE_BUILTIN_DTB
> >>>>> + bool "Use builtin DTB"
> >>>>> + help
> >>>>> + Link a device tree blob for particular hardware into the kernel,
> >>>>> + suppressing use of the DTB pointer provided by the bootloader.
> >>>>> + This option should only be used with hardware or bootloaders that
> >>>>> + are not capable of providing a DTB to the kernel, or for
> >>>>> + experimental hardware without stable device tree bindings.
> >>>>> +
> >>>>> +config BUILTIN_DTB_SOURCE
> >>>>> + string "Source file for builtin DTB"
> >>>>> + default ""
> >>>>> + depends on USE_BUILTIN_DTB
> >>>>> + help
> >>>>> + Base name (without suffix, relative to arch/riscv/boot/dts) for
> >>>>> + the a DTS file that will be used to produce the DTB linked into
> >>>>> + the kernel.
> >>>>> +
> >>>>> endmenu
> >>>>>
> >>>>> menu "Power management options"
> >>>>> diff --git a/arch/riscv/boot/dts/Makefile
> >>>>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d
> >>>>> 100644
> >>>>> --- a/arch/riscv/boot/dts/Makefile
> >>>>> +++ b/arch/riscv/boot/dts/Makefile
> >>>>> @@ -1,2 +1,6 @@
> >>>>> # SPDX-License-Identifier: GPL-2.0
> >>>>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"")
> >>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst
> >>>>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o
> >>>>> +else
> >>>>> subdir-y += sifive
> >>>>> +endif
> >>>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> >>>>> index 0a6d415b0a5a..3e89be9d888c 100644
> >>>>> --- a/arch/riscv/kernel/setup.c
> >>>>> +++ b/arch/riscv/kernel/setup.c
> >>>>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p)
> >>>>>
> >>>>> setup_bootmem();
> >>>>> paging_init();
> >>>>> +
> >>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> >>>>> + unflatten_and_copy_device_tree();
> >>>>> +#else
> >>>>> unflatten_device_tree();
> >>>>> +#endif
> >>>>> +
> >>>>> clint_init_boot_cpu();
> >>>>>
> >>>>> #ifdef CONFIG_SWIOTLB
> >>>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index
> >>>>> 965a8cf4829c..1274e889d008 100644
> >>>>> --- a/arch/riscv/mm/init.c
> >>>>> +++ b/arch/riscv/mm/init.c
> >>>>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else
> >>>>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) {
> >>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB)
> >>>>> + dtb_early_va = __dtb_start;
> >>>>> +#else
> >>>>> dtb_early_va = (void *)dtb_pa;
> >>>>> +#endif
> >>>>> }
> >>>>>
> >>>>> static inline void setup_vm_final(void)
> >>>
> >>
> >>
> >> --
> >> Damien Le Moal
> >> Western Digital Research
> >
>
>
> --
> Damien Le Moal
> Western Digital Research
>
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-02-22 19:07 ` Wladimir J. van der Laan
@ 2020-04-01 17:55 ` Drew Fustini
2020-04-02 2:24 ` Damien Le Moal
0 siblings, 1 reply; 89+ messages in thread
From: Drew Fustini @ 2020-04-01 17:55 UTC (permalink / raw)
To: Wladimir J. van der Laan
Cc: Carlos Eduardo de Paula, Anup Patel, Damien Le Moal,
Sean Anderson, Palmer Dabbelt, Paul Walmsley, linux-riscv
On Sat, Feb 22, 2020 at 8:07 PM Wladimir J. van der Laan
<laanwj@gmail.com> wrote:
> > > > So the LCD connector is supposed to be for a ST7789V controller, but
> > > > there doesn't appear to be a driver in Linux for it. I don't have an
> > > > appropriate LCD screen, so I will not be able to write a driver.
> > > >
> > >
> > > Actually there is a driver and config DRM_PANEL_SITRONIX_ST7789V, in
> > > gpu/drm/panel/panel-sitronix-st7789v.c and also FB_TFT_ST7789V and
> > > CONFIG_FB_TFT_ST7789V with the driver a in
> > > staging/fbtft/fb_st7789v.c. Might be easier :)
> > >
> > > Weird that the Kendryte SDK refers to the LCD as NT35310
> > > (https://github.com/kendryte/kendryte-standalone-demo/tree/develop/lcd).
> >
> > I remember checking the datasheet for both a while ago and NT35310 and ST7789V
> > seem to be more or less compatible, with only register differences
> > for more obscure functionality.
>
> I just stumbled on this:
> https://forum.kendryte.com/topic/68/a-guide-to-adapt-kendryte-kd233-kpu-demo-to-sipeed-m1
> under "LCD Driver".
>
> So it looks like the K233 uses a nt35310, while Sipeed M1 uses st7789. This is
> a likely explanation for them mentioning both chips in the SDKs.
Hello all,
I have the Sipeed MAiX Go and was wondering if any has made anymore
progress with the LCD.
Is it reasonable to try to use a tinydrm driver to put basic
framebuffer on the LCD?
(so we could see the adorable Tux at boot, etc)
thanks,
drew
^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH 08/10] riscv: Add Kendryte K210 device tree
2020-04-01 17:55 ` Drew Fustini
@ 2020-04-02 2:24 ` Damien Le Moal
0 siblings, 0 replies; 89+ messages in thread
From: Damien Le Moal @ 2020-04-02 2:24 UTC (permalink / raw)
To: Drew Fustini, Wladimir J. van der Laan
Cc: Carlos Eduardo de Paula, Anup Patel, Sean Anderson,
Palmer Dabbelt, Paul Walmsley, linux-riscv
On 2020/04/02 2:55, Drew Fustini wrote:
> On Sat, Feb 22, 2020 at 8:07 PM Wladimir J. van der Laan
> <laanwj@gmail.com> wrote:
>>>>> So the LCD connector is supposed to be for a ST7789V controller, but
>>>>> there doesn't appear to be a driver in Linux for it. I don't have an
>>>>> appropriate LCD screen, so I will not be able to write a driver.
>>>>>
>>>>
>>>> Actually there is a driver and config DRM_PANEL_SITRONIX_ST7789V, in
>>>> gpu/drm/panel/panel-sitronix-st7789v.c and also FB_TFT_ST7789V and
>>>> CONFIG_FB_TFT_ST7789V with the driver a in
>>>> staging/fbtft/fb_st7789v.c. Might be easier :)
>>>>
>>>> Weird that the Kendryte SDK refers to the LCD as NT35310
>>>> (https://github.com/kendryte/kendryte-standalone-demo/tree/develop/lcd).
>>>
>>> I remember checking the datasheet for both a while ago and NT35310 and ST7789V
>>> seem to be more or less compatible, with only register differences
>>> for more obscure functionality.
>>
>> I just stumbled on this:
>> https://forum.kendryte.com/topic/68/a-guide-to-adapt-kendryte-kd233-kpu-demo-to-sipeed-m1
>> under "LCD Driver".
>>
>> So it looks like the K233 uses a nt35310, while Sipeed M1 uses st7789. This is
>> a likely explanation for them mentioning both chips in the SDKs.
>
> Hello all,
>
> I have the Sipeed MAiX Go and was wondering if any has made anymore
> progress with the LCD.
>
> Is it reasonable to try to use a tinydrm driver to put basic
> framebuffer on the LCD?
>
> (so we could see the adorable Tux at boot, etc)
I have not tried. But it may be good to first start with the LCD in text mode
only :)
There are tons of LCD controller drivers under drivers/auxdisplay and
drivers/gpu/drm/panel. The MAIX Go LCD controller is likely already supported.
But you will need to add it to the device tree and fix k210-sysctl driver to
have the proper clock for it. Sean did a lot of work in this area already. We
can use it as a base for improving the device tree and driver I think.
Waiting to get the base series accepted first.
Palmer ? Any update ? You still had concerns about the embedded device tree and
I replied to that. Please let me know what you think.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 89+ messages in thread
end of thread, other threads:[~2020-04-02 2:24 UTC | newest]
Thread overview: 89+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
2020-02-20 0:15 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
2020-02-14 20:18 ` Sean Anderson
2020-02-15 2:15 ` Damien Le Moal
2020-02-15 2:26 ` Sean Anderson
2020-02-15 2:40 ` Damien Le Moal
2020-03-02 3:48 ` Anup Patel
2020-03-04 18:38 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
2020-03-02 3:57 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
2020-03-02 3:58 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
2020-03-05 4:58 ` Anup Patel
2020-03-05 5:14 ` Damien Le Moal
2020-03-05 5:37 ` Anup Patel
2020-03-05 6:13 ` Damien Le Moal
2020-03-08 6:10 ` Anup Patel
2020-03-05 8:18 ` Atish Patra
2020-03-07 0:02 ` Sean Anderson
2020-03-07 1:51 ` Atish Patra
2020-03-07 2:08 ` Sean Anderson
2020-03-06 23:56 ` Sean Anderson
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
2020-02-14 20:31 ` Sean Anderson
2020-03-04 19:38 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
2020-03-02 3:59 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
2020-02-14 20:51 ` Sean Anderson
2020-02-15 2:34 ` Damien Le Moal
2020-02-15 2:48 ` Sean Anderson
2020-02-15 3:00 ` Damien Le Moal
2020-02-18 14:12 ` Carlos Eduardo de Paula
2020-02-18 14:18 ` Sean Anderson
2020-02-18 14:30 ` Carlos Eduardo de Paula
2020-02-18 17:48 ` Sean Anderson
2020-02-18 19:26 ` Carlos Eduardo de Paula
2020-02-19 9:06 ` Wladimir J. van der Laan
2020-02-19 22:28 ` Sean Anderson
2020-02-20 10:48 ` Wladimir J. van der Laan
2020-02-22 19:07 ` Wladimir J. van der Laan
2020-04-01 17:55 ` Drew Fustini
2020-04-02 2:24 ` Damien Le Moal
2020-02-19 8:50 ` Wladimir J. van der Laan
2020-02-27 19:43 ` Sean Anderson
2020-03-02 4:06 ` Anup Patel
2020-03-02 4:15 ` Damien Le Moal
2020-03-02 4:22 ` Anup Patel
2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:05 ` Anup Patel
2020-03-02 5:08 ` Damien Le Moal
2020-03-07 0:18 ` Sean Anderson
2020-03-07 4:11 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
2020-03-02 4:07 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
2020-03-02 4:08 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
2020-02-15 2:02 ` Damien Le Moal
2020-02-17 13:28 ` Carlos Eduardo de Paula
2020-02-26 21:31 ` Carlos Eduardo de Paula
2020-02-27 2:18 ` Damien Le Moal
2020-02-28 20:32 ` Sean Anderson
2020-03-02 3:01 ` Damien Le Moal
2020-03-02 3:53 ` Sean Anderson
2020-03-02 4:11 ` Damien Le Moal
2020-03-02 4:18 ` Sean Anderson
2020-03-02 4:54 ` Damien Le Moal
2020-03-02 4:56 ` Sean Anderson
2020-03-02 5:03 ` Damien Le Moal
2020-03-02 4:17 ` Anup Patel
2020-03-02 4:21 ` Sean Anderson
2020-03-02 4:48 ` Damien Le Moal
2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:02 ` Sean Anderson
2020-03-02 5:11 ` Damien Le Moal
2020-03-02 5:25 ` Sean Anderson
2020-03-02 5:43 ` Damien Le Moal
2020-03-04 19:44 ` Palmer Dabbelt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.