tech-unixplatformspec@lists.riscv.org | Review request: New EFI_RISCV_BOOT

Home Messages Hashtags Subgroups

Date Date 1 - 12 of 12

Review request: New EFI_RISCV_BOOT_PROTOCOL

Sunil V L #1627 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
More All Messages By This Member
Heinrich Schuchardt #1628 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
More All Messages By This Member
Heinrich Schuchardt #1629 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
More All Messages By This Member
Sunil V L #1630 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
More All Messages By This Member
Sunil V L #1631 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
More All Messages By This Member
Sunil V L #1632 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
More All Messages By This Member
Heinrich Schuchardt #1633 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
More All Messages By This Member
atishp@... #1634 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
More All Messages By This Member
Sunil V L #1635 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
More All Messages By This Member
atishp@... #1643 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
More All Messages By This Member
Sunil V L #1644 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
More All Messages By This Member
Sunil V L #1645 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
More All Messages By This Member

1 - 12 of 12

Previous Topic Next Topic

Home Hashtags Subgroups Terms