|
[PATCH] UEFI: Add RISCV_EFI_BOOT_PROTOCOL requirement
RISC-V UEFI systems need to support new RISCV_BOOT_PROTOCOL.
This protocol is required to communicate the boot hart ID
from firmware to the bootloader/kernel.
This protocol specification is
RISC-V UEFI systems need to support new RISCV_BOOT_PROTOCOL.
This protocol is required to communicate the boot hart ID
from firmware to the bootloader/kernel.
This protocol specification is
|
By
Sunil V L
·
#1670
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
There was no need for any extension specific return value yet. I doubt if we will need one
in the future.
To reduce ambiguity, how about this change:
"Returns 0 if the given SBI extension ID (EID)
There was no need for any extension specific return value yet. I doubt if we will need one
in the future.
To reduce ambiguity, how about this change:
"Returns 0 if the given SBI extension ID (EID)
|
By
atishp@...
·
#1669
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Why should the value be implementation specific and not extension specific?
I would prefer if the specification would provide extension specific unique return values instead of introducing ambiguity
Why should the value be implementation specific and not extension specific?
I would prefer if the specification would provide extension specific unique return values instead of introducing ambiguity
|
By
Heinrich Schuchardt
·
#1668
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Sounds good to me as well. I will make the change.
Sounds good to me as well. I will make the change.
|
By
atishp@...
·
#1667
·
|
|
Introduction Update and OS-A Motivation
Hi All,
I submitted a pull request to the platform spec repo: https://github.com/riscv/riscv-platform-specs/pull/75 This is definitely a WIP, but I wanted to start the conversation. Much of the
Hi All,
I submitted a pull request to the platform spec repo: https://github.com/riscv/riscv-platform-specs/pull/75 This is definitely a WIP, but I wanted to start the conversation. Much of the
|
By
Aaron Durbin
·
#1666
·
|
|
Re: Specifying Cache Granule Size in Platform
Are we or will we be using any benchmarks here?
I worry that this is based on experience. Workloads have evolved.
Things like traversing workloads (hadoop, cpu encrypt, cpu compress, ...) and sparse
Are we or will we be using any benchmarks here?
I worry that this is based on experience. Workloads have evolved.
Things like traversing workloads (hadoop, cpu encrypt, cpu compress, ...) and sparse
|
By
mark
·
#1665
·
|
|
Re: Specifying Cache Granule Size in Platform
Hi all,
A few comments to add on here:
- The expectation in the CMO group was that there *could* be different cache block sizes for different operations. As Aaron points out, one may have one block
Hi all,
A few comments to add on here:
- The expectation in the CMO group was that there *could* be different cache block sizes for different operations. As Aaron points out, one may have one block
|
By
David Kruckemyer
·
#1664
·
|
|
Specifying Cache Granule Size in Platform
Hi All,
During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to
Hi All,
During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to
|
By
Aaron Durbin
·
#1663
·
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
The RVA22S64 ISA profile will provide all that detail. An 2022 OS-A platform spec will simply mandate the RVA22S64 profile.
Greg
The RVA22S64 ISA profile will provide all that detail. An 2022 OS-A platform spec will simply mandate the RVA22S64 profile.
Greg
|
By
Greg Favor
·
#1662
·
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Hi Greg,
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each
Hi Greg,
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each
|
By
Michael Frank
·
#1661
·
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA
That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA
|
By
Greg Favor
·
#1660
·
|
|
Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
Could you explain in what way you think it is wrong?
I disagree; I think the parenthetical comment is unnecessary in the
normative text.
The first portion is explicit in the privileged
Could you explain in what way you think it is wrong?
I disagree; I think the parenthetical comment is unnecessary in the
normative text.
The first portion is explicit in the privileged
|
By
Darius Rad
·
#1659
·
|
|
Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
All,
Recently a PR was sent out to remove U and VU mode standardization from the platform spec scope. Which is sort of right and sort of wrong.
I brought this issue up with Krste and Andrew
All,
Recently a PR was sent out to remove U and VU mode standardization from the platform spec scope. Which is sort of right and sort of wrong.
I brought this issue up with Krste and Andrew
|
By
Greg Favor
·
#1658
·
|
|
Next Platform HSC Meeting on Mon Jan 24th 2022 8AM PST
Hi All,
The next platform HSC meeting is scheduled on Mon Jan 24th 2022 at 8AM PST.
Here are the details:
Agenda and minutes kept on the github
Hi All,
The next platform HSC meeting is scheduled on Mon Jan 24th 2022 at 8AM PST.
Here are the details:
Agenda and minutes kept on the github
|
By
Kumar Sankaran
·
#1657
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Thank you for your reply
By
merle w
·
#1656
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
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
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
|
By
atishp@...
·
#1655
·
|
|
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
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
|
By
merle w
·
#1654
·
|
|
Re: [PATCH] Remove stoptime requirement
Hi Paul,
Can you send a PR please?
Regards
Kumar
Hi Paul,
Can you send a PR please?
Regards
Kumar
|
By
Kumar Sankaran
·
#1653
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Indeed. I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).
Indeed. I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).
|
By
Andrew Waterman
·
#1652
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
Hi Andrew,
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
Hi Andrew,
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
|
By
Anup Patel
·
#1651
·
|