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

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

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

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

Hi Ved, Are we ready to finalize the changes after all the comments and discussions on the list of questions you had on this thread? If yes, can you send a PR for these changes please? I see the PCIe

This is platform specific address and it will break for platforms having MTIME register at some other address. Such optimizations, increasingly make a SBI implementation platform specific. This is