Date   

Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

On Thu, Jan 13, 2022 at 10:13:04AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:


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

On Wed, Jan 12, 2022 at 05:53:15PM -0800, Atish Kumar Patra wrote:
On Wed, Jan 12, 2022 at 12:04 AM Sunil V L <sunilvl@...>
wrote:

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.
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 on UEFI platforms to retrieve such
information."

The following statement should be improved to indicate that /chosen
node is an existing solution. However, it will not work for ACPI.
EFI_RISCV_BOOT_PROTOCOL should be the preferred over /chosen node
option for both DT/ACPI platforms.
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 to
USWG.
We still need ECR?
The "codefirst" is to have the implementation first then submit the ECR for the new UEFI protocol.
However, we are not going to propose any protocols to UEFI spec. Even don't need to add a sentence for the external reference to this new document. To add the requirement in the platform spec is the perfect match IMO.
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
already talks about the DT node, correct?

In addition, we can try adding this to 2.6.2 like other optional
protocols. I am not very sure whether USWG will agree for this. But
at the minimum if 2.3.7.1 can be updated.

Thanks
Sunil
Abner


Atish, should this be added to EBBR also?
Yeah. RISC-V Multiprocessor Startup Protocol should be updated.
EFI_RISCV_BOOT_PROTOCOL should be preferred first. In absence of this,
firmware must
provide the /chosen hartid for the DT based platforms.

I guess you don't need to update EBBR right away. Once this is
accepted in the UEFI forum, EBBR can be updated.
Sure.

Thanks
Sunil

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





Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

On Wed, Jan 12, 2022 at 05:53:15PM -0800, Atish Kumar Patra wrote:
On Wed, Jan 12, 2022 at 12:04 AM Sunil V L <sunilvl@...> wrote:

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.
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 on UEFI platforms to retrieve such
information."

The following statement should be improved to indicate that /chosen
node is an existing solution. However, it will not work for ACPI.
EFI_RISCV_BOOT_PROTOCOL should be the preferred over /chosen node
option for both DT/ACPI platforms.
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 to
USWG.


Atish, should this be added to EBBR also?
Yeah. RISC-V Multiprocessor Startup Protocol should be updated.
EFI_RISCV_BOOT_PROTOCOL should be preferred first. In absence of this,
firmware must
provide the /chosen hartid for the DT based platforms.

I guess you don't need to update EBBR right away. Once this is
accepted in the UEFI forum, EBBR can be updated.
Sure.

Thanks
Sunil

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





Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

atishp@...
 

On Wed, Jan 12, 2022 at 12:04 AM Sunil V L <sunilvl@...> wrote:

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.
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 on UEFI platforms to retrieve such
information."

The following statement should be improved to indicate that /chosen
node is an existing solution. However, it will not work for ACPI.
EFI_RISCV_BOOT_PROTOCOL should be the preferred over /chosen node
option for both DT/ACPI platforms.

Atish, should this be added to EBBR also?
Yeah. RISC-V Multiprocessor Startup Protocol should be updated.
EFI_RISCV_BOOT_PROTOCOL should be preferred first. In absence of this,
firmware must
provide the /chosen hartid for the DT based platforms.

I guess you don't need to update EBBR right away. Once this is
accepted in the UEFI forum, EBBR can be updated.

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





Re: Public review of Supervisor Binary Interface (SBI) Specification

Jonathan Behrens <behrensj@...>
 

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 extensions aren't defining any meaning to the various possible non-zero values, I personally don't see why we shouldn't change it to "returns one if it is available".

Jonathan


On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra <atishp@...> wrote:
On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
>
> 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, right now I don't think any of them do. Is this something that should be fixed?
>

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 value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.

> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
>>
>> 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
>>
>>
>>
>>
>>


Re: Public review of Supervisor Binary Interface (SBI) Specification

atishp@...
 

On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:

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, right now I don't think any of them do. Is this something that should be fixed?
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 value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.

Jonathan

On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:

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





Re: OS-A platform stoptime requirement

Paul Donahue
 

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 unfriendly to those with dialup connections.)


Thanks,

-Paul


On Mon, Jan 3, 2022 at 9:45 AM Atish Kumar Patra <atishp@...> wrote:


On Mon, Jan 3, 2022 at 9:43 AM Beeman Strong <beeman@...> wrote:
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 be filed to get that changed?

Send a patch :)


On Wed, Dec 29, 2021 at 9:44 AM Tim Newsome <tim@...> wrote:
On Tue, Dec 28, 2021 at 4:19 PM Ved Shanbhogue <ved@...> wrote:
On Tue, Dec 28, 2021 at 10:04:41AM -0800, Tim Newsome wrote:
>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 through code with a
>timer interrupt enabled, without going into that timer interrupt every time
>you single step.

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

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 peripherals that will not stop generating interrupts/counting time/whatever.)

Tim 


[PATCH] Remove stoptime requirement

Paul Donahue
 

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 238af3a..7a02b76 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -261,8 +261,7 @@ and one resume group (in addition to group 0)
 - dcsr.stepie must support the 0 setting. It is optional to support the 1
 setting
   * Rationale: It is not generally useful to step into interrupt handlers.
-- dcsr.stopcount and dcsr.stoptime must be supported and the reset value of
-each must be 1
+- dcsr.stopcount must be supported and the reset value must be 1
   * Rationale: The architecture has strict requirements on minstret which may
     be perturbed by an external debugger in a way that's visible to software.
     The default should allow code that's sensitive to these requirements to be
--
2.21.0


Re: Public review of Supervisor Binary Interface (SBI) Specification

Jonathan Behrens <behrensj@...>
 

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, right now I don't think any of them do. Is this something that should be fixed?

Jonathan


On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
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






Public review of Supervisor Binary Interface (SBI) Specification

atishp@...
 

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


[PATCH] Updated PCIe sections 4.7.3.4 and 4.7.3.5

Mayuresh Chitale
 

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


Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

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





Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

atishp@...
 

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





Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Heinrich Schuchardt
 

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




Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

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


Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

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


Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

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



Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Heinrich Schuchardt
 

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


Re: Review request: New EFI_RISCV_BOOT_PROTOCOL

Heinrich Schuchardt
 

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


Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L
 

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


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

Kumar Sankaran
 

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

201 - 220 of 1845