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

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 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

I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.

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

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

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

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 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

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

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

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,

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

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

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

<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.

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

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.

Sure, Abner. Makes sense. Let me update the spec. Thanks Sunil

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