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

Which protocols in EDK II do you refer to? "git grep -n RISC edk2/ | grep PRO" yields no result. Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should create an issue in

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

Hi All, As we discussed in the Platform HSC meeting today, here is the document which details a new RISC-V specific EFI

Hi All, The next platform HSC meeting is scheduled on Mon Jan 10th 2022 at 8AM PST. Here are the details: Agenda and minutes kept on the github

Agreed ! I will send a patch for this change. Ok. Will do that.

I agree the comments about RO and NS interactions are non-normative clarifications (and not required to be added, it’s covered in the PCIe spec). The key point is the the text today implies the

Fwiw, through seven generations of ARM SBSA and then the BSA, they talk about No_snoop in a similar way to what we do, but make no corresponding mentions about Relaxed Order (other than mentions of

Hi, thanks for the response. My thinking on intX is that if the HW can provide all the required MSI support, then SW won’t need to fall back to MSIs. The intent of the PCIe spec was to depricate

The intention behind requiring intx was to ensure better compatibility. There are few cases where we fallback to INTx if MSI is not available. For

Send a patch :)

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

Hello, I’m new to participating in the platform WG. I’m working at SiFive now. I spent the last 20 years doing PCIe compliant IO fabrics for Intel chipsets. I have a few comments / questions