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

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra

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 constraint for separate ECAM region

Signed-off-by: Mayuresh Chitale <mchitale@...>
Signed-off-by: Michael Klinglesmith <michael.klinglesmith@...>
---
pcie-topology.ditaa | 30 ++++++++++++++++++++++++++++--
riscv-platform-spec.adoc | 11 ++++-------
2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/pcie-topology.ditaa b/pcie-topology.ditaa
index 7180035..3436fa9 100644
--- a/pcie-topology.ditaa
+++ b/pcie-topology.ditaa
@@ -23,6 +23,32 @@
| | | | |
+--------------------------+ +--------------------------+

+ +----------+
+ | CPU |
+ +-----+----+
+ |
+ |
+ |
+ +------------------------+-----------------------+
+ | |
+ | Root Complex |
+ | |
+ | +--------------+ |
+ | | Host Bridge | |
+ | +------+-------+ |
+ | | |
+ | Bus 0 | |
+ | +-----------------+--------------+ |
+ | | | | |
+ | | | | |
+ | +-----+-------+ +---+---+ +---+---+ |
+ | | Root Port | | RCiEP | | RCEC | |
+ | +-----+-------+ +-------+ +-------+ |
+ | | |
+ | | |
+ |Bus 1 | |
+ | | |
+ +------------------------------------------------+

- RCiEP : Root complex integrated endpoint
- RCEC : Root complex event collector
+ RCiEP - Root complex integrated endpoint
+ RCEC - Root complex event collector
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 238af3a..1244bf7 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -845,10 +845,10 @@ software can be 0x10 so that the function can use lower 4 bits to assert each
of the 16 vectors.

===== PCIe cache coherency
-Memory that is cacheable by harts is not kept coherent by hardware when PCIe
-transactions to that memory are marked with a No_Snoop bit of zero. In this
-case, software must manage coherency on such memory; otherwise, software
-coherency management is not required.
+Memory that is cacheable by harts may not be kept coherent by hardware when
+PCIe transactions to that memory are marked with a No_Snoop bit of one. On
+platforms that honour No_Snoop bit, software must manage coherency on such
+memory; otherwise, software coherency management is not required.

===== PCIe Topology
Platforms are required to implement at least one of the following topologies
@@ -906,9 +906,6 @@ In addition the following requirements must be met:
** If RCiEP is implemented then RCEC must be implemented as well. All
requirements for RCEC specified in the PCIe Base specification must be
implemented. RCEC is required to terminate the AER and PME messages from RCiEP.
-** If both the topologies mentioned above are supported then RCiEP and RCEC
-must be implemented in a separate PCIe domain and must be addressable via a
-separate ECAM I/O region.

===== PCIe Device Firmware
PCI expansion ROM code type 3 (UEFI) image must be provided by PCIe device
--
2.17.1

On Tue, Jan 11, 2022 at 12:48:16PM -0800, Atish Kumar Patra wrote:

On Mon, Jan 10, 2022 at 11:57 PM Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...> wrote:

-----Original Message-----
From: Heinrich Schuchardt <xypron.glpk@...>
Sent: Tuesday, January 11, 2022 3:50 PM
To: Sunil V L <sunilvl@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...>; tech-
unixplatformspec@...; Anup Patel <apatel@...>;
Atish Patra <atishp@...>; Jessica Clarke <jrtc27@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Review request: New
EFI_RISCV_BOOT_PROTOCOL

On 1/11/22 07:02, Sunil V L wrote:

On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS SW/FW

Technologist) wrote:

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;

Jessica

Clarke <jrtc27@...>; Sunil V L <sunilvl@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL



On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I

suggest to have a RISC-V EFI Protocols Specification. This spec

accommodates

EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V

platform,

and those we had implemented in edk2.

Which protocols in EDK II do you refer to?

"git grep -n RISC edk2/ | grep PRO" yields no result.

Oops... RiscVEdk2Sbi was implemented as library for now and the plan is

to rap it as PPI/protocol, bad memory.

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.

Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should

create

an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification.

I don't think this would be accepted by UEFI forum. This is RISC-V specific

protocol however, UEFI protocol is the abstract interface for platform and
architecture. Unless you can come out a abstract interface that can
accommodate different processor/platform architectures (if they also need
this).

We don't really need to merge the entire protocol to the UEFI spec. We
need to maintain this within RISC-V organization like other RISC-V specs
and add as a requirement in the platform spec. We can probably add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be better
since we do not need to update the UEFI spec for any new protocols
specific to RISC-V in future.

What do you think? Do you see any issue with this approach?

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 implement it. And not firmware can claim to be UEFI
compliant without it.

To spec out something in either UEFI or RISC-V specific spec is actually the same to RISC-V edk2 port IMO, if those are the mandatory protocols.
Edk2 RISC-V port should compliant with the firmware spec defined by either specs, unless the spec says the protocol is specifically to uboot but it is optional for other firmware solutions.

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.

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 plan to get it reviewed once with Ard and
linux-riscv also where this solution was proposed originally.

We may not be able to add to mandatory UEFI section 2.6.1 but we can
try adding to 2.6.2 and mandate it via platform spec like we do for
PCI protocol.

Atish, should this be added to EBBR also?

Thanks
Sunil

Regards,
Abner

I would prefer if every UEFI protocol that is absolutely essential for
booting were required by the UEFI specification. If the details are
maintained inside the UEFI specification or outside, does not matter to me.

Best regards

Heirnich

Thanks
Sunil

Regards,
Abner

Best regards

Heinrich

Thanks
Abner

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;

Jessica

Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

As we discussed in the Platform HSC meeting today, here is the

document

which details a new RISC-V specific EFI protocol.

https://github.com/riscv-non-isa/riscv-

uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot

hartid to

the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are

available

at

http://lists.infradead.org/pipermail/linux-riscv/2021-

December/010604.html.

I request your review and will be great if you provide the feedback

by

01/17.

Thanks!
Sunil

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
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing

this

information unnecessarily complicated. Instead consider adding a

version

field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to

me

and is

well described.

Best regards

Heinrich

On Mon, Jan 10, 2022 at 11:57 PM Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...> wrote:

-----Original Message-----
From: Heinrich Schuchardt <xypron.glpk@...>
Sent: Tuesday, January 11, 2022 3:50 PM
To: Sunil V L <sunilvl@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...>; tech-
unixplatformspec@...; Anup Patel <apatel@...>;
Atish Patra <atishp@...>; Jessica Clarke <jrtc27@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Review request: New
EFI_RISCV_BOOT_PROTOCOL

On 1/11/22 07:02, Sunil V L wrote:

On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS SW/FW

Technologist) wrote:

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;

Jessica

Clarke <jrtc27@...>; Sunil V L <sunilvl@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL



On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I

suggest to have a RISC-V EFI Protocols Specification. This spec

accommodates

EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V

platform,

and those we had implemented in edk2.

Which protocols in EDK II do you refer to?

"git grep -n RISC edk2/ | grep PRO" yields no result.

Oops... RiscVEdk2Sbi was implemented as library for now and the plan is

to rap it as PPI/protocol, bad memory.

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.

Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should

create

an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification.

I don't think this would be accepted by UEFI forum. This is RISC-V specific

protocol however, UEFI protocol is the abstract interface for platform and
architecture. Unless you can come out a abstract interface that can
accommodate different processor/platform architectures (if they also need
this).

We don't really need to merge the entire protocol to the UEFI spec. We
need to maintain this within RISC-V organization like other RISC-V specs
and add as a requirement in the platform spec. We can probably add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be better
since we do not need to update the UEFI spec for any new protocols
specific to RISC-V in future.

What do you think? Do you see any issue with this approach?

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 implement it. And not firmware can claim to be UEFI
compliant without it.

To spec out something in either UEFI or RISC-V specific spec is actually the same to RISC-V edk2 port IMO, if those are the mandatory protocols.
Edk2 RISC-V port should compliant with the firmware spec defined by either specs, unless the spec says the protocol is specifically to uboot but it is optional for other firmware solutions.

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.

Regards,
Abner

I would prefer if every UEFI protocol that is absolutely essential for
booting were required by the UEFI specification. If the details are
maintained inside the UEFI specification or outside, does not matter to me.

Best regards

Heirnich

Thanks
Sunil

Regards,
Abner

Best regards

Heinrich

Thanks
Abner

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>;

Jessica

Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

As we discussed in the Platform HSC meeting today, here is the

document

which details a new RISC-V specific EFI protocol.

https://github.com/riscv-non-isa/riscv-

uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot

hartid to

the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are

available

at

http://lists.infradead.org/pipermail/linux-riscv/2021-

December/010604.html.

I request your review and will be great if you provide the feedback

by

01/17.

Thanks!
Sunil

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
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing

this

information unnecessarily complicated. Instead consider adding a

version

field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to

me

and is

well described.

Best regards

Heinrich

On 1/11/22 07:02, Sunil V L wrote:

On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra <atishp@...>; Jessica
Clarke <jrtc27@...>; Sunil V L <sunilvl@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL



On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I

suggest to have a RISC-V EFI Protocols Specification. This spec accommodates
EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V platform,
and those we had implemented in edk2.

Which protocols in EDK II do you refer to?

"git grep -n RISC edk2/ | grep PRO" yields no result.

Oops... RiscVEdk2Sbi was implemented as library for now and the plan is to rap it as PPI/protocol, bad memory.

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.

Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should create
an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification.

I don't think this would be accepted by UEFI forum. This is RISC-V specific protocol however, UEFI protocol is the abstract interface for platform and architecture. Unless you can come out a abstract interface that can accommodate different processor/platform architectures (if they also need this).

We don't really need to merge the entire protocol to the UEFI spec. We
need to maintain this within RISC-V organization like other RISC-V specs
and add as a requirement in the platform spec. We can probably add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be better
since we do not need to update the UEFI spec for any new protocols
specific to RISC-V in future.

What do you think? Do you see any issue with this approach?

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 implement it. And not firmware can claim to be UEFI
compliant without it.

I would prefer if every UEFI protocol that is absolutely essential for
booting were required by the UEFI specification. If the details are
maintained inside the UEFI specification or outside, does not matter to me.

Best regards

Heirnich

Thanks
Sunil

Regards,
Abner

Best regards

Heinrich

Thanks
Abner

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>; Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

As we discussed in the Platform HSC meeting today, here is the

document

which details a new RISC-V specific EFI protocol.

https://github.com/riscv-non-isa/riscv-

uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot hartid to

the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are available

at

http://lists.infradead.org/pipermail/linux-riscv/2021-

December/010604.html.

I request your review and will be great if you provide the feedback by

01/17.

Thanks!
Sunil

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
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing this
information unnecessarily complicated. Instead consider adding a version
field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to me

and is

well described.

Best regards

Heinrich

On Tue, Jan 11, 2022 at 02:11:40AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 9:20 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: tech-unixplatformspec@...; Anup Patel
<apatel@...>; Atish Patra <atishp@...>; Jessica
Clarke <jrtc27@...>; Sunil V L <sunilvl@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL



On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I

suggest to have a RISC-V EFI Protocols Specification. This spec accommodates
EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V platform,
and those we had implemented in edk2.

Which protocols in EDK II do you refer to?

"git grep -n RISC edk2/ | grep PRO" yields no result.

Oops... RiscVEdk2Sbi was implemented as library for now and the plan is to rap it as PPI/protocol, bad memory.

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.

Once we have agreed on the EFI_RISCV_BOOT_PROTOCOL we should create
an
issue in bugzilla.tianocore.org and create a Mantis entry to get it
merged into the UEFI specification.

I don't think this would be accepted by UEFI forum. This is RISC-V specific protocol however, UEFI protocol is the abstract interface for platform and architecture. Unless you can come out a abstract interface that can accommodate different processor/platform architectures (if they also need this).

We don't really need to merge the entire protocol to the UEFI spec. We
need to maintain this within RISC-V organization like other RISC-V specs
and add as a requirement in the platform spec. We can probably add a
link under uefi.org/uefi and provide a reference in section 2.3.7.1.
UEFI allows us to do like this (ex: TCG2 protocols) and it may be better
since we do not need to update the UEFI spec for any new protocols
specific to RISC-V in future.

What do you think? Do you see any issue with this approach?

Thanks
Sunil

Regards,
Abner

Best regards

Heinrich

Thanks
Abner

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>; Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

As we discussed in the Platform HSC meeting today, here is the

document

which details a new RISC-V specific EFI protocol.

https://github.com/riscv-non-isa/riscv-

uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot hartid to

the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are available

at

http://lists.infradead.org/pipermail/linux-riscv/2021-

December/010604.html.

I request your review and will be great if you provide the feedback by

01/17.

Thanks!
Sunil

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
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing this
information unnecessarily complicated. Instead consider adding a version
field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to me

and is

well described.

Best regards

Heinrich

On Tue, Jan 11, 2022 at 01:07:33AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I suggest to have a RISC-V EFI Protocols Specification. This spec accommodates EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V platform, and those we had implemented in edk2.

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

Thanks
Sunil

Thanks
Abner

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>; Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

As we discussed in the Platform HSC meeting today, here is the document

which details a new RISC-V specific EFI protocol.

https://github.com/riscv-non-isa/riscv-

uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot hartid to

the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are available at

http://lists.infradead.org/pipermail/linux-riscv/2021-December/010604.html.

I request your review and will be great if you provide the feedback by

01/17.

Thanks!
Sunil

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
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing this
information unnecessarily complicated. Instead consider adding a version
field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to me and is
well described.

Best regards

Heinrich

On Mon, Jan 10, 2022 at 06:27:37PM +0100, Heinrich Schuchardt wrote:

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

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

https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot hartid to the OS. But this can be extended in future if required. A PoC has been developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are available at http://lists.infradead.org/pipermail/linux-riscv/2021-December/010604.html.

I request your review and will be great if you provide the feedback by 01/17.

Thanks!
Sunil

Dear Sunil,

thank you for drafting the protocol specification.

Hi Heinrich,
Thank you very much for your constant feedback and pointers while
drafting this spec.

The interface of a protocol may change from version to version. Therefore I
understand why there must be a path to convey this information. But using a
function like EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing
this information unnecessarily complicated. Instead consider adding a
version field as first element of the interface like many other UEFI
protocols do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

This makes perfect sense. Will update the spec.

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to me and is well
described.

Jessica has given an input to change the parameter from UINT32 * to
UINTN * since mhartid can be of XLEN. I think this is also a great
feedback. Will incorporate it in the next update of the spec.

Thanks!
Sunil

Best regards

Heinrich

On 1/11/22 02:07, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Sunil,
Instead of having a spec for EFI_RISCV_BOOT_PROTOCOL specifically, I suggest to have a RISC-V EFI Protocols Specification. This spec accommodates EFI_RISCV_BOOT_PROTOCOL, the future EFI protocols for RISC-V platform, and those we had implemented in edk2.

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 bugzilla.tianocore.org and create a Mantis entry to get it merged into the UEFI specification.

Best regards

Heinrich

Thanks
Abner

-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Tuesday, January 11, 2022 1:28 AM
To: Sunil V L <sunilvl@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Anup Patel
<apatel@...>; Atish Patra <atishp@...>; Jessica
Clarke <jrtc27@...>
Subject: Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

On 1/10/22 18:02, Sunil V L wrote:

Hi All,

As we discussed in the Platform HSC meeting today, here is the document

which details a new RISC-V specific EFI protocol.

https://github.com/riscv-non-isa/riscv-

uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot hartid to

the OS. But this can be extended in future if required. A PoC has been
developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are available at

http://lists.infradead.org/pipermail/linux-riscv/2021-December/010604.html.

I request your review and will be great if you provide the feedback by

01/17.

Thanks!
Sunil

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
information. But using a function like
EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing this
information unnecessarily complicated. Instead consider adding a version
field as first element of the interface like many other UEFI protocols
do. This will also decrease the implementation size. For alignment
reasons make this field UINT64. Other protocols call such a field
"Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to me and is
well described.

Best regards

Heinrich

On 1/10/22 18:02, Sunil V L wrote:

Hi All,
As we discussed in the Platform HSC meeting today, here is the document which details a new RISC-V specific EFI protocol.
https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf
Currently, the main use case of this protocol is to pass the boot hartid to the OS. But this can be extended in future if required. A PoC has been developed using EDK2 and Linux.
More details of this requirement and alternatives discussed are available at http://lists.infradead.org/pipermail/linux-riscv/2021-December/010604.html.
I request your review and will be great if you provide the feedback by 01/17.
Thanks!
Sunil

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 information. But using a function like EFI_RISCV_BOOT_PROTOCOL.GetProtocolVersion() makes accessing this information unnecessarily complicated. Instead consider adding a version field as first element of the interface like many other UEFI protocols do. This will also decrease the implementation size. For alignment reasons make this field UINT64. Other protocols call such a field "Revision". Please, provide a define for the current version. E.g.

#define EFI_RISCV_BOOT_PROTOCOL_REVISION 0x00010000
#define EFI_RISCV_BOOT_PROTOCOL_LATEST_VERSION \
EFI_RISCV_BOOT_PROTOCOL_REVISION

Function EFI_RISCV_BOOT_PROTOCOL.GetBootHartId() looks ok to me and is well described.

Best regards

Heinrich

Hi All,

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

https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.1/EFI_RISCV_BOOT_PROTOCOL.pdf

Currently, the main use case of this protocol is to pass the boot hartid to the OS. But this can be extended in future if required. A PoC has been developed using EDK2 and Linux.

More details of this requirement and alternatives discussed are available at http://lists.infradead.org/pipermail/linux-riscv/2021-December/010604.html.

I request your review and will be great if you provide the feedback by 01/17.

Thanks!
Sunil

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 wiki:
https://github.com/riscv/riscv-platform-specs/wiki

Here are the slides:
https://docs.google.com/presentation/d/1SNKpnOshmPO-Ornj0PKACKfHGbXmS2WIHxkFYL7MO_s/edit#slide=id.gce1d523d02_0_0

Meeting info
Zoom meeting: https://zoom.us/j/2786028446
Passcode: 901897

Or iPhone one-tap :
US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 278 602 8446
International numbers available:
https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_

Regards
Kumar

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 host bridge MUST honor the No Snoop hint.  So, are we saying RiscV OS-A server platforms must honor the no snoop hint?  If not I think the text as written is miss leading.

Hi, thanks for the response.

“ Memory that is cacheable by harts may not be kept coherent by hardware when PCIe transactions to that memory are marked with a No_Snoop bit of one.   On systems that honor the No Snoop hint, software must manage coherence on such memory; otherwise, software coherence management is not required.”

At the very least the typo on the No Snoop polarity should be corrected.

Hello,

Proposed text for 4.7.3.4:

A system is required to provide hardware managed coherence for PCIe traffic. A system may ignore the No_snoop hint bit and treat all PCIe traffic as HW coherent.  A system may choose to honor the No_snoop (NS) hint bit on incoming PCIe transactions.  In this case software must manage coherence for the memory used by the device issuing the transactions.  Such systems must also honor the relaxed order (RO) hint bit.  To take full advantage of SW coherence the device should set both NS and RO to 1.  Otherwise, when RO=0 the snooped and non-snooped traffic arriving through a host bridge must be kept ordered, eliminating the benefit of routing some traffic around the cache hierarchy to memory.