tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

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

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

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

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.

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

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.

By Sunil V L · #1632 ·

Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

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

By Sunil V L · #1630 ·

Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

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

By Heinrich Schuchardt · #1629 ·

Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

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

By Heinrich Schuchardt · #1628 ·

Review request: New EFI_RISCV_BOOT_PROTOCOL

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

By Sunil V L · #1627 ·

Next Platform HSC Meeting on Mon Jan 10th 2022 8AM PST

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

By Kumar Sankaran · #1626 ·

Re: OS-A PCIe Questions

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

By Mayuresh Chitale · #1625 ·

Re: OS-A PCIe Questions

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

By Michael Klinglesmith · #1624 ·

Re: OS-A PCIe Questions

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

By Greg Favor · #1623 ·

Re: OS-A PCIe Questions

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

By Michael Klinglesmith · #1622 ·

Re: OS-A PCIe Questions

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

By Mayuresh Chitale · #1621 ·

Re: OS-A platform stoptime requirement

Send a patch :)

By atishp@... · #1620 ·

Re: OS-A platform stoptime requirement

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

By Beeman Strong · #1619 ·

OS-A PCIe Questions

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

By Michael Klinglesmith · #1618 ·

221 - 240 of 1857

Home Hashtags Subgroups Terms