mirror of
https://github.com/tbsdtv/linux_media.git
synced 2025-07-23 04:33:26 +02:00
intro ===== When the RISC-V dt-bindings were accepted upstream in Linux, the base ISA etc had yet to be ratified. By the ratification of the base ISA, incompatible changes had snuck into the specifications - for example the Zicsr and Zifencei extensions were spun out of the base ISA. Fast forward to today, and the reason for this patch. Currently the riscv,isa dt property permits only a specific subset of the ISA string - in particular it excludes version numbering. With the current constraints, it is not possible to discern whether "rv64i" means that the hart supports the fence.i instruction, for example. Future systems may choose to implement their own instruction fencing, perhaps using a vendor extension, or they may not implement the optional counter extensions. Software needs a way to determine this. versioning schemes ================== "Use the extension versions that are described in the ISA manual" you may say, and it's not like this has not been considered. Firstly, software that parses the riscv,isa property at runtime will need to contain a lookup table of some sort that maps arbitrary versions to versions it understands. There is not a consistent application of version number applied to extensions, with a higgledy-piggledy collection of tags, "bare" and versioned documents awaiting the reader on the "recently ratified extensions" page: https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions As an aside, and this is reflected in the patch too, since many extensions have yet to appear in a release of the ISA specs, they are defined by commits in their respective "working draft" repositories. Secondly, there is an issue of backwards compatibility, whereby allowing numbers in the ISA string, some parsers may be broken. This would require an additional property to be created to even use the versions in this manner. ~boolean properties~ string array property ========================================== If a new property is needed, the whole approach may as well be looked at from the bottom up. A string with limited character choices etc is hardly the best approach for communicating extension information to software. Switching to using properties that are defined on a per extension basis, allows us to define explicit meanings for the DT representation of each extension - rather than the current situation where different operating systems or other bits of software may impart different meanings to characters in the string. Clearly the best source of meanings is the specifications themselves, this just provides us the ability to choose at what point in time the meaning is set. If an extension changes incompatibility in the future, a new property will be required. Off-list, some of the RVI folks have committed to shoring up the wording in either the ISA specifications, the riscv-isa-manual or so that in the future, modifications to and additions or removals of features will require a new extension. Codifying that assertion somewhere would make it quite unlikely that compatibility would be broken, but we have the tools required to deal with it, if & when it crops up. It is in our collective interest, as consumers of extension meanings, to define a scheme that enforces compatibility. The use of individual elements, rather than a single string, will also permit validation that the properties have a meaning, as well as potentially reject mutually exclusive combinations, or enforce dependencies between extensions. That would not have be possible with the current dt-schema infrastructure for arbitrary strings, as we would need to add a riscv,isa parser to dt-validate! That's not implemented in this patch, but rather left as future work (for the brave, or the foolish). parser simplicity ================= Many systems that parse DT at runtime already implement an function that can check for the presence of a string in an array of string, as it is similar to the process for parsing a list of compatible strings, so a bunch of new, custom, DT parsing should not be needed. Getting rid of "riscv,isa" parsing would be a nice simplification, but unfortunately for backwards compatibility with old dtbs, existing parsers may not be removable - which may greatly simplify dt parsing code. In Linux, for example, checking for whether a hart supports an extension becomes as simple as: of_property_match_string(node, "riscv,isa-extensions", "zicbom") vendor extensions ================= Compared to riscv,isa, this proposed scheme promotes vendor extensions, oft touted as the strength of RISC-V, to first-class citizens. At present, extensions are defined as meaning what the RISC-V ISA specifications say they do. There is no realistic way of using that interface to provide cross-platform definitions for what vendor extensions mean. Vendor extensions may also have even less consistency than RVI do in terms of versioning, or no care about backwards compatibility. The new property allows us to assign explicit meanings on a per vendor extension basis, backed up by a description of their meanings. fin === Create a new file to store the extension meanings and a new riscv,isa-base property to replace the aspect of riscv,isa that is not represented by the new property - the base ISA implemented by a hart. As a starting point, add properties for extensions currently used in Linux. Finally, mark riscv,isa as deprecated, as removing support for it in existing programs would be an ABI break. CC: Palmer Dabbelt <palmer@dabbelt.com> CC: Paul Walmsley <paul.walmsley@sifive.com> CC: Rob Herring <robh+dt@kernel.org> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> CC: Alistair Francis <alistair.francis@wdc.com> CC: Andrew Jones <ajones@ventanamicro.com> CC: Anup Patel <apatel@ventanamicro.com> CC: Atish Patra <atishp@atishpatra.org> CC: Jessica Clarke <jrtc27@jrtc27.com> CC: Rick Chen <rick@andestech.com> CC: Leo <ycliang@andestech.com> CC: Oleksii <oleksii.kurochko@gmail.com> CC: linux-riscv@lists.infradead.org CC: qemu-riscv@nongnu.org CC: u-boot@lists.denx.de CC: devicetree@vger.kernel.org CC: linux-kernel@vger.kernel.org Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230702-eats-scorebook-c951f170d29f@spud Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
212 lines
6.0 KiB
YAML
212 lines
6.0 KiB
YAML
# SPDX-License-Identifier: (GPL-2.0 OR MIT)
|
|
%YAML 1.2
|
|
---
|
|
$id: http://devicetree.org/schemas/riscv/cpus.yaml#
|
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
|
|
|
title: RISC-V CPUs
|
|
|
|
maintainers:
|
|
- Paul Walmsley <paul.walmsley@sifive.com>
|
|
- Palmer Dabbelt <palmer@sifive.com>
|
|
- Conor Dooley <conor@kernel.org>
|
|
|
|
description: |
|
|
This document uses some terminology common to the RISC-V community
|
|
that is not widely used, the definitions of which are listed here:
|
|
|
|
hart: A hardware execution context, which contains all the state
|
|
mandated by the RISC-V ISA: a PC and some registers. This
|
|
terminology is designed to disambiguate software's view of execution
|
|
contexts from any particular microarchitectural implementation
|
|
strategy. For example, an Intel laptop containing one socket with
|
|
two cores, each of which has two hyperthreads, could be described as
|
|
having four harts.
|
|
|
|
allOf:
|
|
- $ref: /schemas/cpu.yaml#
|
|
- $ref: extensions.yaml
|
|
|
|
properties:
|
|
compatible:
|
|
oneOf:
|
|
- items:
|
|
- enum:
|
|
- andestech,ax45mp
|
|
- canaan,k210
|
|
- sifive,bullet0
|
|
- sifive,e5
|
|
- sifive,e7
|
|
- sifive,e71
|
|
- sifive,rocket0
|
|
- sifive,s7
|
|
- sifive,u5
|
|
- sifive,u54
|
|
- sifive,u7
|
|
- sifive,u74
|
|
- sifive,u74-mc
|
|
- thead,c906
|
|
- thead,c910
|
|
- const: riscv
|
|
- items:
|
|
- enum:
|
|
- sifive,e51
|
|
- sifive,u54-mc
|
|
- const: sifive,rocket0
|
|
- const: riscv
|
|
- const: riscv # Simulator only
|
|
description:
|
|
Identifies that the hart uses the RISC-V instruction set
|
|
and identifies the type of the hart.
|
|
|
|
mmu-type:
|
|
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/
|
|
$ref: /schemas/types.yaml#/definitions/string
|
|
enum:
|
|
- riscv,sv32
|
|
- riscv,sv39
|
|
- riscv,sv48
|
|
- riscv,sv57
|
|
- riscv,none
|
|
|
|
riscv,cbom-block-size:
|
|
$ref: /schemas/types.yaml#/definitions/uint32
|
|
description:
|
|
The blocksize in bytes for the Zicbom cache operations.
|
|
|
|
riscv,cboz-block-size:
|
|
$ref: /schemas/types.yaml#/definitions/uint32
|
|
description:
|
|
The blocksize in bytes for the Zicboz cache operations.
|
|
|
|
# RISC-V has multiple properties for cache op block sizes as the sizes
|
|
# differ between individual CBO extensions
|
|
cache-op-block-size: false
|
|
# RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
|
|
timebase-frequency: false
|
|
|
|
interrupt-controller:
|
|
type: object
|
|
description: Describes the CPU's local interrupt controller
|
|
|
|
properties:
|
|
'#interrupt-cells':
|
|
const: 1
|
|
|
|
compatible:
|
|
const: riscv,cpu-intc
|
|
|
|
interrupt-controller: true
|
|
|
|
required:
|
|
- '#interrupt-cells'
|
|
- compatible
|
|
- interrupt-controller
|
|
|
|
cpu-idle-states:
|
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
|
items:
|
|
maxItems: 1
|
|
description: |
|
|
List of phandles to idle state nodes supported
|
|
by this hart (see ./idle-states.yaml).
|
|
|
|
capacity-dmips-mhz:
|
|
description:
|
|
u32 value representing CPU capacity (see ../cpu/cpu-capacity.txt) in
|
|
DMIPS/MHz, relative to highest capacity-dmips-mhz
|
|
in the system.
|
|
|
|
anyOf:
|
|
- required:
|
|
- riscv,isa
|
|
- required:
|
|
- riscv,isa-base
|
|
|
|
dependencies:
|
|
riscv,isa-base: [ "riscv,isa-extensions" ]
|
|
riscv,isa-extensions: [ "riscv,isa-base" ]
|
|
|
|
required:
|
|
- interrupt-controller
|
|
|
|
unevaluatedProperties: false
|
|
|
|
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-base = "rv64i";
|
|
riscv,isa-extensions = "i", "m", "a", "c";
|
|
|
|
cpu_intc0: 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>;
|
|
tlb-split;
|
|
riscv,isa-base = "rv64i";
|
|
riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
|
|
|
|
cpu_intc1: interrupt-controller {
|
|
#interrupt-cells = <1>;
|
|
compatible = "riscv,cpu-intc";
|
|
interrupt-controller;
|
|
};
|
|
};
|
|
};
|
|
|
|
- |
|
|
// Example 2: Spike ISA Simulator with 1 Hart
|
|
cpus {
|
|
#address-cells = <1>;
|
|
#size-cells = <0>;
|
|
cpu@0 {
|
|
device_type = "cpu";
|
|
reg = <0>;
|
|
compatible = "riscv";
|
|
mmu-type = "riscv,sv48";
|
|
riscv,isa-base = "rv64i";
|
|
riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
|
|
|
|
interrupt-controller {
|
|
#interrupt-cells = <1>;
|
|
interrupt-controller;
|
|
compatible = "riscv,cpu-intc";
|
|
};
|
|
};
|
|
};
|
|
...
|