|
Re: Public review of Supervisor Binary Interface (SBI) Specification
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
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
|
By
Andrew Waterman
·
#1649
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
HI Andrew,
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
HI Andrew,
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
|
By
Anup Patel
·
#1648
·
|
|
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
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
|
By
Andrew Waterman
·
#1647
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.
I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.
|
By
Andrew Waterman
·
#1646
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
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
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
|
By
Sunil V L
·
#1645
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
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
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
|
By
Sunil V L
·
#1644
·
|
|
Re: Review request: New EFI_RISCV_BOOT_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
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
|
By
atishp@...
·
#1643
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
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
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
|
By
Jonathan Behrens <behrensj@...>
·
#1642
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
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
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
|
By
atishp@...
·
#1641
·
|
|
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
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
|
By
Paul Donahue
·
#1640
·
|
|
[PATCH] Remove stoptime requirement
Signed-off-by: Paul Donahue <pdonahue@...>
---
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
Signed-off-by: Paul Donahue <pdonahue@...>
---
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
|
By
Paul Donahue
·
#1639
·
|
|
Re: Public review of Supervisor Binary Interface (SBI) Specification
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,
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,
|
By
Jonathan Behrens <behrensj@...>
·
#1638
·
|
|
Public review of Supervisor Binary Interface (SBI) Specification
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
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
|
By
atishp@...
·
#1637
·
|
|
[PATCH] Updated PCIe sections 4.7.3.4 and 4.7.3.5
As discussed on the mailing list:
- 4.7.3.4
- Fixed typo
- Added clarification for requests with NS=1, RO=0
- 4.7.3.5
- Added topology depicting a RP, RCiEP, RCEC on the root bus
- Removed
As discussed on the mailing list:
- 4.7.3.4
- Fixed typo
- Added clarification for requests with NS=1, RO=0
- 4.7.3.5
- Added topology depicting a RP, RCiEP, RCEC on the root bus
- Removed
|
By
Mayuresh Chitale
·
#1636
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
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
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
|
By
Sunil V L
·
#1635
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
<abner.chang@...> wrote:
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.
<abner.chang@...> wrote:
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.
|
By
atishp@...
·
#1634
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
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
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
|
By
Heinrich Schuchardt
·
#1633
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
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.
We don't really need to merge the entire protocol to the UEFI spec.
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.
We don't really need to merge the entire protocol to the UEFI spec.
|
By
Sunil V L
·
#1632
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
Sure, Abner. Makes sense. Let me update the spec.
Thanks
Sunil
Sure, Abner. Makes sense. Let me update the spec.
Thanks
Sunil
|
By
Sunil V L
·
#1631
·
|
|
Re: Review request: New EFI_RISCV_BOOT_PROTOCOL
Hi Heinrich,
Thank you very much for your constant feedback and pointers while
drafting this spec.
This makes perfect sense. Will update the spec.
Jessica has given an input to change the
Hi Heinrich,
Thank you very much for your constant feedback and pointers while
drafting this spec.
This makes perfect sense. Will update the spec.
Jessica has given an input to change the
|
By
Sunil V L
·
#1630
·
|