Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
* [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
                   ` (10 more replies)
  0 siblings, 11 replies; 32+ 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] 32+ 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
                   ` (9 subsequent siblings)
  10 siblings, 1 reply; 32+ 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	[flat|nested] 32+ 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
  2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
                   ` (8 subsequent siblings)
  10 siblings, 1 reply; 32+ 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	[flat|nested] 32+ 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-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 32+ 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	[flat|nested] 32+ 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-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 32+ 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	[flat|nested] 32+ 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-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 32+ 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	[flat|nested] 32+ 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-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
                   ` (4 subsequent siblings)
  10 siblings, 1 reply; 32+ 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	[flat|nested] 32+ 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-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 32+ 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	[flat|nested] 32+ 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
  2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
                   ` (2 subsequent siblings)
  10 siblings, 1 reply; 32+ 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	[flat|nested] 32+ 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-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 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
  10 siblings, 0 replies; 32+ 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	[flat|nested] 32+ 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-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
  10 siblings, 0 replies; 32+ 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	[flat|nested] 32+ 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
  10 siblings, 1 reply; 32+ 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] 32+ 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
  0 siblings, 1 reply; 32+ 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] 32+ 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
  0 siblings, 0 replies; 32+ 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] 32+ 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
  0 siblings, 1 reply; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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
  0 siblings, 1 reply; 32+ 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] 32+ 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; 32+ 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] 32+ 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
  0 siblings, 1 reply; 32+ 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] 32+ 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; 32+ 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] 32+ 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
  0 siblings, 0 replies; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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
  0 siblings, 1 reply; 32+ 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] 32+ 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
  0 siblings, 0 replies; 32+ 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] 32+ 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; 32+ 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] 32+ messages in thread

end of thread, back to index

Thread overview: 32+ 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-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
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-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
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-19  8:50                   ` Wladimir J. van der Laan
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
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 ` [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

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git