dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
# SPDX-License-Identifier: (GPL-2.0 OR MIT)
|
|
|
|
|
%YAML 1.2
|
|
|
|
|
---
|
|
|
|
|
$id: http://devicetree.org/schemas/riscv/extensions.yaml#
|
|
|
|
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
|
|
|
|
|
|
|
|
|
title: RISC-V ISA extensions
|
|
|
|
|
|
|
|
|
|
maintainers:
|
|
|
|
|
- Paul Walmsley <paul.walmsley@sifive.com>
|
|
|
|
|
- Palmer Dabbelt <palmer@sifive.com>
|
|
|
|
|
- Conor Dooley <conor@kernel.org>
|
|
|
|
|
|
|
|
|
|
description: |
|
|
|
|
|
RISC-V has a large number of extensions, some of which are "standard"
|
|
|
|
|
extensions, meaning they are ratified by RISC-V International, and others
|
|
|
|
|
are "vendor" extensions.
|
|
|
|
|
This document defines properties that indicate whether a hart supports a
|
|
|
|
|
given extension.
|
|
|
|
|
|
|
|
|
|
Once a standard extension has been ratified, no changes in behaviour can be
|
|
|
|
|
made without the creation of a new extension.
|
|
|
|
|
The properties for standard extensions therefore map to their originally
|
|
|
|
|
ratified states, with the exception of the I, Zicntr & Zihpm extensions.
|
|
|
|
|
See the "i" property for more information.
|
|
|
|
|
|
|
|
|
|
select:
|
|
|
|
|
properties:
|
|
|
|
|
compatible:
|
|
|
|
|
contains:
|
|
|
|
|
const: riscv
|
|
|
|
|
|
|
|
|
|
properties:
|
|
|
|
|
riscv,isa:
|
|
|
|
|
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/
|
|
|
|
|
|
|
|
|
|
Due to revisions of the ISA specification, some deviations
|
|
|
|
|
have arisen over time.
|
|
|
|
|
Notably, riscv,isa was defined prior to the creation of the
|
|
|
|
|
Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i"
|
|
|
|
|
implies "zicntr_zicsr_zifencei_zihpm".
|
|
|
|
|
|
|
|
|
|
While the isa strings in ISA specification are case
|
|
|
|
|
insensitive, letters in the riscv,isa string must be all
|
|
|
|
|
lowercase.
|
|
|
|
|
$ref: /schemas/types.yaml#/definitions/string
|
2023-12-08 16:06:51 +00:00
|
|
|
pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[0-9a-z])+)?(?:_[hsxz](?:[0-9a-z])+)*$
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
deprecated: true
|
|
|
|
|
|
|
|
|
|
riscv,isa-base:
|
|
|
|
|
description:
|
|
|
|
|
The base ISA implemented by this hart, as described by the 20191213
|
|
|
|
|
version of the unprivileged ISA specification.
|
|
|
|
|
enum:
|
|
|
|
|
- rv32i
|
|
|
|
|
- rv64i
|
|
|
|
|
|
|
|
|
|
riscv,isa-extensions:
|
|
|
|
|
$ref: /schemas/types.yaml#/definitions/string-array
|
|
|
|
|
minItems: 1
|
|
|
|
|
description: Extensions supported by the hart.
|
|
|
|
|
items:
|
|
|
|
|
anyOf:
|
|
|
|
|
# single letter extensions, in canonical order
|
|
|
|
|
- const: i
|
|
|
|
|
description: |
|
|
|
|
|
The base integer instruction set, as ratified in the 20191213
|
|
|
|
|
version of the unprivileged ISA specification.
|
|
|
|
|
|
|
|
|
|
This does not include Chapter 10, "Counters", which was moved into
|
|
|
|
|
the Zicntr and Zihpm extensions after the ratification of the
|
|
|
|
|
20191213 version of the unprivileged specification.
|
|
|
|
|
|
|
|
|
|
- const: m
|
|
|
|
|
description:
|
|
|
|
|
The standard M extension for integer multiplication and division, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: a
|
|
|
|
|
description:
|
|
|
|
|
The standard A extension for atomic instructions, as ratified in the
|
|
|
|
|
20191213 version of the unprivileged ISA specification.
|
|
|
|
|
|
|
|
|
|
- const: f
|
|
|
|
|
description:
|
|
|
|
|
The standard F extension for single-precision floating point, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: d
|
|
|
|
|
description:
|
|
|
|
|
The standard D extension for double-precision floating-point, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: q
|
|
|
|
|
description:
|
|
|
|
|
The standard Q extension for quad-precision floating-point, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: c
|
|
|
|
|
description:
|
|
|
|
|
The standard C extension for compressed instructions, as ratified in
|
|
|
|
|
the 20191213 version of the unprivileged ISA specification.
|
|
|
|
|
|
|
|
|
|
- const: v
|
|
|
|
|
description:
|
|
|
|
|
The standard V extension for vector operations, as ratified
|
|
|
|
|
in-and-around commit 7a6c8ae ("Fix text that describes vfmv.v.f
|
|
|
|
|
encoding") of the riscv-v-spec.
|
|
|
|
|
|
|
|
|
|
- const: h
|
|
|
|
|
description:
|
|
|
|
|
The standard H extension for hypervisors as ratified in the 20191213
|
|
|
|
|
version of the privileged ISA specification.
|
|
|
|
|
|
|
|
|
|
# multi-letter extensions, sorted alphanumerically
|
|
|
|
|
- const: smaia
|
|
|
|
|
description: |
|
|
|
|
|
The standard Smaia supervisor-level extension for the advanced
|
|
|
|
|
interrupt architecture for machine-mode-visible csr and behavioural
|
|
|
|
|
changes to interrupts as frozen at commit ccbddab ("Merge pull
|
|
|
|
|
request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
|
|
|
|
|
|
2023-09-13 16:39:00 +00:00
|
|
|
- const: smstateen
|
|
|
|
|
description: |
|
|
|
|
|
The standard Smstateen extension for controlling access to CSRs
|
|
|
|
|
added by other RISC-V extensions in H/S/VS/U/VU modes and as
|
|
|
|
|
ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
- const: ssaia
|
|
|
|
|
description: |
|
|
|
|
|
The standard Ssaia supervisor-level extension for the advanced
|
|
|
|
|
interrupt architecture for supervisor-mode-visible csr and
|
|
|
|
|
behavioural changes to interrupts as frozen at commit ccbddab
|
|
|
|
|
("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
|
|
|
|
|
|
|
|
|
|
- const: sscofpmf
|
|
|
|
|
description: |
|
|
|
|
|
The standard Sscofpmf supervisor-level extension for count overflow
|
|
|
|
|
and mode-based filtering as ratified at commit 01d1df0 ("Add ability
|
|
|
|
|
to manually trigger workflow. (#2)") of riscv-count-overflow.
|
|
|
|
|
|
|
|
|
|
- const: sstc
|
|
|
|
|
description: |
|
|
|
|
|
The standard Sstc supervisor-level extension for time compare as
|
|
|
|
|
ratified at commit 3f9ed34 ("Add ability to manually trigger
|
|
|
|
|
workflow. (#2)") of riscv-time-compare.
|
|
|
|
|
|
|
|
|
|
- const: svinval
|
|
|
|
|
description:
|
|
|
|
|
The standard Svinval supervisor-level extension for fine-grained
|
|
|
|
|
address-translation cache invalidation as ratified in the 20191213
|
|
|
|
|
version of the privileged ISA specification.
|
|
|
|
|
|
|
|
|
|
- const: svnapot
|
|
|
|
|
description:
|
|
|
|
|
The standard Svnapot supervisor-level extensions for napot
|
|
|
|
|
translation contiguity as ratified in the 20191213 version of the
|
|
|
|
|
privileged ISA specification.
|
|
|
|
|
|
|
|
|
|
- const: svpbmt
|
|
|
|
|
description:
|
|
|
|
|
The standard Svpbmt supervisor-level extensions for page-based
|
|
|
|
|
memory types as ratified in the 20191213 version of the privileged
|
|
|
|
|
ISA specification.
|
|
|
|
|
|
2023-12-20 15:57:19 +00:00
|
|
|
- const: zacas
|
|
|
|
|
description: |
|
|
|
|
|
The Zacas extension for Atomic Compare-and-Swap (CAS) instructions
|
|
|
|
|
is supported as ratified at commit 5059e0ca641c ("update to
|
|
|
|
|
ratified") of the riscv-zacas.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
- const: zba
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zba bit-manipulation extension for address generation
|
|
|
|
|
acceleration instructions as ratified at commit 6d33919 ("Merge pull
|
|
|
|
|
request #158 from hirooih/clmul-fix-loop-end-condition") of
|
|
|
|
|
riscv-bitmanip.
|
|
|
|
|
|
|
|
|
|
- const: zbb
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zbb bit-manipulation extension for basic bit-manipulation
|
|
|
|
|
as ratified at commit 6d33919 ("Merge pull request #158 from
|
|
|
|
|
hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
|
|
|
|
|
|
|
|
|
|
- const: zbc
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zbc bit-manipulation extension for carry-less
|
|
|
|
|
multiplication as ratified at commit 6d33919 ("Merge pull request
|
|
|
|
|
#158 from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
|
|
|
|
|
|
2023-11-14 14:12:41 +00:00
|
|
|
- const: zbkb
|
|
|
|
|
description:
|
|
|
|
|
The standard Zbkb bitmanip instructions for cryptography as ratified
|
|
|
|
|
in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zbkc
|
|
|
|
|
description:
|
|
|
|
|
The standard Zbkc carry-less multiply instructions as ratified
|
|
|
|
|
in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zbkx
|
|
|
|
|
description:
|
|
|
|
|
The standard Zbkx crossbar permutation instructions as ratified
|
|
|
|
|
in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
- const: zbs
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zbs bit-manipulation extension for single-bit
|
|
|
|
|
instructions as ratified at commit 6d33919 ("Merge pull request #158
|
|
|
|
|
from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
|
|
|
|
|
|
2023-11-14 14:12:56 +00:00
|
|
|
- const: zfa
|
|
|
|
|
description:
|
|
|
|
|
The standard Zfa extension for additional floating point
|
|
|
|
|
instructions, as ratified in commit 056b6ff ("Zfa is ratified") of
|
|
|
|
|
riscv-isa-manual.
|
|
|
|
|
|
2023-11-14 14:12:47 +00:00
|
|
|
- const: zfh
|
|
|
|
|
description:
|
|
|
|
|
The standard Zfh extension for 16-bit half-precision binary
|
|
|
|
|
floating-point instructions, as ratified in commit 64074bc ("Update
|
|
|
|
|
version numbers for Zfh/Zfinx") of riscv-isa-manual.
|
|
|
|
|
|
|
|
|
|
- const: zfhmin
|
|
|
|
|
description:
|
|
|
|
|
The standard Zfhmin extension which provides minimal support for
|
|
|
|
|
16-bit half-precision binary floating-point instructions, as ratified
|
|
|
|
|
in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
|
|
|
|
|
riscv-isa-manual.
|
|
|
|
|
|
2023-11-14 14:12:41 +00:00
|
|
|
- const: zk
|
|
|
|
|
description:
|
|
|
|
|
The standard Zk Standard Scalar cryptography extension as ratified
|
|
|
|
|
in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zkn
|
|
|
|
|
description:
|
|
|
|
|
The standard Zkn NIST algorithm suite extensions as ratified in
|
|
|
|
|
version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zknd
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zknd for NIST suite: AES decryption instructions as
|
|
|
|
|
ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zkne
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zkne for NIST suite: AES encryption instructions as
|
|
|
|
|
ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zknh
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zknh for NIST suite: hash function instructions as
|
|
|
|
|
ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zkr
|
|
|
|
|
description:
|
|
|
|
|
The standard Zkr entropy source extension as ratified in version
|
|
|
|
|
1.0 of RISC-V Cryptography Extensions Volume I specification.
|
|
|
|
|
This string being present means that the CSR associated to this
|
|
|
|
|
extension is accessible at the privilege level to which that
|
|
|
|
|
device-tree has been provided.
|
|
|
|
|
|
|
|
|
|
- const: zks
|
|
|
|
|
description:
|
|
|
|
|
The standard Zks ShangMi algorithm suite extensions as ratified in
|
|
|
|
|
version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zksed
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zksed for ShangMi suite: SM4 block cipher instructions
|
|
|
|
|
as ratified in version 1.0 of RISC-V Cryptography Extensions
|
|
|
|
|
Volume I specification.
|
|
|
|
|
|
|
|
|
|
- const: zksh
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zksh for ShangMi suite: SM3 hash function instructions
|
|
|
|
|
as ratified in version 1.0 of RISC-V Cryptography Extensions
|
|
|
|
|
Volume I specification.
|
|
|
|
|
|
|
|
|
|
- const: zkt
|
|
|
|
|
description:
|
|
|
|
|
The standard Zkt for data independent execution latency as ratified
|
|
|
|
|
in version 1.0 of RISC-V Cryptography Extensions Volume I
|
|
|
|
|
specification.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
- const: zicbom
|
|
|
|
|
description:
|
|
|
|
|
The standard Zicbom extension for base cache management operations as
|
|
|
|
|
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
|
|
|
|
|
|
|
|
|
|
- const: zicbop
|
|
|
|
|
description:
|
|
|
|
|
The standard Zicbop extension for cache-block prefetch instructions
|
|
|
|
|
as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
|
|
|
|
|
riscv-CMOs.
|
|
|
|
|
|
|
|
|
|
- const: zicboz
|
|
|
|
|
description:
|
|
|
|
|
The standard Zicboz extension for cache-block zeroing as ratified
|
|
|
|
|
in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
|
|
|
|
|
|
|
|
|
|
- const: zicntr
|
|
|
|
|
description:
|
|
|
|
|
The standard Zicntr extension for base counters and timers, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
2023-09-25 09:16:25 +00:00
|
|
|
- const: zicond
|
|
|
|
|
description:
|
|
|
|
|
The standard Zicond extension for conditional arithmetic and
|
|
|
|
|
conditional-select/move operations as ratified in commit 95cf1f9
|
|
|
|
|
("Add changes requested by Ved during signoff") of riscv-zicond.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
- const: zicsr
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zicsr extension for control and status register
|
|
|
|
|
instructions, as ratified in the 20191213 version of the
|
|
|
|
|
unprivileged ISA specification.
|
|
|
|
|
|
|
|
|
|
This does not include Chapter 10, "Counters", which documents
|
|
|
|
|
special case read-only CSRs, that were moved into the Zicntr and
|
|
|
|
|
Zihpm extensions after the ratification of the 20191213 version of
|
|
|
|
|
the unprivileged specification.
|
|
|
|
|
|
|
|
|
|
- const: zifencei
|
|
|
|
|
description:
|
|
|
|
|
The standard Zifencei extension for instruction-fetch fence, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: zihintpause
|
|
|
|
|
description:
|
|
|
|
|
The standard Zihintpause extension for pause hints, as ratified in
|
|
|
|
|
commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
|
|
|
|
|
|
2023-11-14 14:12:50 +00:00
|
|
|
- const: zihintntl
|
|
|
|
|
description:
|
|
|
|
|
The standard Zihintntl extension for non-temporal locality hints, as
|
|
|
|
|
ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
|
|
|
|
|
riscv-isa-manual.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
- const: zihpm
|
|
|
|
|
description:
|
|
|
|
|
The standard Zihpm extension for hardware performance counters, as
|
|
|
|
|
ratified in the 20191213 version of the unprivileged ISA
|
|
|
|
|
specification.
|
|
|
|
|
|
|
|
|
|
- const: ztso
|
|
|
|
|
description:
|
|
|
|
|
The standard Ztso extension for total store ordering, as ratified
|
|
|
|
|
in commit 2e5236 ("Ztso is now ratified.") of the
|
|
|
|
|
riscv-isa-manual.
|
|
|
|
|
|
2023-11-14 14:12:44 +00:00
|
|
|
- const: zvbb
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvbb extension for vectored basic bit-manipulation
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvbc
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvbc extension for vectored carryless multiplication
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
2023-11-14 14:12:53 +00:00
|
|
|
- const: zvfh
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvfh extension for vectored half-precision
|
|
|
|
|
floating-point instructions, as ratified in commit e2ccd05
|
|
|
|
|
("Remove draft warnings from Zvfh[min]") of riscv-v-spec.
|
|
|
|
|
|
|
|
|
|
- const: zvfhmin
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvfhmin extension for vectored minimal half-precision
|
|
|
|
|
floating-point instructions, as ratified in commit e2ccd05
|
|
|
|
|
("Remove draft warnings from Zvfh[min]") of riscv-v-spec.
|
|
|
|
|
|
2023-11-14 14:12:44 +00:00
|
|
|
- const: zvkb
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvkb extension for vector cryptography bit-manipulation
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvkg
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvkg extension for vector GCM/GMAC instructions, as
|
|
|
|
|
ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc")
|
|
|
|
|
of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvkn
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvkn extension for NIST algorithm suite instructions, as
|
|
|
|
|
ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc")
|
|
|
|
|
of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvknc
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvknc extension for NIST algorithm suite with carryless
|
|
|
|
|
multiply instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvkned
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvkned extension for Vector AES block cipher
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvkng
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvkng extension for NIST algorithm suite with GCM
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvknha
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zvknha extension for NIST suite: vector SHA-2 secure,
|
|
|
|
|
hash (SHA-256 only) instructions, as ratified in commit
|
|
|
|
|
56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvknhb
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zvknhb extension for NIST suite: vector SHA-2 secure,
|
|
|
|
|
hash (SHA-256 and SHA-512) instructions, as ratified in commit
|
|
|
|
|
56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvks
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvks extension for ShangMi algorithm suite
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvksc
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvksc extension for ShangMi algorithm suite with
|
|
|
|
|
carryless multiplication instructions, as ratified in commit 56ed795
|
|
|
|
|
("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvksed
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zvksed extension for ShangMi suite: SM4 block cipher
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvksh
|
|
|
|
|
description: |
|
|
|
|
|
The standard Zvksh extension for ShangMi suite: SM3 secure hash
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvksg
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvksg extension for ShangMi algorithm suite with GCM
|
|
|
|
|
instructions, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
|
|
|
|
- const: zvkt
|
|
|
|
|
description:
|
|
|
|
|
The standard Zvkt extension for vector data-independent execution
|
|
|
|
|
latency, as ratified in commit 56ed795 ("Update
|
|
|
|
|
riscv-crypto-spec-vector.adoc") of riscv-crypto.
|
|
|
|
|
|
dt-bindings: riscv: deprecate riscv,isa
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>
2023-07-01 23:10:01 +00:00
|
|
|
additionalProperties: true
|
|
|
|
|
...
|