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
|
