Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

[Palmer Dabbelt]

On Tue, 07 Nov 2023 15:12:16 PST (-0800), Conor Dooley wrote:

+CC Palmer

On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:

On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> 
> 
> > further clarify or not

> > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > kernel, not a U-Boot thing).
> 
> TBH, this a bit fragmented across threads, and as someone that hasn't

> been following it it's a bit difficult to tell exactly what is being


Also just kind of jumping in: I don't usually follow u-boot stuff, but a 
few of us ended up talking abot this.



> asked for. Would someone be able to ask it as a direct question?

Sorry for being unclear, and thanks for asking. What I think the U-Boot
community would like to know is, what is the device-tree based way to
know if a RISC-V platform has the Zbb extensions


For this one, it's pretty straightforward IMO - if riscv,isa-extensions
contains "zbb", then you are safe to use those instructions. My
understanding is that relying on getting illegal instruction traps is
not a sufficient test for usability of standard extensions, as a vendor
extension could be using the same opcodes as a standard extension.


Not just could, but we've got systems that actually overlay 
vendor-specific behavior onto the standard encoding space.  There's a 
lot of small offenders for things like errata, but there's also stuff 
like T-Head where huge chunks of space reserved by the ISA for standard 
stuff gets reused.



so the RNG opcodes,
similar (in concept at least?) to the ARMv8.5 RNG feature.


The ordinary extensions that are instructions - like Zbkb that provides
bit manipulation instructions for cryptography you will be able to rely
on riscv,isa-extensions also. Zkr is actually a CSR acting as an entropy
source and is a bit more complicated. RISC-V Cryptography Extensions
Volume I, Chapter Four [0] is the relevant thing for use of the CSR
provided by Zkr, and it says "The seed CSR is also access controlled by
execution mode, and attempted read or write access will raise an illegal
instruction exception outside M mode unless access is explicitly granted."
My take is that either the SBI implementation needs to provide S-Mode
U-Boot with an accurate devicetree (including what extensions are valid
for use in S-mode) or if the devicetree is provided as part of the U-Boot
binary then it needs to match what is available at that privilege level
on the platform. In this case, you would also be able to rely on
riscv,isa-extensions for that detection. There is an existing dt-binding
patch

that adds Zkr, and my proposal would be to document that the presence of Zkr
explicitly in riscv,isa-extensions means that the bit in mseccfg.[s,u]seed
has been set so it can be used at the current privilege level.


FWIW, that seems generally viable to me.


If that's not acceptable, and people think that having Zkr in the
devicetree means that the hardware has the extension, regardless of
usability at the present privilege level, then IMO we need an SBI ecall
defined to request entablement of the CSR & report as to whether or not
that was possible.


I think we can start without the SBI interface, but I'm not 100% sure.  
I was worried about writes to "seed" somehow resulting in an information 
leak, but the spec says "The write value (in rs1 or uimm) must be 
ignored by implementations." so I think we're safe.



I'm not sure how any of the above lines up with the ARMv8.5 RNG feature
unfortunately.


All I know is what's in this patch set 
.  
It looks generalyl to me like the RNDR bits in 
"cpu-features-registers.rst" would coorespond to "Zkr" being set in 
"riscv,isa-extensions" -- we don't have ISA-defined feature registers, 
hence why all this ends up shimed in via DT.




Cheers,
Conor.

0 - https://github.com/riscv/riscv-crypto/releases/tag/v1.0.1-scalar

Re: [PATCH v5] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

On Sun, 02 Jul 2023 00:10:01 +0100, Conor Dooley wrote:
> 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.
> 
> [...]

Applied, thanks!

[1/1] dt-bindings: riscv: deprecate riscv,isa
  https://git.kernel.org/palmer/c/aeb71e42caae

Best regards,
-- 
Palmer Dabbelt 

Re: [PATCH v4] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

r 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 
CC: Paul Walmsley 
CC: Rob Herring 
CC: Krzysztof Kozlowski 
CC: Alistair Francis 
CC: Andrew Jones 
CC: Anup Patel 
CC: Atish Patra 
CC: Jessica Clarke 
CC: Rick Chen 
CC: Leo 
CC: Oleksii 
CC: linux-ri...@lists.infradead.org
CC: qemu-ri...@nongnu.org
CC: u-boot@lists.denx.de
CC: devicet...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Reviewed-by: Rob Herring 
Signed-off-by: Conor Dooley 
---
Changes in v4:
- Drop the ACPI section at Anup's request.
- Pick up tags from Rob.
- Reword some counter access clarification bits in I & Zicsr.

Changes in v3:
- Per Rob's suggestion, switch to an array of strings. Cuts down on the
  size, compared to booleans. It has a standard mechanism for parsing
  (you need to parse arrays of strings for compatibles). It still allows
  for having a limited set of explicitly defined properties - so the
  advantages over a free-form string still apply.
- Pick up Palmer's Ack and Review (although I expect that he will be the
  one to apply this).
---
 .../devicetree/bindings/riscv/cpus.yaml   |  43 ++-
 .../devicetree/bindings/riscv/extensions.yaml | 250 ++
 2 files changed, 270 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/riscv/extensions.yaml

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml 
b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 67bd239ead0b..74bc92591086 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -25,6 +25,7 @@ description: |

 allOf:
   - $ref: /schemas/cpu.yaml#
+  - $ref: extensions.yaml

 properties:
   compatible:
@@ -82,25 +83,6 @@ properties:
 description:
   The blocksize in bytes for the Zicboz cache operations.

-  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
-pattern: 
^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
-
   # RISC-V has multiple properties for cache op block sizes as the sizes
   # differ between individual CBO extensions
   cache-op-block-size: false
@@ -139,8 +121,17 @@ properties:
   DMIPS/MHz, relative to highest capacity-dmips-mhz
   in the system.

+oneOf:
+  - required:
+  - riscv,isa
+  - required:
+  - riscv,isa-base
+
+dependencies:
+  riscv,isa-base: [ "riscv,isa-extensions" ]
+  riscv,isa-extensions: [ "riscv,isa-base" ]
+
 required:
-  - riscv,isa
   - interrupt-controller

 unevaluatedProperties: false
@@ -160,7 +151,9 @@ examples:
 i-cache-sets = <128>;
 i-cache-size = <16384>;
 reg = <0>;
-riscv,isa = "rv64imac";
+riscv,isa-base = "rv64i";
+riscv,isa-extensions = "i", "m", "a", "c";
+
 cpu_intc0: interrupt-controller {
 #interrupt-cells = <1>;
 compatible = "riscv,cpu-intc";
@@ -183,8 +176,10 @@ examples:
 i-tlb-size = <32>;
 mmu-type = "riscv,sv39";
 reg = <1>;
-riscv,isa = "rv64imafdc";
 tlb-split;
+riscv,isa-base = "rv64i";
+riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+
 cpu_intc1: interrupt-controller {
 #interrupt-cells 

Re: [PATCH v3] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

On Wed, 28 Jun 2023 08:31:32 PDT (-0700), apa...@ventanamicro.com wrote:

On Wed, Jun 28, 2023 at 7:46 PM Palmer Dabbelt  wrote:


On Tue, 27 Jun 2023 08:49:06 PDT (-0700), Palmer Dabbelt wrote:
> On Mon, 26 Jun 2023 23:52:06 PDT (-0700), apa...@ventanamicro.com wrote:
>> On Tue, Jun 27, 2023 at 1:23 AM Palmer Dabbelt  wrote:
>>>
>>> On Mon, 26 Jun 2023 10:38:43 PDT (-0700), apa...@ventanamicro.com wrote:
>>> > On Mon, Jun 26, 2023 at 3:42 PM Conor Dooley  
wrote:
>>> >>
>>> >> 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
>

Re: [PATCH v3] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

On Tue, 27 Jun 2023 08:49:06 PDT (-0700), Palmer Dabbelt wrote:
> On Mon, 26 Jun 2023 23:52:06 PDT (-0700), apa...@ventanamicro.com wrote:
>> On Tue, Jun 27, 2023 at 1:23 AM Palmer Dabbelt  wrote:
>>>
>>> On Mon, 26 Jun 2023 10:38:43 PDT (-0700), apa...@ventanamicro.com wrote:
>>> > On Mon, Jun 26, 2023 at 3:42 PM Conor Dooley 
>>> >  wrote:
>>> >>
>>> >> 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 

Re: [PATCH v3] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

cking 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 
CC: Paul Walmsley 
CC: Rob Herring 
CC: Krzysztof Kozlowski 
CC: Alistair Francis 
CC: Andrew Jones 
CC: Anup Patel 
CC: Atish Patra 
CC: Jessica Clarke 
CC: Rick Chen 
CC: Leo 
CC: Oleksii 
CC: linux-ri...@lists.infradead.org
CC: qemu-ri...@nongnu.org
CC: u-boot@lists.denx.de
CC: devicet...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Signed-off-by: Conor Dooley 
---
Changes in v3:
- Per Rob's suggestion, switch to an array of strings. Cuts down on the
  size, compared to booleans. It has a standard mechanism for parsing
  (you need to parse arrays of strings for compatibles). It still allows
  for having a limited set of explicitly defined properties - so the
  advantages over a free-form string still apply.
- Pick up Palmer's Ack and Review (although I expect that he will be the
  one to apply this).
---
 .../devicetree/bindings/riscv/cpus.yaml   |  43 ++-
 .../devicetree/bindings/riscv/extensions.yaml | 245 ++
 2 files changed, 265 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/riscv/extensions.yaml

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml 
b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 67bd239ead0b..74bc92591086 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -25,6 +25,7 @@ description: |

 allOf:
   - $ref: /schemas/cpu.yaml#
+  - $ref: extensions.yaml

 properties:
   compatible:
@@ -82,25 +83,6 @@ properties:
 description:
   The blocksize in bytes for the Zicboz cache operations.

-  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
-pattern: 
^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
-
   # RISC-V has multiple properties for cache op block sizes as the sizes
   # differ between individual CBO extensions
   cache-op-block-size: false
@@ -139,8 +121,17 @@ properties:
   DMIPS/MHz, relative to highest capacity-dmips-mhz
   in the system.

+oneOf:
+  - required:
+  - riscv,isa
+  - required:
+  - riscv,isa-base
+
+dependencies:
+  riscv,isa-base: [ "riscv,isa-extensions" ]
+  riscv,isa-extensions: [ "riscv,isa-base" ]
+
 required:
-  - riscv,isa
   - interrupt-controller

 unevaluatedProperties: false
@@ -160,7 +151,9 @@ examples:
 i-cache-sets = <128>;
 i-cache-size = <16384>;
 reg = <0>;
-riscv,isa = "rv64imac";
+riscv,isa-base = "rv64i";
+riscv,isa-extensions = "i", "m", "a", "c";
+
 cpu_intc0: interrupt-controller {
 #interrupt-cells = <1>;
 compatible = "riscv,cpu-intc";
@@ -183,8 +176,10 @@ examples:
 i-tlb-size = <32>;
 mmu-type = "riscv,sv39";
 reg = <1>;
-riscv,isa = "rv64imaf

Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

On Thu, 22 Jun 2023 11:59:32 PDT (-0700), Conor Dooley wrote:

On Thu, Jun 22, 2023 at 11:25:35AM -0700, Palmer Dabbelt wrote:


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

I'm not wed to any particular encoding for the properties, IMO that's more
of a decision for the DT folks.  IMO the important bit is to just get away
from ISA strings and move towards some tightly-specified properties that
indicate how the HW actually behaves.


I'm going to resubmit with Rob's list of strings. I'll keep your tags,
since the spirit of the patch will be the same, with enforced meanings
for each extension.


Works for me, thanks.



Cheers,
Conor.

Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

care about backwards
compatibility.
A boolean 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, each of which are
boolean children of a riscv,isa-extensions node and a new
riscv,isa-base property to replace the aspect of riscv,isa that is
not represented by booleans - the base ISA implemented by a hart.
Originally I proposed properties in the cpu node, rather than as a child
of the cpu node, but some concerns were raised about the size of the dtb
for systems with dozens of cpus & dozens of extensions. Using a child
node, and dropping the "riscv,isa-extension-" prefix saves the guts of
20 bytes per extension, per hart, and hopefully placates the size
conscious.

As a starting point, add properties for extensions currently used in
Linux.

Finally, mark riscv,isa as deprecated, as removing it is an ABI break.

CC: Palmer Dabbelt 
CC: Paul Walmsley 
CC: Rob Herring 
CC: Krzysztof Kozlowski 
CC: Alistair Francis 
CC: Andrew Jones 
CC: Anup Patel 
CC: Atish Patra 
CC: Jessica Clarke 
CC: Rick Chen 
CC: Leo 
CC: Oleksii 
CC: linux-ri...@lists.infradead.org
CC: qemu-ri...@nongnu.org
CC: u-boot@lists.denx.de
CC: devicet...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Conor Dooley 
---
Changes in v2:
- Use Sean's suggestion of a child node to calm fears of bloat
- Fixup a rake of wording etc issues that Drew pointed out

As a result of implementing Sean's suggestion, I believe I need to add
riscv,isa-extensions as an exception to the rules preventing vendor
properties being of object type, otherwise dt_binding_check is less than
happy with me.

I've tried to CC a few folks here that would care about this, but I am
sure there are more. I'll go cross-post it to sw-dev, if it allows me to
post there...
---
 .../devicetree/bindings/riscv/cpus.yaml   |  57 ++--
 .../devicetree/bindings/riscv/extensions.yaml | 278 ++
 2 files changed, 313 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/riscv/extensions.yaml

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml 
b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 3d2934b15e80..1e4f67129f97 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -23,6 +23,9 @@ description: |
   two cores, each of which has two hyperthreads, could be described as
   having four harts.

+allOf:
+  - $ref: extensions.yaml
+
 properties:
   compatible:
 oneOf:
@@ -79,25 +82,6 @@ properties:
 description:
   The blocksize in bytes for the Zicboz cache operations.

-  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
-  Zicsr and Zifencei extensions and thus "i" implies
-  "zicsr_zifencei".
-
-  While the isa strings in ISA specification are case
-  insensitive, letters in the riscv,isa string must be all
-  lowercase to simplify parsing.
-$ref: "/schemas/types.yaml#/definitions/string"
-pattern: 
^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
-
   # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
   timebase-frequency: false

@@ -133,8 +117,17 @@ properties:
   DMIPS/MHz, relative to highest capacity-dmips-mhz
   in the system.

+oneOf:
+  - required:
+  - riscv,isa
+  - required:
+  - riscv,isa-base
+
+dependencies:
+  riscv,isa-base: [ "riscv,isa-extensions" ]
+  riscv,isa-extensions: [ "riscv,isa-base" ]
+
 required:
-  - riscv,isa
   - interrupt-controller

 additionalProperties: true
@@ -177,8 +170,18 @@ examples:
 i-tlb-size = <32>;
 mmu-type = "riscv,sv39";
 reg = <1>;
-riscv,isa = "rv64imafdc";
 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";
@@ -196,8 +199,18 @@ examples:
 device_type = "cpu";
 reg = <0>;
 compatible = "riscv";
-riscv,isa = "rv64imafdc";
 mmu-type = "r

Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa

[Palmer Dabbelt]

On Thu, 18 May 2023 07:06:17 PDT (-0700), Conor Dooley wrote:

On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote:

On Thu, May 18, 2023 at 4:02 PM Andrew Jones  wrote:
> On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote:



> > -  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
> > -  Zicsr and Zifencei extensions and thus "i" implies
> > -  "zicsr_zifencei".
> > -
> > -  While the isa strings in ISA specification are case
> > -  insensitive, letters in the riscv,isa string must be all
> > -  lowercase to simplify parsing.
> > -$ref: "/schemas/types.yaml#/definitions/string"
> > -pattern: 
^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
> > -
> ># RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
> >timebase-frequency: false
> >
> > @@ -133,8 +117,13 @@ properties:
> >DMIPS/MHz, relative to highest capacity-dmips-mhz
> >in the system.
> >
> > +oneOf:
> > +  - required:
> > +  - riscv,isa
>
> This is the part Anup keeps reminding me about. We can create better ways
> to handle extensions in DT and ACPI, but we'll still need to parse ISA
> strings to handle legacy DTs and holdouts that keep creating ISA strings,
> at least during the deprecation period, since ISA strings are still "the
> way to do it" according to the spec.

Coming up with an alternate way in DT is fine but we can't deprecate
ISA strings since ISA strings are widely used:
1) Various bootloaders


Aye, for the reason, as I mentioned earlier and in the RFC thread,
removing existing parsers isn't a good idea.


Removing and deprecating are different.  We can deprecate stuff.


2) It is part of /proc/cpuinfo


That is irrelevant.


3) Hypervisors use it to communicate HW features to Guest/VM.
Hypervisors can't get away from generating ISA strings because
Hypervisors don't know what is running inside Guest/VM.


Generate both :) As things stand, your guests could interpret what you
communicate to them via riscv,isa differently!


In the case of ACPI, it is a very different situation. Like Sunil mentioned,
ACPI will always follow mechanisms defined by RVI (such as ISA string).
Other ACPI approaches such as GUID for ISA extension are simply not
scalable and will take a lot more memory for ACPI tables compared to
ISA strings.


My proposal should actually suit ACPI, at least for Linux, as it would
be a chance to align currently misaligned definitions. I won't speak to
GUIDs or whatever as that's someone else's problem :)


We talked a bit in the patchwork meeting with Drew about ACPI.  Any 
actual spec/encoding would need to be different, of course, but 
conceptually it seems to fit fine.  It's also broadly similar to what 
we've done with riscv_hwprobe() for userspace, which is nice.



> Also, if we assume the wording in the spec does get shored up, then,
> unless I'm missing something, the list of advantages for this boolean
> proposal from your commit message would be

IMO, we should try our best to have the wordings changed in RVI spec.


Yes, doing so is beneficial for all of us regardless of what happens
here. I do think that it is partially orthogonal - it allows us to not
design an interface that needs to be capable of communicating a wide
variety of versions, but I don't think it solves some of the issues
that riscv,isa has. If I thought it did, I would not have gone to the
trouble of respinning this patch out of the other approach.


> * More character choices for name -- probably not a huge gain for ratified
>   extensions, since the boolean properties will likely still use the same
>   name as the ISA string (riscv,isa-extension-). But, for vendor
>   extensions, this is indeed a major improvement, since vendor extension
>   boolean property names may need to be extended in unambiguous ways to
>   handle changes in the extension.
>
> * Simpler, more complete DT validation (but we still need a best effort
>   for legacy ISA strings)
>
> * Simpler DT parsing (but we still need the current parser for legacy ISA
>   strings)
>
> > +  - required:
> > +  - riscv,isa-base
> > +
> >  required:
> > -  - riscv,isa
> >- interrupt-controller
> >
> >  additionalProperties: true
> > @@ -177,7 +166,13 @@ examples:
> >  i-tlb-size = <32>;
> >  mmu-type = "riscv,sv39";
> >  reg = <1>;
> > -riscv,isa = "rv64imafdc";
> > +riscv,isa-base = "rv64i";
> > +riscv,isa-extension-i;
> > +riscv,isa-extension-m;
> > +   

Re: [PATCH] Finish converting CONFIG_SYS_CACHELINE_SIZE to Kconfig

[Palmer Dabbelt]

On Mon, 30 Aug 2021 19:51:28 PDT (-0700), tr...@konsulko.com wrote:

On Tue, Aug 31, 2021 at 04:12:21AM +0200, Daniel Schwierzeck wrote:

Am Donnerstag, dem 26.08.2021 um 11:47 -0400 schrieb Tom Rini:
> We move the SYS_CACHE_SHIFT_N options from arch/arm/Kconfig to
> arch/Kconfig, and introduce SYS_CACHE_SHIFT_4 to provide a size of
> 16.
> Introduce select statements for other architectures based on current
> usage.  For MIPS, we take the existing arch-specific symbol and
> migrate
> to the generic symbol.  This lets us remove a little bit of otherwise
> unused code.
> 
> Cc: Alexey Brodkin 

> Cc: Anup Patel 
> Cc: Atish Patra 
> Cc: Bin Meng 
> Cc: Daniel Schwierzeck 
> Cc: Leo 
> Cc: Palmer Dabbelt 
> Cc: Paul Walmsley 
> Cc: Rick Chen 
> Cc: Sean Anderson 
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> ---
> I'm Cc'ing a bunch of RISC-V folks since that's where I'm least
> confident and just put it per-board for now.


There's nothing in the ISA for cache line sizes, so if it's got to be a 
fixed number it'l need to be a per-device thing and if there's any 
correctness issues there (non-coherent stuff, for example) that will 
break binary compatibility.



> ---
>  arch/Kconfig   | 25 +
>  arch/arc/include/asm/cache.h   |  3 ---
>  arch/arm/Kconfig   | 15 ---
>  arch/mips/Kconfig  | 26 +++---
>  arch/mips/include/asm/cache.h  | 12 +---
>  arch/mips/mach-bmips/Kconfig   | 20 ++--
>  arch/mips/mach-mtmips/Kconfig  |  4 ++--
>  arch/mips/mach-pic32/Kconfig   |  2 +-
>  arch/powerpc/cpu/mpc83xx/Kconfig   |  6 ++
>  arch/powerpc/cpu/mpc85xx/Kconfig   | 15 +++
>  arch/powerpc/cpu/mpc8xx/Kconfig|  2 ++
>  arch/powerpc/include/asm/cache.h   |  7 ---
>  arch/riscv/Kconfig |  2 ++
>  arch/sandbox/include/asm/cache.h   |  1 -
>  arch/x86/include/asm/cache.h   |  7 +--
>  include/configs/M5208EVBE.h|  1 -
>  include/configs/M5235EVB.h |  1 -
>  include/configs/M5249EVB.h |  1 -
>  include/configs/M5253DEMO.h|  1 -
>  include/configs/M5272C3.h  |  1 -
>  include/configs/M5275EVB.h |  1 -
>  include/configs/M5282EVB.h |  1 -
>  include/configs/M53017EVB.h|  1 -
>  include/configs/M5329EVB.h |  1 -
>  include/configs/M5373EVB.h |  1 -
>  include/configs/amcore.h   |  1 -
>  include/configs/astro_mcf5373l.h   |  1 -
>  include/configs/cobra5272.h|  1 -
>  include/configs/eb_cpu5282.h   |  1 -
>  include/configs/mx7ulp_evk.h   |  2 --
>  include/configs/rk3188_common.h|  2 --
>  include/configs/rk3368_common.h|  2 --
>  include/configs/sifive-unmatched.h |  2 --
>  include/configs/sipeed-maix.h  |  1 -
>  include/configs/stmark2.h  |  1 -
>  35 files changed, 68 insertions(+), 103 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig

> index b6f9e177b645..25f4a15b19f9 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -7,6 +7,27 @@ config HAVE_ARCH_IOREMAP
>  config NEEDS_MANUAL_RELOC
>bool
>  
> +config SYS_CACHE_SHIFT_4

> +  bool
> +
> +config SYS_CACHE_SHIFT_5
> +  bool
> +
> +config SYS_CACHE_SHIFT_6
> +  bool
> +
> +config SYS_CACHE_SHIFT_7
> +  bool
> +
> +config SYS_CACHELINE_SIZE
> +  int
> +  default 128 if SYS_CACHE_SHIFT_7
> +  default 64 if SYS_CACHE_SHIFT_6
> +  default 32 if SYS_CACHE_SHIFT_5
> +  default 16 if SYS_CACHE_SHIFT_4
> +  # Fall-back for MIPS
> +  default 32 if MIPS

can't we get rid of the SYS_ prefix? Also _CACHE_ is ambiguous,
L1_CACHE_SHIFT_* and L1_CACHELINE_SIZE are possibly more suitable.
Otherwise:


I don't see a problem to a follow-up renaming things for further
clarity (and using L1 in the name makes sense), but I am for now trying
to (as you've probably noticed) plow through the CONFIG backlog and get
everything migrated.

--
Tom

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Thu, 30 Sep 2021 10:38:02 PDT (-0700), markhimelst...@riscv.org wrote:

The following is the extension lifecycle. It includes the official names
going forward for each phase. We are trying to resolve any confusion naming
and numbering and are still in progress of this evolution:

https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit?usp=sharing

Again, if we can improve anything to make it clearer or if we got something
wrong, please let us know.


That is, unfortunately, even more confusing.

Slide 3 lists the milestones, but that uses very different terms than 
the "Specification States" wiki entry I was linked to earlier as the 
canonical definition of the process.  I'm also now less sure about what 
exactly is being frozen, as the slides seem to mix up extension and 
specification (which is the core of what I'm worried about).


Looking at slide 4 (titled "Extension Lifecycle"), I see a bunch of 
version number looking strings (things like "v0.1" and "v1.0-rcN 
(final)").  Are those versions, and if so what do they version?


It also says "v1.0 (ratified)" with an arrow pointing directly after 
"TSC Ratification Review & Vote", but in the v-1.0 tag I see "Once ratified, 
the spec will be given version 2.0."  Are these version-number-looking 
strings supposed to be things that exist within the same namespace?


Just loking over the slide again I see "New or Changed Features 
Specification Development become a new extension -- Go back to the top 
left".  That sort of seems like something that might help answer some of 
my core questionsn here around what's allowed to change when, but I'm 
genuinely not sure how to parse the words.  Might not be the most 
important thing to focus on now, though.




Mark

On Thu, Sep 30, 2021 at 10:30 AM Palmer Dabbelt  wrote:


On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelst...@riscv.org wrote:
> Palmer,
>
>
>
> Thank you for your input.
>
>
>
> Our strong intention is to not change specs once frozen. I speak for the
> committees here and say that, in our opinion, declaring something frozen
> sets a very high bar for making any changes and is sufficient to allow
code
> supporting an extension to be upstreamed. Of course if an unexpected and
> significant issue is discovered during the public review that absolutely
> must be addressed and cannot be deferred to a future extension (where the
> cost of not addressing the issue exceeds the cost of addressing it. for
> example introduces security vulnerabilities), then we will do so, as
anyone
> should expect from a public review.
>
>
>
> We do not have versions of extensions. If an extension has a problem once
> ratified, we will issue errata. All implementers have to publish the
errata
> if they use branding. We may release a new extension with the bulk of the
> original extension plus the errata fix at some future date.

This is probably at the core of my confusion here.

At the preface of the user ISA there is a table with the headings
"Extension", "Version", and "Frozen"; contains a list of letters that
look like extension name; and contains a list of numbers that look like
versions of those extensions.

That nomenclature seems to carry on to some more recent specifications.
For example the first page of

https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf
(tagged 11 days ago) is

RISC-V "V" Vector Extension
Version 1.0

I'm happy to answer the rest of the questions here, but I think trying
to get on the same page about what is versioned and is proabbly the
first step because that's a pretty key component of my worries.

> New extensions reserve the right to be incompatible with existing
> extensions but our philosophy is very much to minimize that and only
allow
> the rare well-justified exceptions.  Reasons may include errata, security
> issues discovered, or new functionality we need to add that justifies
> creating an incompatibility, etc.
>
> What specifically do you see as an issue? What are you blocked on by our
> conventions? We need specific details to resolve any issues. Right now, I
> don't feel I have enough information from you.
>
>
>
> Thanks
>
> Mark
>
>
>
> P.S. We had some situations in the past, in part due to vendors not
waiting
> for the specification processes to conclude, where implementers
implemented
> non-confoming chips either with vendor-specific extensions using reserved
> opcodes and state, or implementing early drafts of standards-track
> proposals in the development state (will likely change). This is in the
> past and resolved. Anyone implementing non-standard extensions must
> advertise them as such and make it clear that these are not stand

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelst...@riscv.org wrote:

Palmer,



Thank you for your input.



Our strong intention is to not change specs once frozen. I speak for the
committees here and say that, in our opinion, declaring something frozen
sets a very high bar for making any changes and is sufficient to allow code
supporting an extension to be upstreamed. Of course if an unexpected and
significant issue is discovered during the public review that absolutely
must be addressed and cannot be deferred to a future extension (where the
cost of not addressing the issue exceeds the cost of addressing it. for
example introduces security vulnerabilities), then we will do so, as anyone
should expect from a public review.



We do not have versions of extensions. If an extension has a problem once
ratified, we will issue errata. All implementers have to publish the errata
if they use branding. We may release a new extension with the bulk of the
original extension plus the errata fix at some future date.


This is probably at the core of my confusion here.

At the preface of the user ISA there is a table with the headings  
"Extension", "Version", and "Frozen"; contains a list of letters that 
look like extension name; and contains a list of numbers that look like 
versions of those extensions.


That nomenclature seems to carry on to some more recent specifications.  
For example the first page of 
https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf 
(tagged 11 days ago) is


   RISC-V "V" Vector Extension
   Version 1.0

I'm happy to answer the rest of the questions here, but I think trying 
to get on the same page about what is versioned and is proabbly the 
first step because that's a pretty key component of my worries.



New extensions reserve the right to be incompatible with existing
extensions but our philosophy is very much to minimize that and only allow
the rare well-justified exceptions.  Reasons may include errata, security
issues discovered, or new functionality we need to add that justifies
creating an incompatibility, etc.

What specifically do you see as an issue? What are you blocked on by our
conventions? We need specific details to resolve any issues. Right now, I
don't feel I have enough information from you.



Thanks

Mark



P.S. We had some situations in the past, in part due to vendors not waiting
for the specification processes to conclude, where implementers implemented
non-confoming chips either with vendor-specific extensions using reserved
opcodes and state, or implementing early drafts of standards-track
proposals in the development state (will likely change). This is in the
past and resolved. Anyone implementing non-standard extensions must
advertise them as such and make it clear that these are not standard RISC-V
extensions: this should make it clear for upstream projects that they will
be dealing with the respective vendors for support and maintenance, and
that any code implementing support for these extensions will be different
from what covers the respective standard extensions. Whether upstream
projects accept such changes, and what conditions they stipulate for
acceptance of these changes, are beyond the control of RISC-V.  We also, as
I have described to you many times, have instituted mandatory standards
specification states for the front page of each specification to ensure
clarity (any divergence from this is a bug and we work to fix these
quickly).


On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt  wrote:


On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
> the words in this document :
>
>
https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
>
> make it very clear when changes are allowed or not and likely or not.
>
> if you think the verbiage is somehow ambiguous please help us make it
better.

I'm not really worried about changes, I'm worried about a committment to
future compatibility.  When we take code into the kernel (and most other
core systems projects) we're taking on the burden of supporting (until
someone can prove there are no more users), which is very difficult to
do when the ISA changes in an incompatible fashion.  The whole point of
agreeing on the frozen thing was that it gave us a committment from the
specifcation authors that the future ISA would be compatible with th
frozen extensions.

We're already in this spot with the V extension and the whole stable
thing, this definitaion of frozen looks very much like what was has led
to the issues there.  Saying the spec won't change really isn't
meaningful, it's saying future specs will be compatible that's
important.  Nothing in this whole rule touches on compatibility, and I
really don't want to end up in a bigger mess than we're already in.

(Also: some PGE subcontractor drove a crane into my house, so things are
a bit chaotic on my end

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 16:23:56 PDT (-0700), ati...@atishpatra.org wrote:

On Tue, Sep 28, 2021 at 3:43 PM Palmer Dabbelt  wrote:


On Tue, 28 Sep 2021 13:05:53 PDT (-0700), ati...@atishpatra.org wrote:
> On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt  wrote:
>>
>> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
>> > the words in this document :
>> >
>> > 
https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
>> >
>> > make it very clear when changes are allowed or not and likely or not.
>> >
>> > if you think the verbiage is somehow ambiguous please help us make it 
better.
>>
>> I'm not really worried about changes, I'm worried about a committment to
>> future compatibility.  When we take code into the kernel (and most other
>> core systems projects) we're taking on the burden of supporting (until
>> someone can prove there are no more users), which is very difficult to
>> do when the ISA changes in an incompatible fashion.  The whole point of
>> agreeing on the frozen thing was that it gave us a committment from the
>> specifcation authors that the future ISA would be compatible with th
>> frozen extensions.
>>
>> We're already in this spot with the V extension and the whole stable
>> thing, this definitaion of frozen looks very much like what was has led
>> to the issues there.  Saying the spec won't change really isn't
>> meaningful, it's saying future specs will be compatible that's
>> important.  Nothing in this whole rule touches on compatibility, and I
>> really don't want to end up in a bigger mess than we're already in.
>>
>> (Also: some PGE subcontractor drove a crane into my house, so things are
>> a bit chaotic on my end.  If you have that list of what's officially
>> frozen, can you send it out?  I'll try to take a look ASAP, as then I
>> can at least focus the discussion on what's relevant right now.)
>
> Here is the list of the specs that are frozen.
> 
https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone

How does that indicate what is frozen?  I see "ISA Extensions On Deck
for Freeze Milestone" as the title, which makes it sound like these are
extension that are not yet frozen but will be eventually.


Any row with "top sheet" complete and "out for public review" is frozen.
The life cycle document[1] that I shared earlier in this thread also
says the same i.e. any specification that is out for public review is
frozen.
Stephano also sent out a public email about all the specifications
that are frozen.

However, I understand that you need to do a little bit of deduction to
understand what is frozen.
@Stephano(already cc'd here)

Can you add a separate column clearly indicating that "Freeze" status
for each of those specifications in the wiki link.


Is meant to be the complete list of what is frozen?

I'd expect any list of things that are frozen to contain the specs we've 
been working with for a while (priv-1.11, all the user 2.0 specs, etc).  
There was some talk about the SBI stuff that was called out as frozen 
before this process not actually being frozen, are those other specs in 
the same spot and if so are they going to end up being frozen?


That reminds me about this other set of specifications, sometimes called 
software specifications.  There's a list of "Non-ISA Extensions On Deck 
for Freeze Milestone" here: 
https://wiki.riscv.org/display/TECH/Non-ISA+Extensions+On+Deck+for+Freeze+Milestone 
.  That's got a frozen column in the table, but the table itself is 
pretty much empty.  We've had a bunch of confusing statements about 
those specifications being frozen, were the statements inaccurate, is 
that table inaccurate, and will that table be an additional list of 
frozen specifications?




[1] 
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1


Scrolling down to the end of that list, it lists pointer masking.  The
best I can find is
https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc
, which says "Version: v0.1-draft", which definately doesn't sound
frozen.  The README says "Working Draft of the RISC-V J Extension
Specification", which also doesn't sound frozen.

> I will let Mark comment on the compatibility thing.
>
>>
>> >
>> > Mark
>> > 
>> > sent from a mobile device. please forgive any typos.
>> >
>> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt  wrote:
>> >>
>> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:
>> >>> Hi All,
>> >>> Please find the below email from S

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 13:05:53 PDT (-0700), ati...@atishpatra.org wrote:

On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt  wrote:


On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
> the words in this document :
>
> 
https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
>
> make it very clear when changes are allowed or not and likely or not.
>
> if you think the verbiage is somehow ambiguous please help us make it better.

I'm not really worried about changes, I'm worried about a committment to
future compatibility.  When we take code into the kernel (and most other
core systems projects) we're taking on the burden of supporting (until
someone can prove there are no more users), which is very difficult to
do when the ISA changes in an incompatible fashion.  The whole point of
agreeing on the frozen thing was that it gave us a committment from the
specifcation authors that the future ISA would be compatible with th
frozen extensions.

We're already in this spot with the V extension and the whole stable
thing, this definitaion of frozen looks very much like what was has led
to the issues there.  Saying the spec won't change really isn't
meaningful, it's saying future specs will be compatible that's
important.  Nothing in this whole rule touches on compatibility, and I
really don't want to end up in a bigger mess than we're already in.

(Also: some PGE subcontractor drove a crane into my house, so things are
a bit chaotic on my end.  If you have that list of what's officially
frozen, can you send it out?  I'll try to take a look ASAP, as then I
can at least focus the discussion on what's relevant right now.)


Here is the list of the specs that are frozen.
https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone


How does that indicate what is frozen?  I see "ISA Extensions On Deck 
for Freeze Milestone" as the title, which makes it sound like these are 
extension that are not yet frozen but will be eventually.


Scrolling down to the end of that list, it lists pointer masking.  The 
best I can find is 
https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc 
, which says "Version: v0.1-draft", which definately doesn't sound 
frozen.  The README says "Working Draft of the RISC-V J Extension 
Specification", which also doesn't sound frozen.



I will let Mark comment on the compatibility thing.



>
> Mark
> 
> sent from a mobile device. please forgive any typos.
>
>> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt  wrote:
>>
>> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:
>>> Hi All,
>>> Please find the below email from Stephano about the freeze announcement for
>>> various RISC-V specifications that will be part of privilege specification
>>> v1.12.
>>> All the review discussions are happening in the isa-dev mailing list. The
>>> review period will be open for 45 days ending Sunday October 31, 2021.
>>>
>>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions
>>> are frozen now. *This will help us merge some patches that have been
>>> present in the mailing list for a while.
>>>
>>> Here are the ratification policy and extension life cycle documents present
>>> in the public. If you have any questions regarding this, please check with
>>> Mark/Stephano (cc'd).
>>>
>>> Ratification policy:
>>> 
https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit
>>>
>>> Extension life cycle:
>>> 
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>>
>> I'm still buried after Plumbers, but one of the bits on my TODO list was to 
look throught the new definitions for frozen and stable.  Nothing in this extension 
life cycle talks about the point at which compatibility will be maintained, which was 
really the central point behind frozen before.
>>
>> Are there more concrete definitions somewhere?




--
Regards,
Atish

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
the words in this document : 


https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230

make it very clear when changes are allowed or not and likely or not.

if you think the verbiage is somehow ambiguous please help us make it better.


I'm not really worried about changes, I'm worried about a committment to 
future compatibility.  When we take code into the kernel (and most other 
core systems projects) we're taking on the burden of supporting (until 
someone can prove there are no more users), which is very difficult to 
do when the ISA changes in an incompatible fashion.  The whole point of 
agreeing on the frozen thing was that it gave us a committment from the 
specifcation authors that the future ISA would be compatible with th 
frozen extensions.


We're already in this spot with the V extension and the whole stable 
thing, this definitaion of frozen looks very much like what was has led 
to the issues there.  Saying the spec won't change really isn't 
meaningful, it's saying future specs will be compatible that's 
important.  Nothing in this whole rule touches on compatibility, and I 
really don't want to end up in a bigger mess than we're already in.


(Also: some PGE subcontractor drove a crane into my house, so things are 
a bit chaotic on my end.  If you have that list of what's officially 
frozen, can you send it out?  I'll try to take a look ASAP, as then I 
can at least focus the discussion on what's relevant right now.)




Mark

sent from a mobile device. please forgive any typos.


On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt  wrote:

On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:

Hi All,
Please find the below email from Stephano about the freeze announcement for
various RISC-V specifications that will be part of privilege specification
v1.12.
All the review discussions are happening in the isa-dev mailing list. The
review period will be open for 45 days ending Sunday October 31, 2021.

I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions
are frozen now. *This will help us merge some patches that have been
present in the mailing list for a while.

Here are the ratification policy and extension life cycle documents present
in the public. If you have any questions regarding this, please check with
Mark/Stephano (cc'd).

Ratification policy:
https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit

Extension life cycle:
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1


I'm still buried after Plumbers, but one of the bits on my TODO list was to 
look throught the new definitions for frozen and stable.  Nothing in this 
extension life cycle talks about the point at which compatibility will be 
maintained, which was really the central point behind frozen before.

Are there more concrete definitions somewhere?

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:

Hi All,
Please find the below email from Stephano about the freeze announcement for
various RISC-V specifications that will be part of privilege specification
v1.12.
All the review discussions are happening in the isa-dev mailing list. The
review period will be open for 45 days ending Sunday October 31, 2021.

I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions
are frozen now. *This will help us merge some patches that have been
present in the mailing list for a while.

Here are the ratification policy and extension life cycle documents present
in the public. If you have any questions regarding this, please check with
Mark/Stephano (cc'd).

Ratification policy:
https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit

Extension life cycle:
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1


I'm still buried after Plumbers, but one of the bits on my TODO list was 
to look throught the new definitions for frozen and stable.  Nothing in 
this extension life cycle talks about the point at which compatibility 
will be maintained, which was really the central point behind frozen 
before.


Are there more concrete definitions somewhere?

RISC-V MC at Plumbers

[Palmer Dabbelt]

Looks like our first attempt at sending a message bounced, so this never 
got properly announced.  We've got Microconference at Plumbers again 
this year, the CFP is still open.


https://www.linuxplumbersconf.org/blog/2021/index.php/2021/07/26/risc-v-microconference-accepted-into-2021-linux-plumbers-conference/

Re: [PATCH v7 0/8] Add FU740 chip and HiFive Unmatched board support

[Palmer Dabbelt]

On Thu, 22 Apr 2021 20:40:43 PDT (-0700), Palmer Dabbelt wrote:

On Thu, 22 Apr 2021 02:11:51 PDT (-0700), green@sifive.com wrote:

This patch set is to add SiFive fu740 chip and HiFive Unmatched board
support. Patches are split into several parts:

  - [PATCH v7 1/8] support for fu740 cpu
  - [PATCH v7 2/8] support for fu740 clk driver
  - [PATCH v7 3/8] rename and support for fu740 ram driver
  - [PATCH v7 4/8] add pcie driver
  - [PATCH v7 5/8] dts for SiFive fu740
  - [PATCH v7 6/8] dts for SiFive Unmatched board
  - [PATCH v7 7/8] add Unmatched board support
  - [PATCH v7 8/8] add fu740 support to macb driver


I've got a bunch of versions of this in my inbox, but I always have an
arbitrary subset of the patches.  This generally LGTM, but it's kind of
hard to figure out what goes where when patch sets are split between
trees like this.

IMO the drivers don't need to be in my tree for the DTS files to get
merged, we just need the bindings to be agreed upon.  Can you send a
version of this with just the patches that haven't otherwise been merged
and are relevant for the RISC-V tree?


Ah, sorry, I'm lost here -- I thought this was a Linux patch set.  That 
probably explains why I can't follow the thread... ;)






Description

  - For fu740 cpu support, reuse most of fu540 cpu.
  - For prci driver, add one abstract layer to separate fu540 and
fu740. Move orignal fu540 code to separate files.
  - For pcie driver, it depends on gpio, prci, clk and reset drivers
to do init works. Also based on pcie_dw_common.c
  - Align with Linux DT file.

Tests and patch checks

  - Able to boot both unmatched and unleashed boards.
  - PCIe tests
. M.2 NVMe SSD
. e1000 compatibale ethernet adapter (ping)
. pci-to-usb adapter(usb mass storage)
  - checkpatch is performed. To keep code derived from other boards
the same, ignore some warnings/errors in [PATCH 7/8].

Changlogs
  - V7
. Rebase to latest master branch
. Moved dts for fu740 patch [v6 1/7] to [v7 5/8] and seperate dts of
  Unmatched board from [v6 6/7] into [v7 6/8]
. Applied PCIe refactoring patch to base on the common code in
  pcie_dw_common.c
  - V6
. Remove redundant DT string for 1.2GHz CPU clock and squash to
  [1/7]
  - V5
. Fix unleashed build error in patch [6/8]
. Append one more set for 1.2GHz CPU speed
. Add "#include " back to sifive_ddr.c
. Add Reviewed-by to [4/8] and [7/8]
  - V4
. fixed incorrect file name in ./board/sifive/unmatched/Makefile
. fixed link in doc/board/sifive/index.rst, passed 'make htmldocs'
  - V3
. Rebase to unleashed rename v2 patch
. Rename
  doc/board/sifive/unmatched.rst
  board/sifive/unmatched/unmatched.c
. Fix tail whitespace
. Add 'git mv' info to ram driver and merge patch back to one
. Add comment to macb driver for PLL hardware quirk
. Add reviewed-by to patch [6/7]
. Add 'gpio-poweroff' node for upcoming opensbi integration
  - V2
. Rebase to unleashed rename patch
. remove unnessaary fu540 changes
. split ram driver patch into 2 to keep 'git mv' info
. use a shorter name for unmatched support
. Remove redundant temperature-sensor in DT
. Remove unnecessary USB EHCI & OHCI from defconfig
. Revised fu740 doc
. Fixed year of copyright
. Add reviewed-by received in v1 patch

David Abdurachmanov (1):
  drivers: net: macb: add fu740 support

Green Wan (7):
  riscv: cpu: fu740: Add support for cpu fu740
  drivers: clk: add fu740 support
  drivers: ram: sifive: rename fu540_ddr and add fu740 support
  drivers: pci: add pcie support for fu740
  riscv: dts: add fu740 support
  riscv: dts: add SiFive Unmatched board support
  board: sifive: add HiFive Unmatched board support

 arch/riscv/Kconfig|5 +
 arch/riscv/cpu/fu740/Kconfig  |   37 +
 arch/riscv/cpu/fu740/Makefile |   12 +
 arch/riscv/cpu/fu740/cache.c  |   55 +
 arch/riscv/cpu/fu740/cpu.c|   22 +
 arch/riscv/cpu/fu740/dram.c   |   38 +
 arch/riscv/cpu/fu740/spl.c|   23 +
 arch/riscv/dts/Makefile   |1 +
 arch/riscv/dts/fu740-c000-u-boot.dtsi |  105 ++
 arch/riscv/dts/fu740-c000.dtsi|  329 
 .../dts/fu740-hifive-unmatched-a00-ddr.dtsi   | 1489 +
 .../dts/hifive-unmatched-a00-u-boot.dtsi  |   40 +
 arch/riscv/dts/hifive-unmatched-a00.dts   |  259 +++
 arch/riscv/include/asm/arch-fu740/cache.h |   14 +
 arch/riscv/include/asm/arch-fu740/clk.h   |   14 +
 arch/riscv/include/asm/arch-fu740/gpio.h  |   38 +
 arch/riscv/include/asm/arch-fu740/reset.h |   13 +
 arch/riscv/include/asm/arch-fu740/spl.h   |   14 +
 arch/riscv/lib/sifive_clint.c |1 -
 board/sifive/unleashed/Kconfig|1 +
 board/sifive/unmatched/Kconfig|   50 +

Re: [PATCH v7 0/8] Add FU740 chip and HiFive Unmatched board support

[Palmer Dabbelt]

On Thu, 22 Apr 2021 02:11:51 PDT (-0700), green@sifive.com wrote:

This patch set is to add SiFive fu740 chip and HiFive Unmatched board
support. Patches are split into several parts:

  - [PATCH v7 1/8] support for fu740 cpu
  - [PATCH v7 2/8] support for fu740 clk driver
  - [PATCH v7 3/8] rename and support for fu740 ram driver
  - [PATCH v7 4/8] add pcie driver
  - [PATCH v7 5/8] dts for SiFive fu740
  - [PATCH v7 6/8] dts for SiFive Unmatched board
  - [PATCH v7 7/8] add Unmatched board support
  - [PATCH v7 8/8] add fu740 support to macb driver


I've got a bunch of versions of this in my inbox, but I always have an 
arbitrary subset of the patches.  This generally LGTM, but it's kind of 
hard to figure out what goes where when patch sets are split between 
trees like this.


IMO the drivers don't need to be in my tree for the DTS files to get 
merged, we just need the bindings to be agreed upon.  Can you send a 
version of this with just the patches that haven't otherwise been merged 
and are relevant for the RISC-V tree?




Description

  - For fu740 cpu support, reuse most of fu540 cpu.
  - For prci driver, add one abstract layer to separate fu540 and
fu740. Move orignal fu540 code to separate files.
  - For pcie driver, it depends on gpio, prci, clk and reset drivers
to do init works. Also based on pcie_dw_common.c
  - Align with Linux DT file.

Tests and patch checks

  - Able to boot both unmatched and unleashed boards.
  - PCIe tests
. M.2 NVMe SSD
. e1000 compatibale ethernet adapter (ping)
. pci-to-usb adapter(usb mass storage)
  - checkpatch is performed. To keep code derived from other boards
the same, ignore some warnings/errors in [PATCH 7/8].

Changlogs
  - V7
. Rebase to latest master branch
. Moved dts for fu740 patch [v6 1/7] to [v7 5/8] and seperate dts of
  Unmatched board from [v6 6/7] into [v7 6/8]
. Applied PCIe refactoring patch to base on the common code in
  pcie_dw_common.c
  - V6
. Remove redundant DT string for 1.2GHz CPU clock and squash to
  [1/7]
  - V5
. Fix unleashed build error in patch [6/8]
. Append one more set for 1.2GHz CPU speed
. Add "#include " back to sifive_ddr.c
. Add Reviewed-by to [4/8] and [7/8]
  - V4
. fixed incorrect file name in ./board/sifive/unmatched/Makefile
. fixed link in doc/board/sifive/index.rst, passed 'make htmldocs'
  - V3
. Rebase to unleashed rename v2 patch
. Rename
  doc/board/sifive/unmatched.rst
  board/sifive/unmatched/unmatched.c
. Fix tail whitespace
. Add 'git mv' info to ram driver and merge patch back to one
. Add comment to macb driver for PLL hardware quirk
. Add reviewed-by to patch [6/7]
. Add 'gpio-poweroff' node for upcoming opensbi integration
  - V2
. Rebase to unleashed rename patch
. remove unnessaary fu540 changes
. split ram driver patch into 2 to keep 'git mv' info
. use a shorter name for unmatched support
. Remove redundant temperature-sensor in DT
. Remove unnecessary USB EHCI & OHCI from defconfig
. Revised fu740 doc
. Fixed year of copyright
. Add reviewed-by received in v1 patch

David Abdurachmanov (1):
  drivers: net: macb: add fu740 support

Green Wan (7):
  riscv: cpu: fu740: Add support for cpu fu740
  drivers: clk: add fu740 support
  drivers: ram: sifive: rename fu540_ddr and add fu740 support
  drivers: pci: add pcie support for fu740
  riscv: dts: add fu740 support
  riscv: dts: add SiFive Unmatched board support
  board: sifive: add HiFive Unmatched board support

 arch/riscv/Kconfig|5 +
 arch/riscv/cpu/fu740/Kconfig  |   37 +
 arch/riscv/cpu/fu740/Makefile |   12 +
 arch/riscv/cpu/fu740/cache.c  |   55 +
 arch/riscv/cpu/fu740/cpu.c|   22 +
 arch/riscv/cpu/fu740/dram.c   |   38 +
 arch/riscv/cpu/fu740/spl.c|   23 +
 arch/riscv/dts/Makefile   |1 +
 arch/riscv/dts/fu740-c000-u-boot.dtsi |  105 ++
 arch/riscv/dts/fu740-c000.dtsi|  329 
 .../dts/fu740-hifive-unmatched-a00-ddr.dtsi   | 1489 +
 .../dts/hifive-unmatched-a00-u-boot.dtsi  |   40 +
 arch/riscv/dts/hifive-unmatched-a00.dts   |  259 +++
 arch/riscv/include/asm/arch-fu740/cache.h |   14 +
 arch/riscv/include/asm/arch-fu740/clk.h   |   14 +
 arch/riscv/include/asm/arch-fu740/gpio.h  |   38 +
 arch/riscv/include/asm/arch-fu740/reset.h |   13 +
 arch/riscv/include/asm/arch-fu740/spl.h   |   14 +
 arch/riscv/lib/sifive_clint.c |1 -
 board/sifive/unleashed/Kconfig|1 +
 board/sifive/unmatched/Kconfig|   50 +
 board/sifive/unmatched/MAINTAINERS|9 +
 board/sifive/unmatched/Makefile   |9 +
 board/sifive/unmatched/spl.c  |   85 +
 board/sifive/unmatched/unmatched.c

Re: [PATCH] sifive: fix palmer's email address

[Palmer Dabbelt]

On Thu, 30 Apr 2020 07:42:03 PDT (-0700), pragnesh.pa...@sifive.com wrote:

Fix Palmer's email address

Signed-off-by: Pragnesh Patel 
Reviewed-by: Bin Meng 
---
 board/sifive/fu540/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
index 702d803ad8..5381fc0639 100644
--- a/board/sifive/fu540/MAINTAINERS
+++ b/board/sifive/fu540/MAINTAINERS
@@ -1,6 +1,6 @@
 SiFive FU540 BOARD
 M: Paul Walmsley 
-M: Palmer Dabbelt 
+M: Palmer Dabbelt 
 M: Anup Patel 
 M: Atish Patra 
 S: Maintained


Thanks.  The dabbelt.com email is good, as the google.com one has trouble with
mailing lists.

Reviewed-by: Palmer Dabbelt 

Re: [PATCH v4 13/14] sifive: fix palmer's email address

[Palmer Dabbelt]

On Mon, 24 Feb 2020 00:32:45 PST (-0800), pragnesh.pa...@sifive.com wrote:

Fix Palmer's email address

Signed-off-by: Pragnesh Patel 
---
 board/sifive/fu540/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
index 702d803ad8..9bae3d3db7 100644
--- a/board/sifive/fu540/MAINTAINERS
+++ b/board/sifive/fu540/MAINTAINERS
@@ -1,6 +1,6 @@
 SiFive FU540 BOARD
 M: Paul Walmsley 
-M: Palmer Dabbelt 
+M: Palmer Dabbelt 
 M: Anup Patel 
 M: Atish Patra 
 S: Maintained


Thanks, these are all over the place and I'm afraid I've lost track of them.  I
decided to use pal...@dabbelt.com because I've yet to get the Google passing
DMARC checks.

Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed

[Palmer Dabbelt]

On Mon, 03 Jun 2019 10:02:57 PDT (-0700), tr...@konsulko.com wrote:

On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:



> On Jun 3, 2019, at 5:49 AM, Andreas Schwab  wrote:
> 
> On Mai 29 2019, Karsten Merker  wrote:
> 
>> Mainline U-Boot already uses the distro bootcmd environment for

>> the qemu "virt" machine and it works well.
> 
> The distro_bootcmd doesn't work for the sifive platform yet because it

> doesn't set the correct MAC address for booting.
> 
> Andreas.
> 

Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
we really should not be using, can we make some kind of effort to decide
what the design goals and boot flow should look like instead using the 
default legacy behavior of a bunch of hard to read and maintain CPP

macros?


I feel like you're calling "what everyone agreed on and uses today"
legacy just because it already exists.  It is a bit complex because
devices are so complex, rather than it having to support one-off
situations or similar things people usually call "legacy".


The goal in RISC-V land is to avoid inventing our own stuff, particularly when
there's an agreed upon way of doing things.  As far as I can tell the users
(ie, distros) all want this distro_bootcmd stuff because it's what already
works in ARM land.  While I'm not really a bootloader guy, the general
arguments in favor of distro_bootcmd appaer to be "we tried it some other ways
and that was a mess, but this way works".  That is a really strong argument to
me.


The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.

What good does it do linux distros on RiscV to keep using the old boot
script format, rather than just load a text file and use ‘env import’? Is there
some benefit to this? Do we gain something from the .scr format, like
maybe cryptographic signature support?


Writing things out in script format ends up being more natural (and
easier to understand) than writing things out in environment format.
This is why while I wish the "uEnv.txt" hook had become more popular and
widely used, at this point I also understand why it wasn't.  Doing
a=foo
b=bar
c=baz
magic_name=do this;do that

Was not easier nor more understandable than:
setenv a foo
setenv b bar
setenv c baz
do this; do that


How do we want to support secure boot into Debian, Fedora, and Suse,
and does distro_bootcmd have a way to do this, or can we come up with
some improvement that doesn’t depend on trying to do all the work in
CPP macros and U-boot runtime scripts?


I think the general answer about "secure boot" is that distros want
"UEFI secure boot".  And I want to make sure that's done in such a way
that things like user-owned secure boot aren't any more difficult than
vendor secured boot.  It seems like making use of existing secure boot
mechanisms has set aside as, well, I don't want to throw snark around
myself, so I'll refrain from speculating.

--
Tom

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/11] SMP support for RISC-V

[Palmer Dabbelt]

On Sun, 17 Mar 2019 11:28:31 PDT (-0700), lukas.a...@aisec.fraunhofer.de wrote:

This patch series adds SMP support for RISC-V to U-Boot. It allows
U-Boot to run on multi-hart systems (hart is the RISC-V terminology for
hardware thread). Images passed to bootm will be started on all harts.
The bootm command is currently the only one that will boot images on all
harts, bootefi is not yet supported.

The patches have been successfully tested on both QEMU (machine and
supervisor mode) and the HiFive Unleashed board (supervisor mode), using
BBL and OpenSBI.
Mainline QEMU requires two patches [1, 2] to run in this configuration.
Patch [1] has been dropped and will be replaced with a U-Boot patch.

[1]: https://patchwork.ozlabs.org/patch/1039493/


As far as I understand it we're taking a different approach here, so this patch 
won't be going in.



[2]: https://patchwork.ozlabs.org/patch/1039082/


This should be in rc0, LMK if I screwed something up.

Thanks for the patches, and also for testing on the board :)


Changes in v3:
- Print error if riscv_send_ipi() fails
- Adjust error message for failures of riscv_clear_ipi() to match error
message for failures of riscv_send_ipi()
- New patch to save the hart ID in register tp instead of s0
- Adjust patch to use the new location of the hart ID (register tp)
- New patch to hang if relocation of secondary harts fails

Changes in v2:
- Remove unneeded quotes from NR_CPUS Kconfig entry
- Move memory barrier from send_ipi_many() to handle_ipi()
- Add check in send_ipi_many so that IPIs are only sent to available
harts as indicated by the available_harts mask
- Implement hart lottery to pick main hart to run U-Boot
- Remove CONFIG_MAIN_HART as it is not required anymore
- Register available harts in the available_harts mask
- New patch to populate register a0 with the hart ID from the mhartid
CSR in machine-mode
- New patch to enable SMP on the SiFive FU540, which was previously sent
independently

Lukas Auer (11):
  riscv: add infrastructure for calling functions on other harts
  riscv: import the supervisor binary interface header file
  riscv: implement IPI platform functions using SBI
  riscv: delay initialization of caches and debug UART
  riscv: save hart ID in register tp instead of s0
  riscv: add support for multi-hart systems
  riscv: boot images passed to bootm on all harts
  riscv: do not rely on hart ID passed by previous boot stage
  riscv: hang if relocation of secondary harts fails
  riscv: fu540: enable SMP
  riscv: qemu: enable SMP

 arch/riscv/Kconfig   |  28 +
 arch/riscv/cpu/cpu.c |   9 +-
 arch/riscv/cpu/start.S   | 167 +--
 arch/riscv/include/asm/csr.h |   1 +
 arch/riscv/include/asm/global_data.h |   6 +
 arch/riscv/include/asm/sbi.h |  94 +++
 arch/riscv/include/asm/smp.h |  53 +
 arch/riscv/lib/Makefile  |   2 +
 arch/riscv/lib/asm-offsets.c |   1 +
 arch/riscv/lib/bootm.c   |  13 ++-
 arch/riscv/lib/sbi_ipi.c |  25 
 arch/riscv/lib/smp.c | 118 +++
 board/emulation/qemu-riscv/Kconfig   |   1 +
 board/sifive/fu540/Kconfig   |   1 +
 14 files changed, 507 insertions(+), 12 deletions(-)
 create mode 100644 arch/riscv/include/asm/sbi.h
 create mode 100644 arch/riscv/include/asm/smp.h
 create mode 100644 arch/riscv/lib/sbi_ipi.c
 create mode 100644 arch/riscv/lib/smp.c

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Palmer Dabbelt]

On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng...@gmail.com wrote:

On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman  wrote:


Kevin Hilman  writes:

> Hi Anup,
>
> Anup Patel  writes:
>
>> This patchset adds SiFive Freedom Unleashed (FU540) support
>> to RISC-V U-Boot.
>>
>> The patches are based upon latest U-Boot source tree
>> (git://git.denx.de/u-boot.git) at commit id
>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>
>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>> MACB Ethernet work fine on actual SiFive Unleashed board and
>> QEMU sifive_u machine.
>
> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
> and DHCP doesn't work anymore.

And to be clear, neither does TFTP if setting static
ipaddr/netmask/gatewayip etc.


Sound to me a bug of the GEM driver on SiFive FU540 board.


It looks to me like u-boot is missing a driver for the GEM clockmux in the 
FU540.  This is necessary to switch between the clock for 1G operation and 100M 
operation.  Without this you'll just get whatever clock was set up by the 
previous boot stage (or even worse, reset).

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Palmer Dabbelt]

On Thu, 07 Mar 2019 19:37:30 PST (-0800), Anup Patel wrote:




-Original Message-
From: Andreas Schwab 
Sent: Thursday, March 7, 2019 2:50 PM
To: Anup Patel 
Cc: Atish Patra ; Anup Patel ;
Auer, Lukas ; paul.walms...@sifive.com;
ag...@suse.de; u-boot@lists.denx.de; bar...@tkos.co.il;
daniel.schwierz...@gmail.com; bmeng...@gmail.com;
r...@andestech.com; s...@denx.de; pal...@sifive.com
Subject: Re: [PATCH v2 0/9] SMP support for RISC-V

On Mär 07 2019, Anup Patel  wrote:

> Like I mentioned, there is no functional issue with this series. The
> warm-boot issues were fixed in OpenSBI.
>
> @Andreas, please try at your end.

As long as issue#65 isn't fixed opensbi is mostly a no-go for me.  At least it
gives me more reasons to press the reset button. :-)


The reset button works fine for me an Atish. I am sure it works fine for lot of
other folks too.

BTW, as-per discussion with SiFive folks the reset button on Unleashed
Board is not much tested and it can misbehave on certain boards. It is quite
possible that you might have a "flaky" board.


I don't think the reset button differs between boards.  As far as I know, the 
issues are really just that it doesn't reset everything -- specifically some of 
the IP on the chip (clock, power, JTAG) isn't reset and nothing on the board 
(SD, ethernet, PCIe, etc) is reset.  This frequently results in flakiness when 
debugging drivers, but the cores and memory system should all be OK.


Is that issue 65 on github.com/opensbi?  If so it clearly says this isn't a 
reset button issue.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 00/15] SiFive FU540 Support

[Palmer Dabbelt]

On Thu, 21 Feb 2019 15:41:02 PST (-0800), tr...@konsulko.com wrote:

On Wed, Feb 20, 2019 at 05:45:59AM +, Anup Patel wrote:


This patchset adds SiFive Freedom Unleashed (FU540) support
to RISC-V U-Boot.

The patches are based upon latest U-Boot source tree
(git://git.denx.de/u-boot.git) at v2019.04-rc2 commit id
f14de0014c56093feecf42ca38b8ae5b3878f176

All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
MACB Ethernet work fine on actual SiFive Unleashed board and
QEMU sifive_u machine.


Is the sifive_u QEMU machine in upstream QEMU?  If so, lets add it to
the travis file and run tests.  Thanks!


It's been upstream for a while, though we might deprecate it in the future 
because the name is a bit ambiguous.  There's nothing better right now, so it's 
probably a good bet to test against.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] riscv: qemu: Enable SiFive UART driver in defconfigs

[Palmer Dabbelt]

On Tue, 04 Dec 2018 22:29:24 PST (-0800), a...@brainfault.org wrote:

This patch enables SiFive UART driver in all QEMU RISC-V defconfigs.

Signed-off-by: Anup Patel 
---
 configs/qemu-riscv32_defconfig   | 1 +
 configs/qemu-riscv32_smode_defconfig | 1 +
 configs/qemu-riscv64_defconfig   | 1 +
 configs/qemu-riscv64_smode_defconfig | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index 6334d8c0fc..79c8d54cc7 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -7,3 +7,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_SIFIVE_SERIAL=y
diff --git a/configs/qemu-riscv32_smode_defconfig 
b/configs/qemu-riscv32_smode_defconfig
index 0a84ec1874..b733dbed2f 100644
--- a/configs/qemu-riscv32_smode_defconfig
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_SIFIVE_SERIAL=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index 2d9ead93a2..a9d19a5574 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_SIFIVE_SERIAL=y
diff --git a/configs/qemu-riscv64_smode_defconfig 
b/configs/qemu-riscv64_smode_defconfig
index b012443370..8adc23f826 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -9,3 +9,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_SIFIVE_SERIAL=y


Reviewed-by: Palmer Dabbelt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] drivers: serial: Add SiFive UART driver

[Palmer Dabbelt]

efore changing the 
baud rate.  I don't know anything about u-boot so I'm not sure if that's 
expected.



+static int sifive_serial_probe(struct udevice *dev)
+{
+   struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
+
+   /* No need to reinitialize the UART after relocation */
+   if (gd->flags & GD_FLG_RELOC)
+   return 0;
+
+   _sifive_serial_init(platdata->regs);
+
+   return 0;
+}
+
+static int sifive_serial_getc(struct udevice *dev)
+{
+   int c;
+   struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
+   struct uart_sifive *regs = platdata->regs;
+
+   while ((c = _sifive_serial_getc(regs)) == -EAGAIN) ;
+
+   return c;
+}
+
+static int sifive_serial_putc(struct udevice *dev, const char ch)
+{
+   int rc;
+   struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
+
+   while ((rc = _sifive_serial_putc(platdata->regs, ch)) == -EAGAIN) ;
+
+   return rc;
+}
+
+static int sifive_serial_ofdata_to_platdata(struct udevice *dev)
+{
+   struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
+
+   platdata->regs = (struct uart_sifive *)dev_read_addr(dev);
+   if (IS_ERR(platdata->regs))
+   return PTR_ERR(platdata->regs);
+
+   return 0;
+}
+
+static const struct dm_serial_ops sifive_serial_ops = {
+   .putc = sifive_serial_putc,
+   .getc = sifive_serial_getc,
+   .setbrg = sifive_serial_setbrg,
+};
+
+static const struct udevice_id sifive_serial_ids[] = {
+   { .compatible = "sifive,uart0" },
+   { }
+};
+
+U_BOOT_DRIVER(serial_sifive) = {
+   .name   = "serial_sifive",
+   .id = UCLASS_SERIAL,
+   .of_match = sifive_serial_ids,
+   .ofdata_to_platdata = sifive_serial_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct sifive_uart_platdata),
+   .probe = sifive_serial_probe,
+   .ops= _serial_ops,
+   .priv_auto_alloc_size   = sizeof(struct sifive_uart_platdata),
+};
+
+#ifdef CONFIG_DEBUG_UART_SIFIVE
+static inline void _debug_uart_init(void)
+{
+   struct uart_sifive *regs =
+   (struct uart_sifive *)CONFIG_DEBUG_UART_BASE;
+
+   _sifive_serial_setbrg(regs, CONFIG_DEBUG_UART_CLOCK,
+ CONFIG_BAUDRATE);
+   _sifive_serial_init(regs);
+}
+
+static inline void _debug_uart_putc(int ch)
+{
+   struct uart_sifive *regs =
+   (struct uart_sifive *)CONFIG_DEBUG_UART_BASE;
+
+   while (_sifive_serial_putc(regs, ch) == -EAGAIN)
+   WATCHDOG_RESET();
+}
+
+DEBUG_UART_FUNCS
+
+#endif


Reviewed-by: Palmer Dabbelt 

Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Palmer Dabbelt]

On Wed, 21 Nov 2018 14:06:00 PST (-0800), lukas.a...@aisec.fraunhofer.de wrote:

Hi Palmer,

On Wed, 2018-11-21 at 08:28 -0800, Palmer Dabbelt wrote:

On Tue, 20 Nov 2018 19:41:10 PST (-0800), a...@brainfault.org wrote:
> This patch adds kconfig option RISCV_SMODE to run u-boot in
> S-mode. When this opition is enabled we use s CSRs instead
> of m CSRs.
> 
> It is important to note that there is no equivalent S-mode CSR

> for misa and mhartid CSRs so we expect M-mode runtime firmware
> (BBL or equivalent) to emulate misa and mhartid CSR read.
> 
> In-future, we will have more patches to avoid accessing misa and

> mhartid CSRs from S-mode.

Ya, I don't like this.  Our current boot protocol puts mhartid in a1
upon 
entering the supervisor, and allows the detection of misa via a
device tree 
pointer provided in a0.  


As long as everyone agrees this isn't what we're actually looking for
then I'm 
fine with the patch, I just don't want to end up requiring this "M
mode 
emulates some CSRs for S mode" interface.  Since we don't have an
actual 
platform spec we've got to be careful to avoid a bunch of defacto
interfaces 
that we'll need to support later.




I agree with you. We actually won't need the CSR emulation of misa and
mhartid for long. With Bin's recent patch series [1], the ISA string is
read from the device tree, replacing the use of misa. mhartid is only
used to pass the hart id to the kernel. I am going to replace it in a
patch series I am working on.
So the interface should just be temporary.


Great, thanks!



Thanks,
Lukas

[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=75644

> 
> Signed-off-by: Anup Patel 

> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
> ---
>  arch/riscv/Kconfig |  5 +
>  arch/riscv/cpu/start.S | 33 +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig

> index 3e0af55e71..8f2139ff60 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -55,6 +55,11 @@ config RISCV_ISA_C
>  config RISCV_ISA_A
>def_bool y
> 
> +config RISCV_SMODE

> +  bool "Run in S-Mode"
> +  help
> +Enable this option to build an U-Boot for RISC-V S-Mode
> +
>  config 32BIT
>bool
> 
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S

> index 5af189b338..e4276e8e19 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -39,10 +39,18 @@ _start:
>mv  s1, a1
> 
>  	la	t0, trap_entry

> +#ifdef CONFIG_RISCV_SMODE
> +  csrwstvec, t0
> +#else
>csrwmtvec, t0
> +#endif
> 
>  	/* mask all interrupts */

> +#ifdef CONFIG_RISCV_SMODE
> +  csrwsie, zero
> +#else
>csrwmie, zero
> +#endif
> 
>  	/* Enable cache */

>jal icache_enable
> @@ -164,7 +172,11 @@ fix_rela_dyn:
>  */
>la  t0, trap_entry
>add t0, t0, t6
> +#ifdef CONFIG_RISCV_SMODE
> +  csrwstvec, t0
> +#else
>csrwmtvec, t0
> +#endif
> 
>  clear_bss:

>la  t0, __bss_start /* t0 <- rel __bss_start in FLASH
> */
> @@ -236,17 +248,34 @@ trap_entry:
>SREGx29, 29*REGBYTES(sp)
>SREGx30, 30*REGBYTES(sp)
>SREGx31, 31*REGBYTES(sp)
> +#ifdef CONFIG_RISCV_SMODE
> +  csrra0, scause
> +  csrra1, sepc
> +#else
>csrra0, mcause
>csrra1, mepc
> +#endif
>mv  a2, sp
>jal handle_trap
> +#ifdef CONFIG_RISCV_SMODE
> +  csrwsepc, a0
> +#else
>csrwmepc, a0
> +#endif
> 
> +#ifdef CONFIG_RISCV_SMODE

> +/*
> + * Remain in S-mode after sret
> + */
> +  li  t0, SSTATUS_SPP
> +  csrssstatus, t0
> +#else
>  /*
>   * Remain in M-mode after mret
>   */
>li  t0, MSTATUS_MPP
>csrsmstatus, t0
> +#endif
>LREGx1, 1*REGBYTES(sp)
>LREGx2, 2*REGBYTES(sp)
>LREGx3, 3*REGBYTES(sp)
> @@ -279,4 +308,8 @@ trap_entry:
>LREGx30, 30*REGBYTES(sp)
>LREGx31, 31*REGBYTES(sp)
>addisp, sp, 32*REGBYTES
> +#ifdef CONFIG_RISCV_SMODE
> +  sret
> +#else
>mret
> +#endif

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Palmer Dabbelt]

On Tue, 20 Nov 2018 19:41:10 PST (-0800), a...@brainfault.org wrote:

This patch adds kconfig option RISCV_SMODE to run u-boot in
S-mode. When this opition is enabled we use s CSRs instead
of m CSRs.

It is important to note that there is no equivalent S-mode CSR
for misa and mhartid CSRs so we expect M-mode runtime firmware
(BBL or equivalent) to emulate misa and mhartid CSR read.

In-future, we will have more patches to avoid accessing misa and
mhartid CSRs from S-mode.


Ya, I don't like this.  Our current boot protocol puts mhartid in a1 upon 
entering the supervisor, and allows the detection of misa via a device tree 
pointer provided in a0.  

As long as everyone agrees this isn't what we're actually looking for then I'm 
fine with the patch, I just don't want to end up requiring this "M mode 
emulates some CSRs for S mode" interface.  Since we don't have an actual 
platform spec we've got to be careful to avoid a bunch of defacto interfaces 
that we'll need to support later.




Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---
 arch/riscv/Kconfig |  5 +
 arch/riscv/cpu/start.S | 33 +
 2 files changed, 38 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 3e0af55e71..8f2139ff60 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -55,6 +55,11 @@ config RISCV_ISA_C
 config RISCV_ISA_A
def_bool y

+config RISCV_SMODE
+   bool "Run in S-Mode"
+   help
+ Enable this option to build an U-Boot for RISC-V S-Mode
+
 config 32BIT
bool

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 5af189b338..e4276e8e19 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -39,10 +39,18 @@ _start:
mv  s1, a1

la  t0, trap_entry
+#ifdef CONFIG_RISCV_SMODE
+   csrwstvec, t0
+#else
csrwmtvec, t0
+#endif

/* mask all interrupts */
+#ifdef CONFIG_RISCV_SMODE
+   csrwsie, zero
+#else
csrwmie, zero
+#endif

/* Enable cache */
jal icache_enable
@@ -164,7 +172,11 @@ fix_rela_dyn:
 */
la  t0, trap_entry
add t0, t0, t6
+#ifdef CONFIG_RISCV_SMODE
+   csrwstvec, t0
+#else
csrwmtvec, t0
+#endif

 clear_bss:
la  t0, __bss_start /* t0 <- rel __bss_start in FLASH */
@@ -236,17 +248,34 @@ trap_entry:
SREGx29, 29*REGBYTES(sp)
SREGx30, 30*REGBYTES(sp)
SREGx31, 31*REGBYTES(sp)
+#ifdef CONFIG_RISCV_SMODE
+   csrra0, scause
+   csrra1, sepc
+#else
csrra0, mcause
csrra1, mepc
+#endif
mv  a2, sp
jal handle_trap
+#ifdef CONFIG_RISCV_SMODE
+   csrwsepc, a0
+#else
csrwmepc, a0
+#endif

+#ifdef CONFIG_RISCV_SMODE
+/*
+ * Remain in S-mode after sret
+ */
+   li  t0, SSTATUS_SPP
+   csrssstatus, t0
+#else
 /*
  * Remain in M-mode after mret
  */
li  t0, MSTATUS_MPP
csrsmstatus, t0
+#endif
LREGx1, 1*REGBYTES(sp)
LREGx2, 2*REGBYTES(sp)
LREGx3, 3*REGBYTES(sp)
@@ -279,4 +308,8 @@ trap_entry:
LREGx30, 30*REGBYTES(sp)
LREGx31, 31*REGBYTES(sp)
addisp, sp, 32*REGBYTES
+#ifdef CONFIG_RISCV_SMODE
+   sret
+#else
mret
+#endif

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot