|
Next Platform HSC Meeting on Mon Jan 24th 2022 8AM PST
Kumar Sankaran
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
On Thu, Jan 20, 2022 at 6:23 PM <merlew4n6@...> wrote:
3.4. Function: Probe SBI extension (FID #3)
struct sbiret sbi_probe_extension(long extension_id);
Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero
value if it is available.
Do we need to add more fine-grained detection to check if a certain funcid is available
That won't be required as the specification clearly states that "SBI extensions as whole are optional but they shall not be partially implemented. If sbi_probe_extension() signals that an extension is available, all functions present in the SBI version reported by sbi_get_spec_version() must conform to that version of the SBI specification."
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
3.4. Function: Probe SBI extension (FID #3)
struct sbiret sbi_probe_extension(long extension_id);
Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero
value if it is available.
Do we need to add more fine-grained detection to check if a certain funcid is available
|
|
|
Re: [PATCH] Remove stoptime requirement
Kumar Sankaran
Hi Paul, Can you send a PR please? Regards Kumar
From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Paul Donahue
Sent: Wednesday, January 12, 2022 11:49 AM
To: tech-unixplatformspec <tech-unixplatformspec@...>
Subject: [RISC-V] [tech-unixplatformspec] [PATCH] Remove stoptime requirement ---
riscv-platform-spec.adoc | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 238af3a..7a02b76 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -261,8 +261,7 @@ and one resume group (in addition to group 0)
- dcsr.stepie must support the 0 setting. It is optional to support the 1
setting
* Rationale: It is not generally useful to step into interrupt handlers.
-- dcsr.stopcount and dcsr.stoptime must be supported and the reset value of
-each must be 1
+- dcsr.stopcount must be supported and the reset value must be 1
* Rationale: The architecture has strict requirements on minstret which may
be perturbed by an external debugger in a way that's visible to software.
The default should allow code that's sensitive to these requirements to be
--
2.21.0
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
On Wed, Jan 19, 2022 at 3:10 AM Anup Patel < apatel@...> wrote: Hi Andrew,
On Wed, Jan 19, 2022 at 11:38 AM Andrew Waterman <andrew@...> wrote:
>
>
>
> On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:
>>
>> HI Andrew,
>>
>> On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
>> >
>> > Hi Atish,
>> >
>> > I've got some minor feedback from the Architecture Review committee:
>> >
>> > We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
>>
>> The RV32 physical address space limitation only impacts SBI RFENCE
>> calls and SBI HSM calls. A RV32 system can still use these calls as
>> long as their physical address space is within 4GB.
>>
>> I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
>> chapters for SBI v1.0 and plan to address this in SBI v2.0.
>
>
> It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them. So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.
I mostly agree with your suggestion considering the fact that we have
very few (or none) RV32 Linux (or RichOS) capable systems.
Indeed. I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).
I would also like to correct my previous comment about the RV32
limitation. The RV32 limitation only affects SBI HSM and does not
affect any other SBI extension (including SBI RFENCE) because SBI
RFENCE calls take virtual address as "unsigned long" parameter. In
other words, on a RV32 system the SBI HSM start and suspend calls will
need a physical address within the 4GB address range.
Regards,
Anup
>
>>
>> >
>> > It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
>>
>> I agree with this suggestion. We got this question multiple times in
>> the past as well.
>
>
> Cool, thanks!
>
>>
>>
>> Regards,
>> Anup
>>
>> >
>> > Thanks,
>> > Andrew
>> >
>> > On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
>> >>
>> >> I just realized that the below email was not delivered to unix
>> >> platform mailing list and
>> >> linux-riscv mailing list because of the attachment. Reseeding it again
>> >> without the
>> >> attachment. Apologies for the noise.
>> >>
>> >> -----------------------------------------------------------------------------------------------
>> >> We are delighted to announce the start of the public review period for
>> >> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> >> SBI specification is considered as frozen now as per the RISC-V International
>> >> policies.
>> >>
>> >> The review period begins today, Monday Jan 10, and ends on Monday
>> >> Jan 24 (inclusive).
>> >>
>> >> The specification can be found here
>> >> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>> >>
>> >> which was generated from the source available in the following GitHub
>> >> repository:
>> >> https://github.com/riscv-non-isa/riscv-sbi-doc
>> >>
>> >> To respond to the public review, please either reply to this email or
>> >> send comments to the platform mailing list[1] or add issues to the
>> >> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> >> effort in helping us by reviewing the specification.
>> >>
>> >> During the public review period, corrections, comments, and
>> >> suggestions, will be gathered for review by the Platform HSC members. Any
>> >> minor corrections and/or uncontroversial changes will be incorporated
>> >> into the specification. Any remaining issues or proposed changes will
>> >> be addressed in the public review summary report. If there are no
>> >> issues that require incompatible changes to the public review
>> >> specification, the platform HSC will recommend the updated
>> >> specifications be approved and ratified by the RISC-V Technical
>> >> Steering Committee and the RISC-V Board of Directors.
>> >>
>> >> SBI specification is non-ISA specifications and will evolve over time
>> >> with new extensions as long as they are backward compatible. Any such
>> >> proposals for new extensions can be included in the future releases
>> >> after proper discussions in the platform working group meetings.
>> >>
>> >> Thanks to all the contributors for all their hard work.
>> >>
>> >> [1] tech-unixplatformspec@...
>> >> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>> >>
>> >> Regards,
>> >> Atish Patra
>> >>
>> >>
>> >>
>> >>
>> >>
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Anup Patel
Hi Andrew, On Wed, Jan 19, 2022 at 11:38 AM Andrew Waterman <andrew@...> wrote:
On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:
HI Andrew,
On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
Hi Atish,
I've got some minor feedback from the Architecture Review committee:
We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.
I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.
It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them. So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.
I mostly agree with your suggestion considering the fact that we have very few (or none) RV32 Linux (or RichOS) capable systems. I would also like to correct my previous comment about the RV32 limitation. The RV32 limitation only affects SBI HSM and does not affect any other SBI extension (including SBI RFENCE) because SBI RFENCE calls take virtual address as "unsigned long" parameter. In other words, on a RV32 system the SBI HSM start and suspend calls will need a physical address within the 4GB address range. Regards, Anup
It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in
the past as well.
Cool, thanks!
Regards,
Anup
Thanks,
Andrew
On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.
-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.
The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).
The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc
To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.
During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.
SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.
Thanks to all the contributors for all their hard work.
[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
Regards,
Atish Patra
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
On Tue, Jan 18, 2022 at 10:08 PM Andrew Waterman <andrew@...> wrote:
On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:
HI Andrew,
On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
Hi Atish,
I've got some minor feedback from the Architecture Review committee:
We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.
I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.
It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them. So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.
Sure. Here is the proposed diff that removed all the references to RV32 in the specification. Is it a common practice to explicitly specify in the specification that only the RV64 version is ratified ? We can add it to the release notes. Please let me know if there are any other places it should be specified. ------------------------------------------------------------------------------------------------------------- diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index be753a596837..09061e5e4b3b 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -90,7 +90,7 @@ function calls except that: * An `ECALL` is used as the control transfer instruction instead of a `CALL` instruction. -* `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (*EID*), +* `a7` encodes the SBI extension ID (*EID*), which matches how the system call ID is encoded in Linux system call ABI. Many SBI extensions also chose to encode an additional SBI function ID (*FID*) @@ -136,9 +136,9 @@ An `ECALL` with an unsupported SBI extension ID (*EID*) or an unsupported SBI function ID (*FID*) must return the error code `SBI_ERR_NOT_SUPPORTED`. Every SBI function should prefer `unsigned long` as the data type. It keeps -the specification simple and easily adaptable for all RISC-V ISA types (i.e. -RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher -privilege software must ensure that it only uses 32 bit data only. +the specification simple and easily adaptable for all RISC-V ISA types. +In case the data is defined as 32bit wide, higher privilege software must +ensure that it only uses 32 bit data only. If an SBI function needs to pass a list of harts to the higher privilege mode, it must use a hart mask as defined below. This is applicable to any extensions @@ -977,7 +977,7 @@ shown in <<table_hsm_hart_suspend_types>> below. | 0x80000000 | Default non-retentive suspend | 0x80000001 - 0x8FFFFFFF | Reserved for future use | 0x90000000 - 0xFFFFFFFF | Platform specific non-retentive suspend -| > 0xFFFFFFFF | Reserved (and non-existent on RV32) +| > 0xFFFFFFFF | Reserved |=== The `resume_addr` parameter points to a runtime-specified physical address, @@ -1051,7 +1051,7 @@ in the <<table_srst_system_reset_types>> below. | 0x00000002 | Warm reboot | 0x00000003 - 0xEFFFFFFF | Reserved for future use | 0xF0000000 - 0xFFFFFFFF | Vendor or platform specific reset type -| > 0xFFFFFFFF | Reserved (and non-existent on RV32) +| > 0xFFFFFFFF | Reserved |=== The `reset_reason` is an optional parameter representing the reason for @@ -1068,7 +1068,7 @@ in the <<table_srst_system_reset_reasons>> below | 0x00000002 - 0xDFFFFFFF | Reserved for future use | 0xE0000000 - 0xEFFFFFFF | SBI implementation specific reset reason | 0xF0000000 - 0xFFFFFFFF | Vendor or platform specific reset reason -| > 0xFFFFFFFF | Reserved (and non-existent on RV32) +| > 0xFFFFFFFF | Reserved |=== -------------------------------------------------------------------------------------------------------------
It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in
the past as well.
I will send a separate patch for this.
Cool, thanks!
Regards,
Anup
Thanks,
Andrew
On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.
-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.
The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).
The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc
To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.
During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.
SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.
Thanks to all the contributors for all their hard work.
[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
Regards,
Atish Patra
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
On Tue, Jan 18, 2022 at 7:48 PM Anup Patel < apatel@...> wrote: HI Andrew,
On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
>
> Hi Atish,
>
> I've got some minor feedback from the Architecture Review committee:
>
> We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.
I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.
It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them. So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.
>
> It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in
the past as well.
Cool, thanks!
Regards,
Anup
>
> Thanks,
> Andrew
>
> On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Anup Patel
HI Andrew, On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
Hi Atish,
I've got some minor feedback from the Architecture Review committee:
We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE calls and SBI HSM calls. A RV32 system can still use these calls as long as their physical address space is within 4GB. I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM chapters for SBI v1.0 and plan to address this in SBI v2.0.
It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in the past as well. Regards, Anup
Thanks,
Andrew
On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.
-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.
The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).
The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc
To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.
During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.
SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.
Thanks to all the contributors for all their hard work.
[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
Regards,
Atish Patra
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Hi Atish,
I've got some minor feedback from the Architecture Review committee:
We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
Thanks, Andrew
On Wed, Jan 12, 2022 at 10:43 AM < atishp@...> wrote: I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.
-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.
The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).
The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc
To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.
During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.
SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.
Thanks to all the contributors for all their hard work.
[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
Regards,
Atish Patra
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
On Wed, Jan 12, 2022 at 12:50 PM Jonathan Behrens < behrensj@...> wrote: If that is the intention, the text should be changed to "Returns 0 if the given SBI extension ID (EID) is not available, or an implementation defined non-zero value if it is available". Although, if the extensions aren't defining any meaning to the various possible non-zero values, I personally don't see why we shouldn't change it to "returns one if it is available".
I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.
On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra < atishp@...> wrote: On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
>
> If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
>
The description says "Returns 0 if the given SBI extension ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.
> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>
|
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On Thu, Jan 13, 2022 at 10:13:04AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Sunil V L <sunilvl@...>
Sent: Thursday, January 13, 2022 5:48 PM
To: Atish Kumar Patra <atishp@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
Heinrich Schuchardt <xypron.glpk@...>; Heinrich Schuchardt
<heinrich.schuchardt@...>; tech-
unixplatformspec@...; Anup Patel <apatel@...>;
Jessica Clarke <jrtc27@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Review request: New
EFI_RISCV_BOOT_PROTOCOL
On Wed, Jan 12, 2022 at 05:53:15PM -0800, Atish Kumar Patra wrote:
On Wed, Jan 12, 2022 at 12:04 AM Sunil V L <sunilvl@...> wrote:
On Tue, Jan 11, 2022 at 12:48:16PM -0800, Atish Kumar Patra wrote:
On Mon, Jan 10, 2022 at 11:57 PM Chang, Abner (HPS SW/FW
Technologist)
<abner.chang@...> wrote:
-----Original Message-----
From: Heinrich Schuchardt <xypron.glpk@...>
Sent: Tuesday, January 11, 2022 3:50 PM
To: Sunil V L <sunilvl@...>; Chang, Abner (HPS
SW/FW
Technologist) <abner.chang@...>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...>;
tech-
unixplatformspec@...; Anup Patel
<apatel@...>;
Atish Patra <atishp@...>; Jessica Clarke
<jrtc27@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Review request: New
EFI_RISCV_BOOT_PROTOCOL
On 1/11/22 07:02, Sunil V L wrote:
On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS
SW/FW
Technologist) wrote:
-----Original Message-----
From: Heinrich Schuchardt
<heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra
<atishp@...>;
Jessica
Clarke <jrtc27@...>; Sunil V L
<sunilvl@...>
Subject: Re: Review request: New
EFI_RISCV_BOOT_PROTOCOL
On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist)
wrote:
Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL
specifically, I
suggest to have a RISC-V EFI Protocols Specification. This spec
accommodates
EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-
V
platform,
and those we had implemented in edk2.
Which protocols in EDK II do you refer to?
"git grep -n RISC edk2/ | grep PRO" yields no result. Oops... RiscVEdk2Sbi was implemented as library for now and
the plan is
to rap it as PPI/protocol, bad memory.
Even if there are no other RISC-V protocols today, Abner's
suggestion
will allow us to add them in future to the same document.
Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we
should
create
an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification. I don't think this would be accepted by UEFI forum. This is RISC-V
specific
protocol however, UEFI protocol is the abstract interface for
platform and
architecture. Unless you can come out a abstract interface that can
accommodate different processor/platform architectures (if they
also need
this).
We don't really need to merge the entire protocol to the UEFI
spec. We
need to maintain this within RISC-V organization like other RISC-V
specs
and add as a requirement in the platform spec. We can probably
add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be
better
since we do not need to update the UEFI spec for any new
protocols
specific to RISC-V in future.
What do you think? Do you see any issue with this approach? The TCG2 protocol is only a UEFI extension (see UEFI spec 2.9, p.68)
and
not required to claim UEFI compatibility.
If you put a protocol into the UEFI specification, you can be sure that
EDK II will implement it. And not firmware can claim to be UEFI
compliant without it. To spec out something in either UEFI or RISC-V specific spec is actually
the same to RISC-V edk2 port IMO, if those are the mandatory protocols.
Edk2 RISC-V port should compliant with the firmware spec defined by
either specs, unless the spec says the protocol is specifically to uboot but it is
optional for other firmware solutions.
I think it would be better to enforce the mandatory requirement
explicitly in the UEFI spec. The actual content of the protocol can be
hosted under RISC-V.
Hi All,
I think I have addressed your comments. Please take a look at
https://github.com/riscv-non-isa/riscv-
uefi/releases/download/0.2/EFI_RISCV_PROTOCOL-spec.pdf.
If you think it is fine, I plan to get it reviewed once with Ard and
linux-riscv also where this solution was proposed originally.
We may not be able to add to mandatory UEFI section 2.6.1 but we can
try adding to 2.6.2 and mandate it via platform spec like we do for
PCI protocol.
Sounds good. One minor comment:
"While there can be a solution using /chosen node in DT based systems
to pass this information, a simple and common interface across DT and
ACPI platforms is desired on UEFI platforms to retrieve such
information."
The following statement should be improved to indicate that /chosen
node is an existing solution. However, it will not work for ACPI.
EFI_RISCV_BOOT_PROTOCOL should be the preferred over /chosen node
option for both DT/ACPI platforms.
Thanks. Updated as per your suggestion.
https://github.com/riscv-non-isa/riscv-
uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf
I will work with you, Heinrich and Abner to get an codefirst ECR to
USWG. We still need ECR?
The "codefirst" is to have the implementation first then submit the ECR for the new UEFI protocol.
However, we are not going to propose any protocols to UEFI spec. Even don't need to add a sentence for the external reference to this new document. To add the requirement in the platform spec is the perfect match IMO.
Hi Abner, We need to add this requirement in the platform spec for sure. I will send the patch once this is frozen. But I think we also need to update the UEFI section 2.3.7.1 since it already talks about the DT node, correct? In addition, we can try adding this to 2.6.2 like other optional protocols. I am not very sure whether USWG will agree for this. But at the minimum if 2.3.7.1 can be updated. Thanks Sunil Abner
Atish, should this be added to EBBR also?
Yeah. RISC-V Multiprocessor Startup Protocol should be updated.
EFI_RISCV_BOOT_PROTOCOL should be preferred first. In absence of this,
firmware must
provide the /chosen hartid for the DT based platforms.
I guess you don't need to update EBBR right away. Once this is
accepted in the UEFI forum, EBBR can be updated.
Sure.
Thanks
Sunil
Thanks
Sunil
Regards,
Abner
I would prefer if every UEFI protocol that is absolutely essential for
booting were required by the UEFI specification. If the details are
maintained inside the UEFI specification or outside, does not matter
to me.
Best regards
Heirnich
Thanks
Sunil
Regards,
Abner
Best regards
Heinrich
Thanks
Abner
-----Original Message-----
From: Heinrich Schuchardt
<heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner
(HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra
<atishp@...>;
Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New
EFI_RISCV_BOOT_PROTOCOL
On 1/10/22 18:02, Sunil V L wrote:
Hi All,
As we discussed in the Platform HSC meeting today, here is
the
document
which details a new RISC-V specific EFI protocol.
https://github.com/riscv-non-isa/riscv-
uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf
Currently, the main use case of this protocol is to pass the
boot
hartid to
the OS. But this can be extended in future if required. A PoC
has been
developed using EDK2 and Linux.
More details of this requirement and alternatives discussed
are
available
at
http://lists.infradead.org/pipermail/linux-riscv/2021-
December/010604.html.
I request your review and will be great if you provide the
feedback
by
01/17.
Thanks!
Sunil
Dear Sunil,
thank you for drafting the protocol specification.
The interface of a protocol may change from version to
version.
Therefore I understand why there must be a path to convey
this
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes
accessing
this
information unnecessarily complicated. Instead consider
adding a
version
field as first element of the interface like many other UEFI
protocols
do. This will also decrease the implementation size. For
alignment
reasons make this field UINT64. Other protocols call such a
field
"Revision". Please, provide a define for the current version.
E.g.
#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION
Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId()
looks ok to
me
and is
well described.
Best regards
Heinrich
|
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On Wed, Jan 12, 2022 at 05:53:15PM -0800, Atish Kumar Patra wrote: On Wed, Jan 12, 2022 at 12:04 AM Sunil V L <sunilvl@...> wrote:
On Tue, Jan 11, 2022 at 12:48:16PM -0800, Atish Kumar Patra wrote:
On Mon, Jan 10, 2022 at 11:57 PM Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...> wrote:
-----Original Message-----
From: Heinrich Schuchardt <xypron.glpk@...>
Sent: Tuesday, January 11, 2022 3:50 PM
To: Sunil V L <sunilvl@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...>; tech-
unixplatformspec@...; Anup Patel <apatel@...>;
Atish Patra <atishp@...>; Jessica Clarke <jrtc27@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Review request: New
EFI_RISCV_BOOT_PROTOCOL
On 1/11/22 07:02, Sunil V L wrote:
On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;
Jessica
Clarke <jrtc27@...>; Sunil V L <sunilvl@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:
Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I
suggest to have a RISC-V EFI Protocols Specification. This spec
accommodates
EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V
platform,
and those we had implemented in edk2.
Which protocols in EDK II do you refer to?
"git grep -n RISC edk2/ | grep PRO" yields no result. Oops... RiscVEdk2Sbi was implemented as library for now and the plan is
to rap it as PPI/protocol, bad memory.
Even if there are no other RISC-V protocols today, Abner's suggestion
will allow us to add them in future to the same document.
Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should
create
an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification. I don't think this would be accepted by UEFI forum. This is RISC-V specific
protocol however, UEFI protocol is the abstract interface for platform and
architecture. Unless you can come out a abstract interface that can
accommodate different processor/platform architectures (if they also need
this).
We don't really need to merge the entire protocol to the UEFI spec. We
need to maintain this within RISC-V organization like other RISC-V specs
and add as a requirement in the platform spec. We can probably add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be better
since we do not need to update the UEFI spec for any new protocols
specific to RISC-V in future.
What do you think? Do you see any issue with this approach? The TCG2 protocol is only a UEFI extension (see UEFI spec 2.9, p.68) and
not required to claim UEFI compatibility.
If you put a protocol into the UEFI specification, you can be sure that
EDK II will implement it. And not firmware can claim to be UEFI
compliant without it. To spec out something in either UEFI or RISC-V specific spec is actually the same to RISC-V edk2 port IMO, if those are the mandatory protocols.
Edk2 RISC-V port should compliant with the firmware spec defined by either specs, unless the spec says the protocol is specifically to uboot but it is optional for other firmware solutions.
I think it would be better to enforce the mandatory requirement
explicitly in the UEFI spec. The actual content of the protocol can be
hosted under RISC-V. Hi All,
I think I have addressed your comments. Please take a look at
https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.2/EFI_RISCV_PROTOCOL-spec.pdf.
If you think it is fine, I plan to get it reviewed once with Ard and
linux-riscv also where this solution was proposed originally.
We may not be able to add to mandatory UEFI section 2.6.1 but we can
try adding to 2.6.2 and mandate it via platform spec like we do for
PCI protocol.
Sounds good. One minor comment:
"While there can be a solution using /chosen node in DT based systems
to pass this information, a simple and common interface across DT and
ACPI platforms is desired on UEFI platforms to retrieve such
information."
The following statement should be improved to indicate that /chosen
node is an existing solution. However, it will not work for ACPI.
EFI_RISCV_BOOT_PROTOCOL should be the preferred over /chosen node
option for both DT/ACPI platforms. Thanks. Updated as per your suggestion. https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdfI will work with you, Heinrich and Abner to get an codefirst ECR to USWG.
Atish, should this be added to EBBR also?
Yeah. RISC-V Multiprocessor Startup Protocol should be updated.
EFI_RISCV_BOOT_PROTOCOL should be preferred first. In absence of this,
firmware must
provide the /chosen hartid for the DT based platforms.
I guess you don't need to update EBBR right away. Once this is
accepted in the UEFI forum, EBBR can be updated.
Sure. Thanks Sunil
Thanks
Sunil
Regards,
Abner
I would prefer if every UEFI protocol that is absolutely essential for
booting were required by the UEFI specification. If the details are
maintained inside the UEFI specification or outside, does not matter to me.
Best regards
Heirnich
Thanks
Sunil
Regards,
Abner
Best regards
Heinrich
Thanks
Abner
-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;
Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On 1/10/22 18:02, Sunil V L wrote:
Hi All,
As we discussed in the Platform HSC meeting today, here is the
document
which details a new RISC-V specific EFI protocol.
https://github.com/riscv-non-isa/riscv-
uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf
Currently, the main use case of this protocol is to pass the boot
hartid to
the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.
More details of this requirement and alternatives discussed are
available
at
http://lists.infradead.org/pipermail/linux-riscv/2021-
December/010604.html.
I request your review and will be great if you provide the feedback
by
01/17.
Thanks!
Sunil
Dear Sunil,
thank you for drafting the protocol specification.
The interface of a protocol may change from version to version.
Therefore I understand why there must be a path to convey this
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing
this
information unnecessarily complicated. Instead consider adding a
version
field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.
#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION
Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to
me
and is
well described.
Best regards
Heinrich
|
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On Wed, Jan 12, 2022 at 12:04 AM Sunil V L <sunilvl@...> wrote:
On Tue, Jan 11, 2022 at 12:48:16PM -0800, Atish Kumar Patra wrote:
On Mon, Jan 10, 2022 at 11:57 PM Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...> wrote:
-----Original Message-----
From: Heinrich Schuchardt <xypron.glpk@...>
Sent: Tuesday, January 11, 2022 3:50 PM
To: Sunil V L <sunilvl@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...>; tech-
unixplatformspec@...; Anup Patel <apatel@...>;
Atish Patra <atishp@...>; Jessica Clarke <jrtc27@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Review request: New
EFI_RISCV_BOOT_PROTOCOL
On 1/11/22 07:02, Sunil V L wrote:
On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;
Jessica
Clarke <jrtc27@...>; Sunil V L <sunilvl@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:
Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I
suggest to have a RISC-V EFI Protocols Specification. This spec
accommodates
EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V
platform,
and those we had implemented in edk2.
Which protocols in EDK II do you refer to?
"git grep -n RISC edk2/ | grep PRO" yields no result. Oops... RiscVEdk2Sbi was implemented as library for now and the plan is
to rap it as PPI/protocol, bad memory.
Even if there are no other RISC-V protocols today, Abner's suggestion
will allow us to add them in future to the same document.
Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should
create
an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification. I don't think this would be accepted by UEFI forum. This is RISC-V specific
protocol however, UEFI protocol is the abstract interface for platform and
architecture. Unless you can come out a abstract interface that can
accommodate different processor/platform architectures (if they also need
this).
We don't really need to merge the entire protocol to the UEFI spec. We
need to maintain this within RISC-V organization like other RISC-V specs
and add as a requirement in the platform spec. We can probably add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be better
since we do not need to update the UEFI spec for any new protocols
specific to RISC-V in future.
What do you think? Do you see any issue with this approach? The TCG2 protocol is only a UEFI extension (see UEFI spec 2.9, p.68) and
not required to claim UEFI compatibility.
If you put a protocol into the UEFI specification, you can be sure that
EDK II will implement it. And not firmware can claim to be UEFI
compliant without it. To spec out something in either UEFI or RISC-V specific spec is actually the same to RISC-V edk2 port IMO, if those are the mandatory protocols.
Edk2 RISC-V port should compliant with the firmware spec defined by either specs, unless the spec says the protocol is specifically to uboot but it is optional for other firmware solutions.
I think it would be better to enforce the mandatory requirement
explicitly in the UEFI spec. The actual content of the protocol can be
hosted under RISC-V. Hi All,
I think I have addressed your comments. Please take a look at
https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.2/EFI_RISCV_PROTOCOL-spec.pdf.
If you think it is fine, I plan to get it reviewed once with Ard and
linux-riscv also where this solution was proposed originally.
We may not be able to add to mandatory UEFI section 2.6.1 but we can
try adding to 2.6.2 and mandate it via platform spec like we do for
PCI protocol.
Sounds good. One minor comment: "While there can be a solution using /chosen node in DT based systems to pass this information, a simple and common interface across DT and ACPI platforms is desired on UEFI platforms to retrieve such information." The following statement should be improved to indicate that /chosen node is an existing solution. However, it will not work for ACPI. EFI_RISCV_BOOT_PROTOCOL should be the preferred over /chosen node option for both DT/ACPI platforms. Atish, should this be added to EBBR also?
Yeah. RISC-V Multiprocessor Startup Protocol should be updated. EFI_RISCV_BOOT_PROTOCOL should be preferred first. In absence of this, firmware must provide the /chosen hartid for the DT based platforms. I guess you don't need to update EBBR right away. Once this is accepted in the UEFI forum, EBBR can be updated. Thanks
Sunil
Regards,
Abner
I would prefer if every UEFI protocol that is absolutely essential for
booting were required by the UEFI specification. If the details are
maintained inside the UEFI specification or outside, does not matter to me.
Best regards
Heirnich
Thanks
Sunil
Regards,
Abner
Best regards
Heinrich
Thanks
Abner
-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;
Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
On 1/10/22 18:02, Sunil V L wrote:
Hi All,
As we discussed in the Platform HSC meeting today, here is the
document
which details a new RISC-V specific EFI protocol.
https://github.com/riscv-non-isa/riscv-
uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf
Currently, the main use case of this protocol is to pass the boot
hartid to
the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.
More details of this requirement and alternatives discussed are
available
at
http://lists.infradead.org/pipermail/linux-riscv/2021-
December/010604.html.
I request your review and will be great if you provide the feedback
by
01/17.
Thanks!
Sunil
Dear Sunil,
thank you for drafting the protocol specification.
The interface of a protocol may change from version to version.
Therefore I understand why there must be a path to convey this
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing
this
information unnecessarily complicated. Instead consider adding a
version
field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.
#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION
Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to
me
and is
well described.
Best regards
Heinrich
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Jonathan Behrens <behrensj@...>
If that is the intention, the text should be changed to "Returns 0 if the given SBI extension ID (EID) is not available, or an implementation defined non-zero value if it is available". Although, if the extensions aren't defining any meaning to the various possible non-zero values, I personally don't see why we shouldn't change it to "returns one if it is available".
Jonathan
On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra < atishp@...> wrote: On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
>
> If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
>
The description says "Returns 0 if the given SBI extension ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.
> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
The description says "Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero value if it is available" The specification says it should be non-zero as the value "0" indicates non-availability of the extension. The exact return value should be an implementation detail. Jonathan
On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.
-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.
The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).
The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc
To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.
During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.
SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.
Thanks to all the contributors for all their hard work.
[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
Regards,
Atish Patra
|
|
|
Re: OS-A platform stoptime requirement
I just sent a patch.
(The main reason I didn't do that sooner was that I'm not patch-savvy. I'm more familiar with pull requests which are used by all the other RISC-V specs but which are admittedly unfriendly to those with dialup connections.)
Thanks,
-Paul
On Mon, Jan 3, 2022 at 9:45 AM Atish Kumar Patra < atishp@...> wrote:
On Mon, Jan 3, 2022 at 9:43 AM Beeman Strong < beeman@...> wrote: Back to the original topic, it seems there is broad agreement that stoptime=1 shouldn't be a requirement for the OS-A (or server) platform spec. Is there a formal mechanism by which an issue should be filed to get that changed?
Send a patch :)
On Wed, Dec 29, 2021 at 9:44 AM Tim Newsome < tim@...> wrote: On Tue, Dec 28, 2021 at 4:19 PM Ved Shanbhogue < ved@...> wrote: On Tue, Dec 28, 2021 at 10:04:41AM -0800, Tim Newsome wrote:
>stoptime is nice on single-hart systems, but not really practical in
>multi-hart systems where one hart can be running while another is halted.
>The main benefit is that it allows you to single step through code with a
>timer interrupt enabled, without going into that timer interrupt every time
>you single step.
Are there downsides to the debugger inhibiting the timer interrupt by setting STIE to 0?
This seems like would provide similar benefit even for a multi-hart system...
It works fine, but it's not as nice as the system itself slowing down to your debugging speed. (Although slowing the system down will generally be imperfect in any case, because systems have other peripherals that will not stop generating interrupts/counting time/whatever.)
Tim
|
|
|
[PATCH] Remove stoptime requirement
--- riscv-platform-spec.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 238af3a..7a02b76 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -261,8 +261,7 @@ and one resume group (in addition to group 0) - dcsr.stepie must support the 0 setting. It is optional to support the 1 setting * Rationale: It is not generally useful to step into interrupt handlers. -- dcsr.stopcount and dcsr.stoptime must be supported and the reset value of -each must be 1 +- dcsr.stopcount must be supported and the reset value must be 1 * Rationale: The architecture has strict requirements on minstret which may be perturbed by an external debugger in a way that's visible to software. The default should allow code that's sensitive to these requirements to be -- 2.21.0
|
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Jonathan Behrens <behrensj@...>
If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
Jonathan
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.
-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.
The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).
The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc
To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.
During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.
SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.
Thanks to all the contributors for all their hard work.
[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
Regards,
Atish Patra
|
|
|
