Similar to ARM64, add support for building DTB files from DT source
data for RISC-V boards.
This patch starts with the infrastructure needed for SiFive boards.
Boards from other vendors would add support here in a similar form.
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
---
arch/riscv/Kconfig | 2 ++
arch/riscv/Kconfig.platforms | 8 ++++++++
arch/riscv/boot/dts/Makefile | 2 ++
3 files changed, 12 insertions(+)
create mode 100644 arch/riscv/Kconfig.platforms
create mode 100644 arch/riscv/boot/dts/Makefile
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index eb56c82d8aa1..10e818816017 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -127,6 +127,8 @@ config ARCH_RV64I
endchoice
+source "arch/riscv/Kconfig.platforms"
+
# We must be able to map all physical memory into the kernel, but the compiler
# is still a bit more efficient when generating code if it's setup in a manner
# such that it can only map 2GiB of memory.
diff --git a/arch/riscv/Kconfig.platforms b/arch/riscv/Kconfig.platforms
new file mode 100644
index 000000000000..bd3d2642bcff
--- /dev/null
+++ b/arch/riscv/Kconfig.platforms
@@ -0,0 +1,8 @@
+menu "Platform selection"
+
+config ARCH_SIFIVE
+ bool "SiFive platforms"
+ help
+ This enables direct support for SiFive SoC platform hardware.
+
+endmenu
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
new file mode 100644
index 000000000000..dcc3ada78455
--- /dev/null
+++ b/arch/riscv/boot/dts/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+subdir-y += sifive
--
2.20.1
Add YAML DT binding documentation for the SiFive FU540 SoC. This
SoC is documented at:
https://static.dev.sifive.com/FU540-C000-v1.0.pdf
Passes dt-doc-validate, as of yaml-bindings commit 4c79d42e9216.
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
.../devicetree/bindings/riscv/sifive.yaml | 26 +++++++++++++++++++
MAINTAINERS | 9 +++++++
2 files changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/sifive.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive.yaml b/Documentation/devicetree/bindings/riscv/sifive.yaml
new file mode 100644
index 000000000000..d2808d8d79bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive/sifive.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive SoC-based boards
+
+maintainers:
+ - Paul Walmsley <[email protected]>
+ - Palmer Dabbelt <[email protected]>
+
+description:
+ SiFive SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ items:
+ - enum:
+ - sifive,freedom-unleashed-a00-fu540
+ - sifive,freedom-unleashed-a00
+ - const: sifive,fu540-c000
+ - const: sifive,fu540
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 3ec37f17f90e..c02bf352a8c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14138,6 +14138,15 @@ S: Supported
K: sifive
N: sifive
+SIFIVE FU540 SYSTEM-ON-CHIP
+M: Paul Walmsley <[email protected]>
+M: Palmer Dabbelt <[email protected]>
+L: [email protected]
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pjw/sifive.git
+S: Supported
+K: fu540
+N: fu540
+
SILEAD TOUCHSCREEN DRIVER
M: Hans de Goede <[email protected]>
L: [email protected]
--
2.20.1
At Rob's request, we're starting to migrate our DT binding
documentation to json-schema YAML format. Start by converting our cpu
binding documentation. While doing so, document more properties and
nodes. This includes adding binding documentation support for the E51
and U54 CPU cores ("harts") that are present on this SoC. These cores
are described in:
https://static.dev.sifive.com/FU540-C000-v1.0.pdf
This cpus.yaml file is intended to be a starting point and to
evolve over time. It passes dt-doc-validate as of the yaml-bindings
commit 4c79d42e9216.
This patch was originally based on the ARM json-schema binding
documentation as added by commit 672951cbd1b7 ("dt-bindings: arm: Convert
cpu binding to json-schema").
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
.../devicetree/bindings/riscv/cpus.yaml | 274 ++++++++++++++++++
1 file changed, 274 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/cpus.yaml
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
new file mode 100644
index 000000000000..11ade807fd49
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -0,0 +1,274 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/cpus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V bindings for 'cpus' DT nodes
+
+maintainers:
+ - Paul Walmsley <[email protected]>
+ - Palmer Dabbelt <[email protected]>
+
+description: |+
+ In SoC device tree data files, the layout of CPUs is described in
+ the "cpus" node. This node in turn contains a number of subnodes
+ representing CPUs, which define properties for every cpu.
+
+ Bindings for CPU nodes follow the Devicetree Specification, available from:
+
+ https://www.devicetree.org/specifications/
+
+ with updates for RISC-V cores provided in this document.
+
+ ================================
+ Convention used in this document
+ ================================
+
+ This document follows the conventions described in the Devicetree
+ Specification, with the addition:
+
+ - square brackets define bitfields, e.g. reg[7:0] represents the
+ value of the bitfield in the reg property contained in bits 7 down
+ to 0
+
+ =====================================
+ cpus and cpu node bindings definition
+ =====================================
+
+ If a Devicetree file is used to provide hardware data to the kernel,
+ the RISC-V architecture requires the cpus and cpu nodes to be
+ present and contain the properties described below.
+
+properties:
+ $nodename:
+ const: cpus
+ description: Container of cpu nodes
+
+ '#address-cells':
+ const: 1
+ description: |
+ A single unsigned 32-bit integer uniquely identifies
+ each RISC-V hart in a system. (See the "reg" node under
+ the "cpu" node, below).
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^cpu@[0-9a-f]+$':
+ properties:
+ device_type:
+ const: cpu
+
+ reg:
+ maxItems: 1
+ description: |
+ Set the "reg" property to the hart ID of this CPU node.
+ Each value in this property must be unique in the scope
+ of the Devicetree file that contains it.
+
+ compatible:
+ items:
+ - const: riscv
+ - enum:
+ - sifive,rocket0
+ - sifive,e5
+ - sifive,e51
+ - sifive,u54-mc
+ - sifive,u54
+ - sifive,u5
+ description: |
+ Identifies that the hart uses the RISC-V instruction set
+ and identifies the type of the hart.
+
+ mmu-type:
+ items:
+ - enum:
+ - riscv,sv32
+ - riscv,sv39
+ - riscv,sv48
+ description: |
+ Identifies the MMU address translation mode used on this
+ hart. These values originate from the RISC-V Privileged
+ Specification document, available from
+ https://riscv.org/specifications/
+
+ riscv,isa:
+ items:
+ - enum:
+ - rv64imac
+ - rv64imafdc
+ description: |
+ Identifies the specific RISC-V instruction set architecture
+ supported by the hart. These are documented in the RISC-V
+ User-Level ISA document, available from
+ https://riscv.org/specifications/
+
+ The RISC-V Linux port only will execute on a subset of these
+ values. However, other hart cores may be present in the
+ Devicetree hardware description file that do not run Linux.
+
+ timebase-frequency:
+ maxItems: 1
+ description: |
+ Specifies the clock frequency of the system timer in Hz.
+ This value is common to all harts in this Linux system image.
+
+ i-cache-block-size:
+ maxItems: 1
+ description: |
+ Specifies the size, in bytes, of an instruction cache line.
+
+ i-cache-sets:
+ maxItems: 1
+ description: |
+ Specifies the number of sets in the hart's instruction cache.
+
+ i-cache-size:
+ maxItems: 1
+ description: |
+ Specifies the size, in bytes, of the hart's instruction cache.
+
+ i-tlb-sets:
+ maxItems: 1
+ description: |
+ Specifies the number of sets in the hart's instruction TLB.
+ If present, the "tlb-split" property must be set.
+
+ i-tlb-size:
+ maxItems: 1
+ description: |
+ Specifies the number of entries in the hart's instruction TLB.
+ If present, the "tlb-split" property must be set.
+
+ d-cache-block-size:
+ maxItems: 1
+ description: |
+ Specifies the size, in bytes, of a data cache line.
+
+ d-cache-sets:
+ maxItems: 1
+ description: |
+ Specifies the number of sets in the hart's data cache.
+
+ d-cache-size:
+ maxItems: 1
+ description: |
+ Specifies the size, in bytes, of the hart's data cache.
+
+ d-tlb-sets:
+ maxItems: 1
+ description: |
+ Specifies the number of sets in the hart's data TLB.
+ If present, the "tlb-split" property must be set.
+
+ d-tlb-size:
+ maxItems: 1
+ description: |
+ Specifies the number of entries in the hart's data TLB.
+ If present, the "tlb-split" property must be set.
+
+ tlb-split: true
+
+ patternProperties:
+ '^interrupt-controller@[0-9a-f]+$':
+ properties:
+ $nodename:
+ const: interrupt-controller
+ description: Describes the CPU's local interrupt controller
+
+ '#interrupt-cells':
+ const: 1
+
+ compatible:
+ const: riscv,cpu-intc
+
+ interrupt-controller: true
+
+ required:
+ - '#interrupt-cells'
+ - compatible
+ - interrupt-controller
+
+ required:
+ - device_type
+ - reg
+ - compatible
+ - riscv,isa
+ - timebase-frequency
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+
+examples:
+ - |
+ // Example 1: SiFive Freedom U540G Development Kit
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <1000000>;
+ cpu@0 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <16384>;
+ reg = <0>;
+ riscv,isa = "rv64imac";
+ sifive,dtim = <&L8>;
+ sifive,itim = <&L7>;
+ status = "okay";
+ L10: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu@1 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <1>;
+ riscv,isa = "rv64imafdc";
+ status = "okay";
+ tlb-split;
+ L13: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ };
+
+ - |
+ // Example 2: Spike ISA Simulator with 1 Hart
+ cpus {
+ cpu@0 {
+ device_type = "cpu";
+ reg = <0>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv64imafdc";
+ mmu-type = "riscv,sv48";
+ interrupt-controller {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ };
+ };
+ };
+...
--
2.20.1
Add initial support for the SiFive FU540-C000 SoC. This is a 28nm SoC
based around the SiFive U54-MC core complex and a TileLink
interconnect.
This file is expected to grow as more device drivers are added to the
kernel.
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 207 +++++++++++++++++++++
1 file changed, 207 insertions(+)
create mode 100644 arch/riscv/boot/dts/sifive/fu540-c000.dtsi
diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
new file mode 100644
index 000000000000..dd3b9395cedf
--- /dev/null
+++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: (Apache-2.0 OR GPL-2.0+)
+/* Copyright (c) 2018-2019 SiFive, Inc */
+
+/dts-v1/;
+
+#include <dt-bindings/clock/sifive-fu540-prci.h>
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "sifive,fu540-c000", "sifive,fu540";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ chosen {
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <1000000>;
+ cpu0: cpu@0 {
+ compatible = "sifive,e51", "sifive,rocket0", "riscv";
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <16384>;
+ reg = <0>;
+ riscv,isa = "rv64imac";
+ status = "okay";
+ cpu0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu1: cpu@1 {
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <1>;
+ riscv,isa = "rv64imafdc";
+ status = "okay";
+ tlb-split;
+ cpu1_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu2: cpu@2 {
+ clock-frequency = <0>;
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <2>;
+ riscv,isa = "rv64imafdc";
+ status = "okay";
+ tlb-split;
+ cpu2_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu3: cpu@3 {
+ clock-frequency = <0>;
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <3>;
+ riscv,isa = "rv64imafdc";
+ status = "okay";
+ tlb-split;
+ cpu3_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu4: cpu@4 {
+ clock-frequency = <0>;
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <4>;
+ riscv,isa = "rv64imafdc";
+ status = "okay";
+ tlb-split;
+ cpu4_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ };
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "sifive,fu540-c000", "sifive,fu540", "simple-bus";
+ ranges;
+ plic0: interrupt-controller@c000000 {
+ #interrupt-cells = <1>;
+ compatible = "sifive,plic-1.0.0";
+ reg = <0x0 0xc000000 0x0 0x4000000>;
+ interrupt-controller;
+ interrupts-extended = <
+ &cpu0_intc 11
+ &cpu1_intc 11 &cpu1_intc 9
+ &cpu2_intc 11 &cpu2_intc 9
+ &cpu3_intc 11 &cpu3_intc 9
+ &cpu4_intc 11 &cpu4_intc 9>;
+ };
+ prci: clock-controller@10000000 {
+ compatible = "sifive,fu540-c000-prci";
+ reg = <0x0 0x10000000 0x0 0x1000>;
+ clocks = <&hfclk>, <&rtcclk>;
+ #clock-cells = <1>;
+ };
+ uart0: serial@10010000 {
+ compatible = "sifive,fu540-c000-uart", "sifive,uart0";
+ reg = <0x0 0x10010000 0x0 0x1000>;
+ interrupt-parent = <&plic0>;
+ interrupts = <4>;
+ clocks = <&prci PRCI_CLK_TLCLK>;
+ };
+ uart1: serial@10011000 {
+ compatible = "sifive,fu540-c000-uart", "sifive,uart0";
+ reg = <0x0 0x10011000 0x0 0x1000>;
+ interrupt-parent = <&plic0>;
+ interrupts = <5>;
+ clocks = <&prci PRCI_CLK_TLCLK>;
+ };
+ qspi0: spi@10040000 {
+ compatible = "sifive,fu540-c000-spi", "sifive,spi0";
+ reg = <0x0 0x10040000 0x0 0x1000
+ 0x0 0x20000000 0x0 0x10000000>;
+ interrupt-parent = <&plic0>;
+ interrupts = <51>;
+ clocks = <&prci PRCI_CLK_TLCLK>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ qspi2: spi@10050000 {
+ compatible = "sifive,fu540-c000-spi", "sifive,spi0";
+ reg = <0x0 0x10050000 0x0 0x1000>;
+ interrupt-parent = <&plic0>;
+ interrupts = <6>;
+ clocks = <&prci PRCI_CLK_TLCLK>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ qspi1: spi@10140000 {
+ compatible = "sifive,fu540-c000-spi", "sifive,spi0";
+ reg = <0x0 0x10140000 0x0 0x1000
+ 0x0 0x30000000 0x0 0x10000000>;
+ interrupt-parent = <&plic0>;
+ interrupts = <52>;
+ clocks = <&prci PRCI_CLK_TLCLK>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
--
2.20.1
Add initial board data for the SiFive HiFive Unleashed A00.
Currently the data populated in this DT file describes the board
DRAM configuration and the external clock sources that supply the
PRCI.
This second version adds onboard SPI device data, fixes the board's
memory size, and adds changes based on comments from Rob Herring
<[email protected]>.
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
arch/riscv/boot/dts/sifive/Makefile | 2 +
.../dts/sifive/hifive-unleashed-a00-fu540.dts | 69 +++++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 arch/riscv/boot/dts/sifive/Makefile
create mode 100644 arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts
diff --git a/arch/riscv/boot/dts/sifive/Makefile b/arch/riscv/boot/dts/sifive/Makefile
new file mode 100644
index 000000000000..fb825db888df
--- /dev/null
+++ b/arch/riscv/boot/dts/sifive/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_SIFIVE) += hifive-unleashed-a00-fu540.dtb
diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts
new file mode 100644
index 000000000000..9d35e811a3aa
--- /dev/null
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: (Apache-2.0 OR GPL-2.0+)
+/* Copyright (c) 2018-2019 SiFive, Inc */
+
+/dts-v1/;
+
+#include "fu540-c000.dtsi"
+
+/* Clock frequency (in Hz) of the PCB crystal for rtcclk */
+#define RTCCLK_FREQ 1000000
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "SiFive HiFive Unleashed A00 (FU540-C000)";
+ compatible = "sifive,hifive-unleashed-a00-fu540",
+ "sifive,hifive-unleashed-fu540",
+ "sifive,fu540-c000", "sifive-fu540";
+
+ chosen {
+ };
+
+ cpus {
+ timebase-frequency = <RTCCLK_FREQ>;
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x2 0x00000000>;
+ };
+
+ soc {
+ };
+
+ hfclk: hfclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <33333333>;
+ clock-output-names = "hfclk";
+ };
+
+ rtcclk: rtcclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <RTCCLK_FREQ>;
+ clock-output-names = "rtcclk";
+ };
+};
+
+&qspi0 {
+ flash@0 {
+ compatible = "issi,is25wp256d", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ m25p,fast-read;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
+&qspi2 {
+ status = "okay";
+ mmc@0 {
+ compatible = "mmc-spi-slot";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ voltage-ranges = <3300 3300>;
+ disable-wp;
+ };
+};
--
2.20.1
Enable CONFIG_ARCH_SIFIVE in the RISC-V defconfig so
DTB files for SiFive boards are generated by default.
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/riscv/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 2fd3461e50ab..0fb782c8cc1e 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -12,6 +12,7 @@ CONFIG_CHECKPOINT_RESTORE=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_BPF_SYSCALL=y
+CONFIG_ARCH_SIFIVE=y
CONFIG_SMP=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
--
2.20.1
On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote:
> Similar to ARM64, add support for building DTB files from DT source
> data for RISC-V boards.
>
> This patch starts with the infrastructure needed for SiFive boards.
> Boards from other vendors would add support here in a similar form.
What do we build it for? We'd really need something like this:
http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e
http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1
To actually use the DT files.
On Thu, Apr 11, 2019 at 3:43 AM Paul Walmsley <[email protected]> wrote:
>
> At Rob's request, we're starting to migrate our DT binding
> documentation to json-schema YAML format. Start by converting our cpu
> binding documentation. While doing so, document more properties and
> nodes. This includes adding binding documentation support for the E51
> and U54 CPU cores ("harts") that are present on this SoC. These cores
> are described in:
>
> https://static.dev.sifive.com/FU540-C000-v1.0.pdf
>
> This cpus.yaml file is intended to be a starting point and to
> evolve over time. It passes dt-doc-validate as of the yaml-bindings
> commit 4c79d42e9216.
>
> This patch was originally based on the ARM json-schema binding
> documentation as added by commit 672951cbd1b7 ("dt-bindings: arm: Convert
> cpu binding to json-schema").
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> .../devicetree/bindings/riscv/cpus.yaml | 274 ++++++++++++++++++
> 1 file changed, 274 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/riscv/cpus.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> new file mode 100644
> index 000000000000..11ade807fd49
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -0,0 +1,274 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/cpus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V bindings for 'cpus' DT nodes
> +
> +maintainers:
> + - Paul Walmsley <[email protected]>
> + - Palmer Dabbelt <[email protected]>
> +
> +description: |+
> + In SoC device tree data files, the layout of CPUs is described in
> + the "cpus" node. This node in turn contains a number of subnodes
> + representing CPUs, which define properties for every cpu.
> +
> + Bindings for CPU nodes follow the Devicetree Specification, available from:
> +
> + https://www.devicetree.org/specifications/
> +
> + with updates for RISC-V cores provided in this document.
> +
> + ================================
> + Convention used in this document
> + ================================
> +
> + This document follows the conventions described in the Devicetree
> + Specification, with the addition:
> +
> + - square brackets define bitfields, e.g. reg[7:0] represents the
> + value of the bitfield in the reg property contained in bits 7 down
> + to 0
> +
> + =====================================
> + cpus and cpu node bindings definition
> + =====================================
> +
> + If a Devicetree file is used to provide hardware data to the kernel,
> + the RISC-V architecture requires the cpus and cpu nodes to be
> + present and contain the properties described below.
> +
> +properties:
> + $nodename:
> + const: cpus
> + description: Container of cpu nodes
> +
> + '#address-cells':
> + const: 1
> + description: |
> + A single unsigned 32-bit integer uniquely identifies
> + each RISC-V hart in a system. (See the "reg" node under
> + the "cpu" node, below).
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + '^cpu@[0-9a-f]+$':
> + properties:
> + device_type:
> + const: cpu
> +
> + reg:
> + maxItems: 1
> + description: |
> + Set the "reg" property to the hart ID of this CPU node.
> + Each value in this property must be unique in the scope
> + of the Devicetree file that contains it.
> +
> + compatible:
> + items:
> + - const: riscv
Wrong order here. This should be last.
> + - enum:
> + - sifive,rocket0
> + - sifive,e5
> + - sifive,e51
> + - sifive,u54-mc
> + - sifive,u54
> + - sifive,u5
> + description: |
> + Identifies that the hart uses the RISC-V instruction set
> + and identifies the type of the hart.
> +
> + mmu-type:
> + items:
> + - enum:
If a single value, then you can drop 'items'.
> + - riscv,sv32
> + - riscv,sv39
> + - riscv,sv48
> + description: |
> + Identifies the MMU address translation mode used on this
> + hart. These values originate from the RISC-V Privileged
> + Specification document, available from
> + https://riscv.org/specifications/
> +
> + riscv,isa:
This needs to have a $ref to a type schema. (Under an 'allOf' list
with this enum)
> + items:
> + - enum:
Also don't need items here if a single value.
> + - rv64imac
> + - rv64imafdc
> + description: |
> + Identifies the specific RISC-V instruction set architecture
> + supported by the hart. These are documented in the RISC-V
> + User-Level ISA document, available from
> + https://riscv.org/specifications/
> +
> + The RISC-V Linux port only will execute on a subset of these
What Linux does isn't relevant to the binding.
> + values. However, other hart cores may be present in the
> + Devicetree hardware description file that do not run Linux.
> +
> + timebase-frequency:
> + maxItems: 1
Not an array.
> + description: |
> + Specifies the clock frequency of the system timer in Hz.
> + This value is common to all harts in this Linux system image.
> +
> + i-cache-block-size:
> + maxItems: 1
Not an array. Surely you can define either the set of possible values
or min/max values. Same comment on the rest of the cache props.
Are the cache attributes really not discoverable?
> + description: |
> + Specifies the size, in bytes, of an instruction cache line.
> +
> + i-cache-sets:
> + maxItems: 1
> + description: |
> + Specifies the number of sets in the hart's instruction cache.
> +
> + i-cache-size:
> + maxItems: 1
> + description: |
> + Specifies the size, in bytes, of the hart's instruction cache.
> +
> + i-tlb-sets:
> + maxItems: 1
> + description: |
> + Specifies the number of sets in the hart's instruction TLB.
> + If present, the "tlb-split" property must be set.
'dependencies' can express this for you. We do need a core schema for
all these to define the type and maybe dependencies can be there.
> +
> + i-tlb-size:
> + maxItems: 1
> + description: |
> + Specifies the number of entries in the hart's instruction TLB.
> + If present, the "tlb-split" property must be set.
> +
> + d-cache-block-size:
> + maxItems: 1
> + description: |
> + Specifies the size, in bytes, of a data cache line.
> +
> + d-cache-sets:
> + maxItems: 1
> + description: |
> + Specifies the number of sets in the hart's data cache.
> +
> + d-cache-size:
> + maxItems: 1
> + description: |
> + Specifies the size, in bytes, of the hart's data cache.
> +
> + d-tlb-sets:
> + maxItems: 1
> + description: |
> + Specifies the number of sets in the hart's data TLB.
> + If present, the "tlb-split" property must be set.
> +
> + d-tlb-size:
> + maxItems: 1
> + description: |
> + Specifies the number of entries in the hart's data TLB.
> + If present, the "tlb-split" property must be set.
> +
> + tlb-split: true
> +
> + patternProperties:
> + '^interrupt-controller@[0-9a-f]+$':
No 'reg', so should not have a unit-address.
> + properties:
> + $nodename:
You don't need this as we just defined it above.
> + const: interrupt-controller
> + description: Describes the CPU's local interrupt controller
> +
> + '#interrupt-cells':
> + const: 1
> +
> + compatible:
> + const: riscv,cpu-intc
> +
> + interrupt-controller: true
> +
> + required:
> + - '#interrupt-cells'
> + - compatible
> + - interrupt-controller
> +
> + required:
> + - device_type
> + - reg
> + - compatible
> + - riscv,isa
> + - timebase-frequency
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> +
> +examples:
> + - |
> + // Example 1: SiFive Freedom U540G Development Kit
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <1000000>;
> + cpu@0 {
> + clock-frequency = <0>;
> + compatible = "sifive,rocket0", "riscv";
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <128>;
> + i-cache-size = <16384>;
> + reg = <0>;
> + riscv,isa = "rv64imac";
> + sifive,dtim = <&L8>;
> + sifive,itim = <&L7>;
Not documented.
> + status = "okay";
Don't show status in examples.
> + L10: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu@1 {
> + clock-frequency = <0>;
> + compatible = "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <1>;
> + riscv,isa = "rv64imafdc";
> + status = "okay";
> + tlb-split;
> + L13: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + };
> +
> + - |
> + // Example 2: Spike ISA Simulator with 1 Hart
> + cpus {
> + cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + status = "okay";
> + compatible = "riscv";
> + riscv,isa = "rv64imafdc";
> + mmu-type = "riscv,sv48";
> + interrupt-controller {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "riscv,cpu-intc";
> + };
> + };
> + };
> +...
> --
> 2.20.1
>
On Thu, Apr 11, 2019 at 3:43 AM Paul Walmsley <[email protected]> wrote:
>
> Add initial board data for the SiFive HiFive Unleashed A00.
>
> Currently the data populated in this DT file describes the board
> DRAM configuration and the external clock sources that supply the
> PRCI.
>
> This second version adds onboard SPI device data, fixes the board's
> memory size, and adds changes based on comments from Rob Herring
> <[email protected]>.
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Albert Ou <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> arch/riscv/boot/dts/sifive/Makefile | 2 +
> .../dts/sifive/hifive-unleashed-a00-fu540.dts | 69 +++++++++++++++++++
> 2 files changed, 71 insertions(+)
> create mode 100644 arch/riscv/boot/dts/sifive/Makefile
> create mode 100644 arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts
>
> diff --git a/arch/riscv/boot/dts/sifive/Makefile b/arch/riscv/boot/dts/sifive/Makefile
> new file mode 100644
> index 000000000000..fb825db888df
> --- /dev/null
> +++ b/arch/riscv/boot/dts/sifive/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_SIFIVE) += hifive-unleashed-a00-fu540.dtb
> diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts
> new file mode 100644
> index 000000000000..9d35e811a3aa
> --- /dev/null
> +++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dts
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: (Apache-2.0 OR GPL-2.0+)
> +/* Copyright (c) 2018-2019 SiFive, Inc */
> +
> +/dts-v1/;
> +
> +#include "fu540-c000.dtsi"
> +
> +/* Clock frequency (in Hz) of the PCB crystal for rtcclk */
> +#define RTCCLK_FREQ 1000000
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "SiFive HiFive Unleashed A00 (FU540-C000)";
> + compatible = "sifive,hifive-unleashed-a00-fu540",
> + "sifive,hifive-unleashed-fu540",
> + "sifive,fu540-c000", "sifive-fu540";
This doesn't match your schema which has 3 entries. Really, 4 entries
is kind of pointless typically. Usually, just a board and SoC
compatible are enough.
> +
> + chosen {
> + };
> +
> + cpus {
> + timebase-frequency = <RTCCLK_FREQ>;
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x0 0x80000000 0x2 0x00000000>;
> + };
> +
> + soc {
> + };
> +
> + hfclk: hfclk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <33333333>;
> + clock-output-names = "hfclk";
> + };
> +
> + rtcclk: rtcclk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <RTCCLK_FREQ>;
> + clock-output-names = "rtcclk";
> + };
> +};
> +
> +&qspi0 {
> + flash@0 {
> + compatible = "issi,is25wp256d", "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <50000000>;
> + m25p,fast-read;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +};
> +
> +&qspi2 {
> + status = "okay";
> + mmc@0 {
> + compatible = "mmc-spi-slot";
> + reg = <0>;
> + spi-max-frequency = <20000000>;
> + voltage-ranges = <3300 3300>;
> + disable-wp;
> + };
> +};
> --
> 2.20.1
>
On Thu, Apr 11, 2019 at 3:43 AM Paul Walmsley <[email protected]> wrote:
>
> Add initial support for the SiFive FU540-C000 SoC. This is a 28nm SoC
> based around the SiFive U54-MC core complex and a TileLink
> interconnect.
>
> This file is expected to grow as more device drivers are added to the
> kernel.
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Albert Ou <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 207 +++++++++++++++++++++
> 1 file changed, 207 insertions(+)
> create mode 100644 arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>
> diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
> new file mode 100644
> index 000000000000..dd3b9395cedf
> --- /dev/null
> +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: (Apache-2.0 OR GPL-2.0+)
You're okay with GPLv9 license?
You're free to license however you want, but most dts files use MIT
for permissive license.
> +/* Copyright (c) 2018-2019 SiFive, Inc */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/clock/sifive-fu540-prci.h>
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "sifive,fu540-c000", "sifive,fu540";
No point in this as the board file overrides.
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + chosen {
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <1000000>;
> + cpu0: cpu@0 {
> + compatible = "sifive,e51", "sifive,rocket0", "riscv";
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <128>;
> + i-cache-size = <16384>;
> + reg = <0>;
> + riscv,isa = "rv64imac";
> + status = "okay";
okay is the default.
It is strange cpu@0 is missing many of the cache properties...
> + cpu0_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu1: cpu@1 {
> + compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <1>;
> + riscv,isa = "rv64imafdc";
> + status = "okay";
> + tlb-split;
> + cpu1_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu2: cpu@2 {
> + clock-frequency = <0>;
> + compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <2>;
> + riscv,isa = "rv64imafdc";
> + status = "okay";
> + tlb-split;
> + cpu2_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu3: cpu@3 {
> + clock-frequency = <0>;
> + compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <3>;
> + riscv,isa = "rv64imafdc";
> + status = "okay";
> + tlb-split;
> + cpu3_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu4: cpu@4 {
> + clock-frequency = <0>;
> + compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <4>;
> + riscv,isa = "rv64imafdc";
> + status = "okay";
> + tlb-split;
> + cpu4_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + };
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
Really need 64-bits of address and size for peripherals?
> + compatible = "sifive,fu540-c000", "sifive,fu540", "simple-bus";
Just simple-bus here. You can't reuse compatible strings.
> + ranges;
> + plic0: interrupt-controller@c000000 {
> + #interrupt-cells = <1>;
> + compatible = "sifive,plic-1.0.0";
> + reg = <0x0 0xc000000 0x0 0x4000000>;
> + interrupt-controller;
> + interrupts-extended = <
> + &cpu0_intc 11
> + &cpu1_intc 11 &cpu1_intc 9
> + &cpu2_intc 11 &cpu2_intc 9
> + &cpu3_intc 11 &cpu3_intc 9
> + &cpu4_intc 11 &cpu4_intc 9>;
> + };
> + prci: clock-controller@10000000 {
> + compatible = "sifive,fu540-c000-prci";
> + reg = <0x0 0x10000000 0x0 0x1000>;
> + clocks = <&hfclk>, <&rtcclk>;
> + #clock-cells = <1>;
> + };
> + uart0: serial@10010000 {
> + compatible = "sifive,fu540-c000-uart", "sifive,uart0";
> + reg = <0x0 0x10010000 0x0 0x1000>;
> + interrupt-parent = <&plic0>;
Move all these up to the parent.
> + interrupts = <4>;
> + clocks = <&prci PRCI_CLK_TLCLK>;
> + };
> + uart1: serial@10011000 {
> + compatible = "sifive,fu540-c000-uart", "sifive,uart0";
> + reg = <0x0 0x10011000 0x0 0x1000>;
> + interrupt-parent = <&plic0>;
> + interrupts = <5>;
> + clocks = <&prci PRCI_CLK_TLCLK>;
> + };
> + qspi0: spi@10040000 {
> + compatible = "sifive,fu540-c000-spi", "sifive,spi0";
> + reg = <0x0 0x10040000 0x0 0x1000
> + 0x0 0x20000000 0x0 0x10000000>;
> + interrupt-parent = <&plic0>;
> + interrupts = <51>;
> + clocks = <&prci PRCI_CLK_TLCLK>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + qspi2: spi@10050000 {
> + compatible = "sifive,fu540-c000-spi", "sifive,spi0";
> + reg = <0x0 0x10050000 0x0 0x1000>;
> + interrupt-parent = <&plic0>;
> + interrupts = <6>;
> + clocks = <&prci PRCI_CLK_TLCLK>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + qspi1: spi@10140000 {
> + compatible = "sifive,fu540-c000-spi", "sifive,spi0";
> + reg = <0x0 0x10140000 0x0 0x1000
> + 0x0 0x30000000 0x0 0x10000000>;
> + interrupt-parent = <&plic0>;
> + interrupts = <52>;
> + clocks = <&prci PRCI_CLK_TLCLK>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +};
> --
> 2.20.1
>
On Thu, 11 Apr 2019, Christoph Hellwig wrote:
> On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote:
> > Similar to ARM64, add support for building DTB files from DT source
> > data for RISC-V boards.
> >
> > This patch starts with the infrastructure needed for SiFive boards.
> > Boards from other vendors would add support here in a similar form.
>
> What do we build it for? We'd really need something like this:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e
> http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1
>
> To actually use the DT files.
Those patches might be useful - I have not reviewed them closely - but
they are not necessary.
The FSBL already supplies a DTB to Linux. I assume the U-boot port works
the same way.
I haven't switched to U-boot yet for these driver tests, so I personally
have been using the open-source FSBL (freedom-u540-c000-bootloader) with
the following trivial patches applied:
https://github.com/sifive/freedom-u540-c000-bootloader/tree/dev/paulw/supply-fsbl-dtb-v5.1-rc4
The fsbl/ux00_fsbl.dtb file can be symlinked to the kernel DTB output,
e.g., ~/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dtb.
- Paul
On 4/11/19 4:46 AM, Christoph Hellwig wrote:
> On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote:
>> Similar to ARM64, add support for building DTB files from DT source
>> data for RISC-V boards.
>>
>> This patch starts with the infrastructure needed for SiFive boards.
>> Boards from other vendors would add support here in a similar form.
>
> What do we build it for? We'd really need something like this:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e
> http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1
>
> To actually use the DT files.
>
We also need to modify the DT, as the default DTS file in this patch
series has hart0 status as "okay",
Or we should set hart0 status as "masked" in the .dts file now.
Regards,
Atish
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
On 4/11/19 2:12 PM, Paul Walmsley wrote:
> On Thu, 11 Apr 2019, Christoph Hellwig wrote:
>
>> On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote:
>>> Similar to ARM64, add support for building DTB files from DT source
>>> data for RISC-V boards.
>>>
>>> This patch starts with the infrastructure needed for SiFive boards.
>>> Boards from other vendors would add support here in a similar form.
>>
>> What do we build it for? We'd really need something like this:
>>
>> http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e
>> http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1
>>
>> To actually use the DT files.
>
> Those patches might be useful - I have not reviewed them closely - but
> they are not necessary.
>
> The FSBL already supplies a DTB to Linux. I assume the U-boot port works
> the same way.
>
I am bit confused here. I thought the idea behind putting the the DTS in
kernel so that Kernel don't need to depend on DT passed from boot
loaders. Currently, DTB passed from FSBL is modified by OpenSBI/BBL
before passing to U-Boot or Linux.
If Linux kernel can boot from the DTS contained within its source code
as is, that would be much more helpful.
> I haven't switched to U-boot yet for these driver tests, so I personally
> have been using the open-source FSBL (freedom-u540-c000-bootloader) with
> the following trivial patches applied:
>
> https://github.com/sifive/freedom-u540-c000-bootloader/tree/dev/paulw/supply-fsbl-dtb-v5.1-rc4
>
> The fsbl/ux00_fsbl.dtb file can be symlinked to the kernel DTB output,
> e.g., ~/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dtb.
>
>
This assumes that FSBL has to be rebuilt every time I want to change the
DT. I was hoping to avoid that.
Regards,
Atish
> - Paul
>
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
On Thu, 11 Apr 2019, Atish Patra wrote:
> On 4/11/19 2:12 PM, Paul Walmsley wrote:
> > On Thu, 11 Apr 2019, Christoph Hellwig wrote:
> >
> > > On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote:
> > > > Similar to ARM64, add support for building DTB files from DT source
> > > > data for RISC-V boards.
> > > >
> > > > This patch starts with the infrastructure needed for SiFive boards.
> > > > Boards from other vendors would add support here in a similar form.
> > >
> > > What do we build it for? We'd really need something like this:
> > >
> > > http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e
> > > http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1
> > >
> > > To actually use the DT files.
> >
> > Those patches might be useful - I have not reviewed them closely - but
> > they are not necessary.
> >
> > The FSBL already supplies a DTB to Linux. I assume the U-boot port works
> > the same way.
> >
>
> I am bit confused here. I thought the idea behind putting the the DTS in
> kernel so that Kernel don't need to depend on DT passed from boot loaders.
Some users will want to do that - mostly embedded device integrators and
kernel developers. We should definitely support these use-cases. So the
basic idea behind Christoph's patch to do that is good (I have not yet
reviewed the code nor tested it).
In fact, there has been an unofficial patch to do something similar for
ARM for about a decade now. But for various reasons, some technical, some
managerial - it was never merged. To be clear, I do agree that we should
merge something like that for RISC-V.
However: the vast majority of users -- even embedded users -- will not use
a kernel with a bundled DTB. This is because it irrevocably ties that
kernel binary to one specific board type. I hope it is obvious why this
would be a non-starter for Linux distributions, and, more generally,
anyone who wants their kernels to be usable on multiple boards. Those
distributors would need to ship one kernel binary per board, or bloat
their kernels with DTBs and come up with some new mechanism to select one.
> Currently, DTB passed from FSBL is modified by OpenSBI/BBL before passing to
> U-Boot or Linux.
This should be avoided whenever possible. I'd be interested in hearing
what OpenSBI is doing now to the DTB; perhaps there is a case where it
makes sense. But in general, doing this makes development and maintenance
quite difficult. Considre that different operating systems that may use
the same SBI layer may use different DT data formats, or may not even use
DT at all. And when the DT data format changes - as is happening now - a
maintenance hassle is created, since then versions across multiple pieces
of software may need to be synchronized. It is also very disconcerting as
a kernel developer to have multiple pieces of software modifying one's
DTB.
The DT data is meant to represent hardware fact. DT is also used to pass
in some non-hardware-related runtime configuration parameters, via the
"chosen" node. But that's about it. So from that point of view, only the
first-stage bootloader should be altering the DT data, and only then in
very minimal ways.
> If Linux kernel can boot from the DTS contained within its source code as is,
> that would be much more helpful.
If you are thinking about embedded system builders, and developers who
only care about their test kernel being compatible with one board, I agree
with you for those specific use-cases. Almost everyone else will pass in
a separate DTB, specific to the board they are using, from U-Boot or
Coreboot or GRUB.
> > I haven't switched to U-boot yet for these driver tests, so I
> > personally have been using the open-source FSBL
> > (freedom-u540-c000-bootloader) with the following trivial patches
> > applied:
> >
> > https://github.com/sifive/freedom-u540-c000-bootloader/tree/dev/paulw/supply-fsbl-dtb-v5.1-rc4
>
> > The fsbl/ux00_fsbl.dtb file can be symlinked to the kernel DTB output,
> > e.g., ~/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dtb.
>
> This assumes that FSBL has to be rebuilt every time I want to change the DT. I
> was hoping to avoid that.
The FSBL is on its way out. It is just a short-term workaround until the
various popular bootloader ports become more stable. After that happens,
it's likely that almost no one to use the current SiFive FSBLs. We plan
to transition our Freedom-U development environment away from it
ourselves.
The point of what I wrote to Christoph earlier is simply that everyone is
already using DTB data that is passed in from an early bootloader, whether
they realize it or not. So there is an existence proof that no additional
patches are needed for the basics to function. It may not be functioning
well in some cases, and may need patching; but that is a separate matter.
- Paul
On Thu, Apr 11, 2019 at 05:08:11PM -0700, Paul Walmsley wrote:
> However: the vast majority of users -- even embedded users -- will not use
> a kernel with a bundled DTB. This is because it irrevocably ties that
> kernel binary to one specific board type. I hope it is obvious why this
> would be a non-starter for Linux distributions, and, more generally,
> anyone who wants their kernels to be usable on multiple boards. Those
> distributors would need to ship one kernel binary per board, or bloat
> their kernels with DTBs and come up with some new mechanism to select one.
Yes, that is the point why the DTB usually comes with the firmware.
In my case I need it because by nommu M-mode Linux port targeted to
the Kendrye _is_ the firmware and there is nothing else running on that
tiny system.
But why are you submitting the DTB files if there is not ways use them
from the kernel? That is what I was wondering about.
On 4/11/19 5:08 PM, Paul Walmsley wrote:
> On Thu, 11 Apr 2019, Atish Patra wrote:
>
>> On 4/11/19 2:12 PM, Paul Walmsley wrote:
>>> On Thu, 11 Apr 2019, Christoph Hellwig wrote:
>>>
>>>> On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote:
>>>>> Similar to ARM64, add support for building DTB files from DT source
>>>>> data for RISC-V boards.
>>>>>
>>>>> This patch starts with the infrastructure needed for SiFive boards.
>>>>> Boards from other vendors would add support here in a similar form.
>>>>
>>>> What do we build it for? We'd really need something like this:
>>>>
>>>> http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e
>>>> http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1
>>>>
>>>> To actually use the DT files.
>>>
>>> Those patches might be useful - I have not reviewed them closely - but
>>> they are not necessary.
>>>
>>> The FSBL already supplies a DTB to Linux. I assume the U-boot port works
>>> the same way.
>>>
>>
>> I am bit confused here. I thought the idea behind putting the the DTS in
>> kernel so that Kernel don't need to depend on DT passed from boot loaders.
>
> Some users will want to do that - mostly embedded device integrators and
> kernel developers. We should definitely support these use-cases. So the
> basic idea behind Christoph's patch to do that is good (I have not yet
> reviewed the code nor tested it).
>
> In fact, there has been an unofficial patch to do something similar for
> ARM for about a decade now. But for various reasons, some technical, some
> managerial - it was never merged. To be clear, I do agree that we should
> merge something like that for RISC-V.
>
> However: the vast majority of users -- even embedded users -- will not use
> a kernel with a bundled DTB. This is because it irrevocably ties that
> kernel binary to one specific board type. I hope it is obvious why this
> would be a non-starter for Linux distributions, and, more generally,
> anyone who wants their kernels to be usable on multiple boards. Those
> distributors would need to ship one kernel binary per board, or bloat
> their kernels with DTBs and come up with some new mechanism to select one.
>
I agree with you completely. I was just suggesting to have the option to
use the DTS in kernel similar Christoph's patch. It should not to be the
default.
>> Currently, DTB passed from FSBL is modified by OpenSBI/BBL before passing to
>> U-Boot or Linux.
>
> This should be avoided whenever possible. I'd be interested in hearing
> what OpenSBI is doing now to the DTB; perhaps there is a case where it
> makes sense.
The current DT modifications by OpenSBI.
1. Change hart status to "masked" from "okay".
2. M-mode interrupt masking in PLIC node.
3. Add a chosen node for serial access in U-Boot.
But in general, doing this makes development and maintenance
> quite difficult. Considre that different operating systems that may use
> the same SBI layer may use different DT data formats, or may not even use
> DT at all. And when the DT data format changes - as is happening now - a
> maintenance hassle is created, since then versions across multiple pieces
> of software may need to be synchronized. It is also very disconcerting as
> a kernel developer to have multiple pieces of software modifying one's
> DTB.
>
Again, we are on the same page. We prefer not have any DT modification
in OpenSBI as well. Currently, that's not an option. But we would
happily get rid of existing one if a reliable alternate solution is
available.
> The DT data is meant to represent hardware fact. DT is also used to pass
> in some non-hardware-related runtime configuration parameters, via the
> "chosen" node. But that's about it. So from that point of view, only the
> first-stage bootloader should be altering the DT data, and only then in
> very minimal ways.
>
>> If Linux kernel can boot from the DTS contained within its source code as is,
>> that would be much more helpful.
>
> If you are thinking about embedded system builders, and developers who
> only care about their test kernel being compatible with one board, I agree
> with you for those specific use-cases. Almost everyone else will pass in
> a separate DTB, specific to the board they are using, from U-Boot or
> Coreboot or GRUB.
>
>>> I haven't switched to U-boot yet for these driver tests, so I
>>> personally have been using the open-source FSBL
>>> (freedom-u540-c000-bootloader) with the following trivial patches
>>> applied:
>>>
>>> https://github.com/sifive/freedom-u540-c000-bootloader/tree/dev/paulw/supply-fsbl-dtb-v5.1-rc4
>>
>>> The fsbl/ux00_fsbl.dtb file can be symlinked to the kernel DTB output,
>>> e.g., ~/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dtb.
>>
>> This assumes that FSBL has to be rebuilt every time I want to change the DT. I
>> was hoping to avoid that.
>
> The FSBL is on its way out. It is just a short-term workaround until the
> various popular bootloader ports become more stable. After that happens,
> it's likely that almost no one to use the current SiFive FSBLs. We plan
> to transition our Freedom-U development environment away from it
> ourselves.
>
Glad to know that.
> The point of what I wrote to Christoph earlier is simply that everyone is
> already using DTB data that is passed in from an early bootloader, whether
> they realize it or not. So there is an existence proof that no additional
> patches are needed for the basics to function. It may not be functioning
> well in some cases, and may need patching; but that is a separate matter.
>
Ah okay.
Regards,
Atish
>
> - Paul
>
On Thu, Apr 11, 2019 at 01:43:00AM -0700, Paul Walmsley wrote:
> Add YAML DT binding documentation for the SiFive FU540 SoC. This
> SoC is documented at:
>
> https://static.dev.sifive.com/FU540-C000-v1.0.pdf
>
> Passes dt-doc-validate, as of yaml-bindings commit 4c79d42e9216.
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Albert Ou <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> .../devicetree/bindings/riscv/sifive.yaml | 26 +++++++++++++++++++
> MAINTAINERS | 9 +++++++
> 2 files changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/riscv/sifive.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/sifive.yaml b/Documentation/devicetree/bindings/riscv/sifive.yaml
> new file mode 100644
> index 000000000000..d2808d8d79bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/sifive.yaml
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/sifive/sifive.yaml#
The path here should match the file path. IOW, drop 'sifive/'.
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SiFive SoC-based boards
> +
> +maintainers:
> + - Paul Walmsley <[email protected]>
> + - Palmer Dabbelt <[email protected]>
> +
> +description:
> + SiFive SoC-based boards
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + items:
> + - enum:
> + - sifive,freedom-unleashed-a00-fu540
> + - sifive,freedom-unleashed-a00
> + - const: sifive,fu540-c000
> + - const: sifive,fu540
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3ec37f17f90e..c02bf352a8c6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14138,6 +14138,15 @@ S: Supported
> K: sifive
> N: sifive
>
> +SIFIVE FU540 SYSTEM-ON-CHIP
> +M: Paul Walmsley <[email protected]>
> +M: Palmer Dabbelt <[email protected]>
> +L: [email protected]
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/pjw/sifive.git
> +S: Supported
> +K: fu540
> +N: fu540
> +
> SILEAD TOUCHSCREEN DRIVER
> M: Hans de Goede <[email protected]>
> L: [email protected]
> --
> 2.20.1
>
On Mon, 29 Apr 2019, Rob Herring wrote:
> On Thu, Apr 11, 2019 at 01:43:00AM -0700, Paul Walmsley wrote:
> > Add YAML DT binding documentation for the SiFive FU540 SoC. This
> > SoC is documented at:
> >
> > https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> >
> > Passes dt-doc-validate, as of yaml-bindings commit 4c79d42e9216.
...
> > ---
> > .../devicetree/bindings/riscv/sifive.yaml | 26 +++++++++++++++++++
> > MAINTAINERS | 9 +++++++
> > 2 files changed, 35 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/riscv/sifive.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/sifive.yaml b/Documentation/devicetree/bindings/riscv/sifive.yaml
> > new file mode 100644
> > index 000000000000..d2808d8d79bb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/sifive.yaml
> > @@ -0,0 +1,26 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/sifive/sifive.yaml#
>
> The path here should match the file path. IOW, drop 'sifive/'.
Thanks, will do.
- Paul
On Thu 11 Apr 2019 at 01:42, Paul Walmsley <[email protected]> wrote:
> Similar to ARM64, add support for building DTB files from DT source
> data for RISC-V boards.
>
> This patch starts with the infrastructure needed for SiFive boards.
> Boards from other vendors would add support here in a similar form.
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Albert Ou <[email protected]>
Tested-by: Loys Ollivier <[email protected]>
Tested the whole patch series using FSBL+BBL.
Did basic boot testing and uart validation.
The actual testing process is quite cumbersome.
One needs to rebuild the BBL to update the dtb loaded.
Would you have an idea of the delta between bbl and u-boot ?
I tried booting the same kernel + dtb with U-Boot but ran into
errors related to plic.
Loys