Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement: 1. As per the contribution guidelines[1], patches should be sent to boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement: 1. Software status: a. UEFI support for RISC-V Linux kernel is already available in the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
2. RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,... [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,... [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
On 20.08.20 08:45, Ard Biesheuvel wrote:
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
EFI_RESET_SYSTEM is a runtime service. To achieve compliance EBBR https://github.com/ARM-software/ebbr/blob/master/source/chapter2-uefi.rst requires to implement it at least before ExitBootServices().
The EBBR describes per board requirements for the implementation of the UEFI API, not requirements on prior firmware stages like SBI and TF-A.
Even if the SBI specification does not have a general service for implementing reset in a hardware agnostic way this does not stop per board implementation.
In U-Boot all boards implementing the U-Boot reset command also provide the ResetSystem() service before ExitBootServices(), e.g. the Kendryte K210 based Sipeed Maixduino board.
b. RISC-V Multiprocessor Startup Protocol: This section willcontain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented.
I guess this will include
* passing of booting hart and device-tree to next stage * privilege levels
Best regards
Heinrich
c. Firmware Storage: AFAIK, RISC-V platforms are alreadycompatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,... [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
On Thu, Aug 20, 2020 at 1:45 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 20.08.20 08:45, Ard Biesheuvel wrote:
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
EFI_RESET_SYSTEM is a runtime service. To achieve compliance EBBR https://github.com/ARM-software/ebbr/blob/master/source/chapter2-uefi.rst requires to implement it at least before ExitBootServices().
The EBBR describes per board requirements for the implementation of the UEFI API, not requirements on prior firmware stages like SBI and TF-A.
Even if the SBI specification does not have a general service for implementing reset in a hardware agnostic way this does not stop per board implementation.
The idea of SBI Reset specification was to come up with a standard way of system reset to avoid per board implementation and emulation in hypervisors.
In U-Boot all boards implementing the U-Boot reset command also provide the ResetSystem() service before ExitBootServices(), e.g. the Kendryte K210 based Sipeed Maixduino board.
b. RISC-V Multiprocessor Startup Protocol: This section willcontain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented.
I guess this will include
- passing of booting hart and device-tree to next stage
- privilege levels
Yes. Few others such as SBI HSM extension. I guess it will just probably point to the booting section of RISC-V Platform specification or other way around.
Best regards
Heinrich
c. Firmware Storage: AFAIK, RISC-V platforms are alreadycompatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3]
https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,...
[4]
https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
I would suggest this, 1. Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded base boot requirement. 2. Add the section in UEFi EBBR for the different archs, such as ARM and RISC-V. 3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec is generic to multiple archs. One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
Abner
Get Outlook for Androidhttps://aka.ms/ghei36 ________________________________ From: Ard Biesheuvel ardb@kernel.org Sent: Thursday, August 20, 2020 2:45:38 PM To: Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; François Ozog francois.ozog@linaro.org Cc: Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Schaefer, Daniel daniel.schaefer@hpe.com Subject: Re: Adding RISC-V to EBBR
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,... [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
Hi,
before commenting the proposal, I'd like to share my views on boot architecture.
I sense we are at an inflection point for the role of firmware, moving away from "let's start the OS as fast as possible" to "let's continue to do so but also provide additional (trust related) services". So I envision the set of components that brings the OS up and offer (trust) services to OS/hypervisor/VMs/containers as a distinct logical software layer that I named "Trusted Substrate". This layer sits between silicon and OS/hypervisor. The services go beyond UEFI Runtime Services and may actually reside in protected worlds (which are implemented in various ways in different architectures - for instance in the Arm TrustZone, Intel Management Engine or in SGX isolated components).
In that context the "contract" between firmware and OS (mostly UEFI) is just one aspect of the boot architecture which should be specified in EBBR.
On Thu, 20 Aug 2020 at 10:55, Chang, Abner (HPS SW/FW Technologist) < abner.chang@hpe.com> wrote:
I would suggest this,
- Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded
base boot requirement.
I would say there are companion ECRs to the one you refer below that tried to do that. We are working on new version with additional explanations on the **whys** we propose the ECRs. EBBR will continue to refer to UEFI parts (and UEFI section in EBBR shall shrink as we progress on the UEFI.org specification) but will go beyond UEFI as I described above for the Trusted Substrate and would need per architecture sections (trust services implementation). So EBBR shall stay independent from UEFI.
- Add the section in UEFi EBBR for the different archs, such as ARM and
RISC-V.
3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec
is generic to multiple archs. One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
Abner
Get Outlook for Android https://aka.ms/ghei36
*From:* Ard Biesheuvel ardb@kernel.org *Sent:* Thursday, August 20, 2020 2:45:38 PM *To:* Atish Patra atishp@atishpatra.org; Grant Likely < grant.likely@arm.com>; François Ozog francois.ozog@linaro.org *Cc:* Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov < david.abdurachmanov@gmail.com>; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Schaefer, Daniel < daniel.schaefer@hpe.com> *Subject:* Re: Adding RISC-V to EBBR
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3]
https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,...
[4]
https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
From: François Ozog [mailto:francois.ozog@linaro.org] Sent: Thursday, August 20, 2020 6:19 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Ard Biesheuvel ardb@kernel.org; Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Schaefer, Daniel daniel.schaefer@hpe.com Subject: Re: Adding RISC-V to EBBR
Hi,
before commenting the proposal, I'd like to share my views on boot architecture.
I sense we are at an inflection point for the role of firmware, moving away from "let's start the OS as fast as possible" to "let's continue to do so but also provide additional (trust related) services". So I envision the set of components that brings the OS up and offer (trust) services to OS/hypervisor/VMs/containers as a distinct logical software layer that I named "Trusted Substrate". This layer sits between silicon and OS/hypervisor. The services go beyond UEFI Runtime Services and may actually reside in protected worlds (which are implemented in various ways in different architectures - for instance in the Arm TrustZone, Intel Management Engine or in SGX isolated components).
In that context the "contract" between firmware and OS (mostly UEFI) is just one aspect of the boot architecture which should be specified in EBBR.
On Thu, 20 Aug 2020 at 10:55, Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.commailto:abner.chang@hpe.com> wrote: I would suggest this, 1. Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded base boot requirement. I would say there are companion ECRs to the one you refer below that tried to do that. We are working on new version with additional explanations on the **whys** we propose the ECRs. EBBR will continue to refer to UEFI parts (and UEFI section in EBBR shall shrink as we progress on the UEFI.org specification) but will go beyond UEFI as I described above for the Trusted Substrate and would need per architecture sections (trust services implementation). So EBBR shall stay independent from UEFI. [Abner] Yes. I agree with you at this point. That depends on how do we position EBBR. EBBR should stay with UEFI if EBBR is only firmware requirements of how embedded system leverage UEFI firmware. If it goes beyond UEFI firmware, then for sure it doesn’t have to be stayed in UEFI. Juts move UEFI stuff from EBBR to UEFI spec and make it as the reference in EBBR.
Is "Trusted Substrate" an ongoing task which someone is working on it and adding to EBBR? Or it is just a thought? I don’t know the detail of "Trusted Substrate", however I assume that is an abstract spec and firmware code base independent?
2. Add the section in UEFi EBBR for the different archs, such as ARM and RISC-V. 3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec is generic to multiple archs. One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
Abner
Get Outlook for Androidhttps://aka.ms/ghei36 ________________________________ From: Ard Biesheuvel <ardb@kernel.orgmailto:ardb@kernel.org> Sent: Thursday, August 20, 2020 2:45:38 PM To: Atish Patra <atishp@atishpatra.orgmailto:atishp@atishpatra.org>; Grant Likely <grant.likely@arm.commailto:grant.likely@arm.com>; François Ozog <francois.ozog@linaro.orgmailto:francois.ozog@linaro.org> Cc: Boot Architecture Mailman List <boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org>; Anup Patel <anup@brainfault.orgmailto:anup@brainfault.org>; David Abdurachmanov <david.abdurachmanov@gmail.commailto:david.abdurachmanov@gmail.com>; Palmer Dabbelt <palmer@dabbelt.commailto:palmer@dabbelt.com>; Heinrich Schuchardt <xypron.glpk@gmx.demailto:xypron.glpk@gmx.de>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.commailto:abner.chang@hpe.com>; Schaefer, Daniel <daniel.schaefer@hpe.commailto:daniel.schaefer@hpe.com> Subject: Re: Adding RISC-V to EBBR
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra <atishp@atishpatra.orgmailto:atishp@atishpatra.org> wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,...https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,20,2,0,76053051 [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::relevance,,Add+system+reset+extension,20,2,0,73235534
-- Regards, Atish
-- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&...] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog
On Thu, 20 Aug 2020 at 12:48, Chang, Abner (HPS SW/FW Technologist) < abner.chang@hpe.com> wrote:
*From:* François Ozog [mailto:francois.ozog@linaro.org] *Sent:* Thursday, August 20, 2020 6:19 PM *To:* Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com *Cc:* Ard Biesheuvel ardb@kernel.org; Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; Boot Architecture Mailman List < boot-architecture@lists.linaro.org>; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt < palmer@dabbelt.com>; Heinrich Schuchardt xypron.glpk@gmx.de; Schaefer, Daniel daniel.schaefer@hpe.com *Subject:* Re: Adding RISC-V to EBBR
Hi,
before commenting the proposal, I'd like to share my views on boot architecture.
I sense we are at an inflection point for the role of firmware, moving away from "let's start the OS as fast as possible" to "let's continue to do so but also provide additional (trust related) services".
So I envision the set of components that brings the OS up and offer (trust) services to OS/hypervisor/VMs/containers as a distinct logical software layer that I named "Trusted Substrate". This layer sits between silicon and OS/hypervisor. The services go beyond UEFI Runtime Services and may actually reside in protected worlds (which are implemented in various ways in different architectures - for instance in the Arm TrustZone, Intel Management Engine or in SGX isolated components).
In that context the "contract" between firmware and OS (mostly UEFI) is just one aspect of the boot architecture which should be specified in EBBR.
On Thu, 20 Aug 2020 at 10:55, Chang, Abner (HPS SW/FW Technologist) < abner.chang@hpe.com> wrote:
I would suggest this,
- Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded
base boot requirement.
I would say there are companion ECRs to the one you refer below that tried to do that. We are working on new version with additional explanations on the **whys** we propose the ECRs.
EBBR will continue to refer to UEFI parts (and UEFI section in EBBR shall shrink as we progress on the UEFI.org specification) but will go beyond UEFI as I described above for the Trusted Substrate and would need per architecture sections (trust services implementation).
So EBBR shall stay independent from UEFI.
*[Abner]*
*Yes. I agree with you at this point. That depends on how do we position EBBR. EBBR should stay with UEFI if EBBR is only firmware requirements of how embedded system leverage UEFI firmware.*
*If it goes beyond UEFI firmware, then for sure it doesn’t have to be stayed in UEFI. Juts move UEFI stuff from EBBR to UEFI spec and make it as the reference in EBBR.*
*Is **"Trusted Substrate" an ongoing task which someone is working on it and adding to EBBR? Or it is just a thought?*
*I don’t know the detail of *"Trusted Substrate", *however I assume that is an abstract spec and firmware code base independent?*
attached is a presentation I gave last week at a BrightTalk IoT summit. Today, Trusted Substrate is mostly evolving within Linaro with some references to it in Linux Foundation Project Alvarium. This is going to gradually change, but as it is led by engineers that are not that marketing savvy....it make take some time ;-) October is probably a good target for more public information.
- Add the section in UEFi EBBR for the different archs, such as ARM and
RISC-V.
- Trim some spec mentioned in ebbr and move it to uefi/pi spec if the
spec is generic to multiple archs.
One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
Abner
Get Outlook for Android https://aka.ms/ghei36
*From:* Ard Biesheuvel ardb@kernel.org *Sent:* Thursday, August 20, 2020 2:45:38 PM *To:* Atish Patra atishp@atishpatra.org; Grant Likely < grant.likely@arm.com>; François Ozog francois.ozog@linaro.org *Cc:* Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov < david.abdurachmanov@gmail.com>; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Schaefer, Daniel < daniel.schaefer@hpe.com> *Subject:* Re: Adding RISC-V to EBBR
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3]
https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,...
[4]
https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
--
*François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
From: François Ozog [mailto:francois.ozog@linaro.org] Sent: Thursday, August 20, 2020 7:38 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Ard Biesheuvel ardb@kernel.org; Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Schaefer, Daniel daniel.schaefer@hpe.com Subject: Re: Adding RISC-V to EBBR
On Thu, 20 Aug 2020 at 12:48, Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.commailto:abner.chang@hpe.com> wrote: From: François Ozog [mailto:francois.ozog@linaro.orgmailto:francois.ozog@linaro.org] Sent: Thursday, August 20, 2020 6:19 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.commailto:abner.chang@hpe.com> Cc: Ard Biesheuvel <ardb@kernel.orgmailto:ardb@kernel.org>; Atish Patra <atishp@atishpatra.orgmailto:atishp@atishpatra.org>; Grant Likely <grant.likely@arm.commailto:grant.likely@arm.com>; Boot Architecture Mailman List <boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org>; Anup Patel <anup@brainfault.orgmailto:anup@brainfault.org>; David Abdurachmanov <david.abdurachmanov@gmail.commailto:david.abdurachmanov@gmail.com>; Palmer Dabbelt <palmer@dabbelt.commailto:palmer@dabbelt.com>; Heinrich Schuchardt <xypron.glpk@gmx.demailto:xypron.glpk@gmx.de>; Schaefer, Daniel <daniel.schaefer@hpe.commailto:daniel.schaefer@hpe.com> Subject: Re: Adding RISC-V to EBBR
Hi,
before commenting the proposal, I'd like to share my views on boot architecture.
I sense we are at an inflection point for the role of firmware, moving away from "let's start the OS as fast as possible" to "let's continue to do so but also provide additional (trust related) services". So I envision the set of components that brings the OS up and offer (trust) services to OS/hypervisor/VMs/containers as a distinct logical software layer that I named "Trusted Substrate". This layer sits between silicon and OS/hypervisor. The services go beyond UEFI Runtime Services and may actually reside in protected worlds (which are implemented in various ways in different architectures - for instance in the Arm TrustZone, Intel Management Engine or in SGX isolated components).
In that context the "contract" between firmware and OS (mostly UEFI) is just one aspect of the boot architecture which should be specified in EBBR.
On Thu, 20 Aug 2020 at 10:55, Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.commailto:abner.chang@hpe.com> wrote: I would suggest this, 1. Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded base boot requirement. I would say there are companion ECRs to the one you refer below that tried to do that. We are working on new version with additional explanations on the **whys** we propose the ECRs. EBBR will continue to refer to UEFI parts (and UEFI section in EBBR shall shrink as we progress on the UEFI.org specification) but will go beyond UEFI as I described above for the Trusted Substrate and would need per architecture sections (trust services implementation). So EBBR shall stay independent from UEFI. [Abner] Yes. I agree with you at this point. That depends on how do we position EBBR. EBBR should stay with UEFI if EBBR is only firmware requirements of how embedded system leverage UEFI firmware. If it goes beyond UEFI firmware, then for sure it doesn’t have to be stayed in UEFI. Juts move UEFI stuff from EBBR to UEFI spec and make it as the reference in EBBR.
Is "Trusted Substrate" an ongoing task which someone is working on it and adding to EBBR? Or it is just a thought? I don’t know the detail of "Trusted Substrate", however I assume that is an abstract spec and firmware code base independent?
attached is a presentation I gave last week at a BrightTalk IoT summit. Today, Trusted Substrate is mostly evolving within Linaro with some references to it in Linux Foundation Project Alvarium. This is going to gradually change, but as it is led by engineers that are not that marketing savvy....it make take some time ;-) October is probably a good target for more public information. [Abner] You really consider "Trusted Substrate" is part of E*Base*BR? This proposal seems to me should be separated from EBBR ☺. 2. Add the section in UEFi EBBR for the different archs, such as ARM and RISC-V. 3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec is generic to multiple archs. One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
Abner
Get Outlook for Androidhttps://aka.ms/ghei36 ________________________________ From: Ard Biesheuvel <ardb@kernel.orgmailto:ardb@kernel.org> Sent: Thursday, August 20, 2020 2:45:38 PM To: Atish Patra <atishp@atishpatra.orgmailto:atishp@atishpatra.org>; Grant Likely <grant.likely@arm.commailto:grant.likely@arm.com>; François Ozog <francois.ozog@linaro.orgmailto:francois.ozog@linaro.org> Cc: Boot Architecture Mailman List <boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org>; Anup Patel <anup@brainfault.orgmailto:anup@brainfault.org>; David Abdurachmanov <david.abdurachmanov@gmail.commailto:david.abdurachmanov@gmail.com>; Palmer Dabbelt <palmer@dabbelt.commailto:palmer@dabbelt.com>; Heinrich Schuchardt <xypron.glpk@gmx.demailto:xypron.glpk@gmx.de>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.commailto:abner.chang@hpe.com>; Schaefer, Daniel <daniel.schaefer@hpe.commailto:daniel.schaefer@hpe.com> Subject: Re: Adding RISC-V to EBBR
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra <atishp@atishpatra.orgmailto:atishp@atishpatra.org> wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,...https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,20,2,0,76053051 [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::relevance,,Add+system+reset+extension,20,2,0,73235534
-- Regards, Atish
-- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&...] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog
-- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&...] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog
On Thu, 20 Aug 2020 at 14:55, Chang, Abner (HPS SW/FW Technologist) < abner.chang@hpe.com> wrote:
*From:* François Ozog [mailto:francois.ozog@linaro.org] *Sent:* Thursday, August 20, 2020 7:38 PM *To:* Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com *Cc:* Ard Biesheuvel ardb@kernel.org; Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; Boot Architecture Mailman List < boot-architecture@lists.linaro.org>; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt < palmer@dabbelt.com>; Heinrich Schuchardt xypron.glpk@gmx.de; Schaefer, Daniel daniel.schaefer@hpe.com *Subject:* Re: Adding RISC-V to EBBR
On Thu, 20 Aug 2020 at 12:48, Chang, Abner (HPS SW/FW Technologist) < abner.chang@hpe.com> wrote:
*From:* François Ozog [mailto:francois.ozog@linaro.org] *Sent:* Thursday, August 20, 2020 6:19 PM *To:* Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com *Cc:* Ard Biesheuvel ardb@kernel.org; Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; Boot Architecture Mailman List < boot-architecture@lists.linaro.org>; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt < palmer@dabbelt.com>; Heinrich Schuchardt xypron.glpk@gmx.de; Schaefer, Daniel daniel.schaefer@hpe.com *Subject:* Re: Adding RISC-V to EBBR
Hi,
before commenting the proposal, I'd like to share my views on boot architecture.
I sense we are at an inflection point for the role of firmware, moving away from "let's start the OS as fast as possible" to "let's continue to do so but also provide additional (trust related) services".
So I envision the set of components that brings the OS up and offer (trust) services to OS/hypervisor/VMs/containers as a distinct logical software layer that I named "Trusted Substrate". This layer sits between silicon and OS/hypervisor. The services go beyond UEFI Runtime Services and may actually reside in protected worlds (which are implemented in various ways in different architectures - for instance in the Arm TrustZone, Intel Management Engine or in SGX isolated components).
In that context the "contract" between firmware and OS (mostly UEFI) is just one aspect of the boot architecture which should be specified in EBBR.
On Thu, 20 Aug 2020 at 10:55, Chang, Abner (HPS SW/FW Technologist) < abner.chang@hpe.com> wrote:
I would suggest this,
- Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded
base boot requirement.
I would say there are companion ECRs to the one you refer below that tried to do that. We are working on new version with additional explanations on the **whys** we propose the ECRs.
EBBR will continue to refer to UEFI parts (and UEFI section in EBBR shall shrink as we progress on the UEFI.org specification) but will go beyond UEFI as I described above for the Trusted Substrate and would need per architecture sections (trust services implementation).
So EBBR shall stay independent from UEFI.
*[Abner]*
*Yes. I agree with you at this point. That depends on how do we position EBBR. EBBR should stay with UEFI if EBBR is only firmware requirements of how embedded system leverage UEFI firmware.*
*If it goes beyond UEFI firmware, then for sure it doesn’t have to be stayed in UEFI. Juts move UEFI stuff from EBBR to UEFI spec and make it as the reference in EBBR.*
*Is **"Trusted Substrate" an ongoing task which someone is working on it and adding to EBBR? Or it is just a thought?*
*I don’t know the detail of *"Trusted Substrate", *however I assume that is an abstract spec and firmware code base independent?*
attached is a presentation I gave last week at a BrightTalk IoT summit. Today, Trusted Substrate is mostly evolving within Linaro with some references to it in Linux Foundation Project Alvarium. This is going to gradually change, but as it is led by engineers that are not that marketing savvy....it make take some time ;-) October is probably a good target for more public information.
*[Abner] You really consider **"Trusted Substrate" is part of E*Base*BR? This proposal seems to me should be separated from EBBR **J* *.*
You are right: because of Trusted Substrate, EBBR shall reference other interfaces/standards than UEFI. Candidates are, for instance, Parsec, PSA-API, TBFU...
- Add the section in UEFi EBBR for the different archs, such as ARM and
RISC-V.
- Trim some spec mentioned in ebbr and move it to uefi/pi spec if the
spec is generic to multiple archs.
One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
Abner
Get Outlook for Android https://aka.ms/ghei36
*From:* Ard Biesheuvel ardb@kernel.org *Sent:* Thursday, August 20, 2020 2:45:38 PM *To:* Atish Patra atishp@atishpatra.org; Grant Likely < grant.likely@arm.com>; François Ozog francois.ozog@linaro.org *Cc:* Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov < david.abdurachmanov@gmail.com>; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Schaefer, Daniel < daniel.schaefer@hpe.com> *Subject:* Re: Adding RISC-V to EBBR
(+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3]
https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,...
[4]
https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
--
*François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
--
*François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On 20/08/2020 09:54, Chang, Abner (HPS SW/FW Technologist) wrote:
I would suggest this,
- Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded
base boot requirement. 2. Add the section in UEFi EBBR for the different archs, such as ARM and RISC-V. 3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec is generic to multiple archs. One example is the Device Tree guid for DTB installed in EFI configuration table. Samer from ARM had ECR for this, but I suggest to pull out entire DT section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. We also had an UEFI ECR for RISC-V in which we mention refer to EFI configuration table section for installing DTB.
I'm happy for text to be pulled out of EBBR and moved into UEFI proper as appropriate. EBBR is intended to be a roll-up document that can cover multiple specs and that OS vendors can point to as the set of requirements needed on supported platforms.
g.
Abner
Get Outlook for Android https://aka.ms/ghei36
*From:* Ard Biesheuvel ardb@kernel.org *Sent:* Thursday, August 20, 2020 2:45:38 PM *To:* Atish Patra atishp@atishpatra.org; Grant Likely grant.likely@arm.com; François Ozog francois.ozog@linaro.org *Cc:* Boot Architecture Mailman List boot-architecture@lists.linaro.org; Anup Patel anup@brainfault.org; David Abdurachmanov david.abdurachmanov@gmail.com; Palmer Dabbelt palmer@dabbelt.com; Heinrich Schuchardt xypron.glpk@gmx.de; Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Schaefer, Daniel daniel.schaefer@hpe.com *Subject:* Re: Adding RISC-V to EBBR (+ Grant, Francois)
On Thu, 20 Aug 2020 at 02:04, Atish Patra atishp@atishpatra.org wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers. 2. The specification is licensed under Creative Commons. The RISC-V related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that. 3. It should be okay to add other copyrights in addition to "Arm Limited and Contributors".
Technical Requirement:
- Software status:
a. UEFI support for RISC-V Linux kernel is already available in the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
- RISC-V related sections in EBBR
a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility? b. RISC-V Multiprocessor Startup Protocol: This section will contain the details of booting protocol for RISC-V and mandatory RISC-V specifications that need to be implemented. c. Firmware Storage: AFAIK, RISC-V platforms are already compatible with this.
Please let me know if I missed something or oversimplified any requirement. We want to make RISC-V compatible with EBBR sooner than later and ready work on any missing pieces if any.
[1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst [2] https://lkml.org/lkml/2020/8/19/1252 [3] https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,... [4] https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::re...
-- Regards, Atish
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Atish,
I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms.
g.
On 20/08/2020 01:03, Atish Patra wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers.
Yes, I will accept RISC-V content
- The specification is licensed under Creative Commons. The RISC-V
related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that.
Yes
- It should be okay to add other copyrights in addition to "Arm
Limited and Contributors".
That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting.
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
+Al Stone.
On Thu, Aug 20, 2020 at 6:46 PM Grant Likely grant.likely@arm.com wrote:
Hi Atish,
I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms.
g.
On 20/08/2020 01:03, Atish Patra wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers.
Yes, I will accept RISC-V content
- The specification is licensed under Creative Commons. The RISC-V
related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that.
Yes
- It should be okay to add other copyrights in addition to "Arm
Limited and Contributors".
That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting.
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.
I don't expect issues adding EFI_RESET_SYSTEM for FU540 (the reference platform majority of developers are using). It's basically GPIO active low to reset the SoC.
https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hif...
We should have GPIO support for FU540 in U-Boot thus we can do something similar to this: https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layersca...
A small thing compared to everything else, but we probably can get EFI_RESET_SYSTEM working for FU540.
david
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 8/20/20 6:45 PM, David Abdurachmanov wrote:
+Al Stone.
On Thu, Aug 20, 2020 at 6:46 PM Grant Likely grant.likely@arm.com wrote:
Hi Atish,
I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms.
g.
On 20/08/2020 01:03, Atish Patra wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers.
Yes, I will accept RISC-V content
- The specification is licensed under Creative Commons. The RISC-V
related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that.
Yes
- It should be okay to add other copyrights in addition to "Arm
Limited and Contributors".
That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting.
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.
I don't expect issues adding EFI_RESET_SYSTEM for FU540 (the reference platform majority of developers are using). It's basically GPIO active low to reset the SoC.
https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hif...
We should have GPIO support for FU540 in U-Boot thus we can do something similar to this: https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layersca...
A small thing compared to everything else, but we probably can get EFI_RESET_SYSTEM working for FU540.
In U-Boot: CONFIG_SYSRESET=y for sifive_fu540_defconfig.
The device tree has
gpio-restart { compatible = "gpio-restart"; gpios = <0x0c 0x0a 0x01>; };
Is there really anything missing for the SiFive HiFive Unleashed?
The following patch allows you to test if the UEFI ResetSystem() service is working when you compile with
CONFIG_EFI_LOADER=y CONFIG_EFI_SELFTEST=y
[1/1] efi_selftest: add a test for ResetSystem() https://lists.denx.de/pipermail/u-boot/2020-August/424075.html https://patchwork.ozlabs.org/project/uboot/patch/20200820105445.23029-1-xypr...
This is the output from the Kendryte K210:
=> setenv efi_selftest 'reset system' => bootefi selftest Found 0 disks
Testing EFI API implementation
Selected test: 'reset system'
Setting up 'reset system' Setting up 'reset system' succeeded
Executing 'reset system' resetting ...
Best regards
Heinrich
On Thu, 20 Aug 2020 10:35:31 PDT (-0700), xypron.glpk@gmx.de wrote:
On 8/20/20 6:45 PM, David Abdurachmanov wrote:
+Al Stone.
On Thu, Aug 20, 2020 at 6:46 PM Grant Likely grant.likely@arm.com wrote:
Hi Atish,
I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms.
g.
On 20/08/2020 01:03, Atish Patra wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers.
Yes, I will accept RISC-V content
- The specification is licensed under Creative Commons. The RISC-V
related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that.
Yes
- It should be okay to add other copyrights in addition to "Arm
Limited and Contributors".
That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting.
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.
I don't expect issues adding EFI_RESET_SYSTEM for FU540 (the reference platform majority of developers are using). It's basically GPIO active low to reset the SoC.
https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hif...
We should have GPIO support for FU540 in U-Boot thus we can do something similar to this: https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layersca...
A small thing compared to everything else, but we probably can get EFI_RESET_SYSTEM working for FU540.
In U-Boot: CONFIG_SYSRESET=y for sifive_fu540_defconfig.
The device tree has
gpio-restart { compatible = "gpio-restart"; gpios = <0x0c 0x0a 0x01>; };Is there really anything missing for the SiFive HiFive Unleashed?
The hardware to actually reset the chip :). SiFive's reset methadology is to minimize the set of flops with reset pins, which means the devices aren't reset and can be put in states where they will proceed to lock up the bus after reset comes back up.
The following patch allows you to test if the UEFI ResetSystem() service is working when you compile with
CONFIG_EFI_LOADER=y CONFIG_EFI_SELFTEST=y
[1/1] efi_selftest: add a test for ResetSystem() https://lists.denx.de/pipermail/u-boot/2020-August/424075.html https://patchwork.ozlabs.org/project/uboot/patch/20200820105445.23029-1-xypr...
This is the output from the Kendryte K210:
=> setenv efi_selftest 'reset system' => bootefi selftest Found 0 disks
Testing EFI API implementation
Selected test: 'reset system'
Setting up 'reset system' Setting up 'reset system' succeeded
Executing 'reset system' resetting ...
Best regards
Heinrich
On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 6:45 PM, David Abdurachmanov wrote:
+Al Stone.
On Thu, Aug 20, 2020 at 6:46 PM Grant Likely grant.likely@arm.com
wrote:
Hi Atish,
I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms.
g.
On 20/08/2020 01:03, Atish Patra wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers.
Yes, I will accept RISC-V content
- The specification is licensed under Creative Commons. The RISC-V
related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that.
Yes
- It should be okay to add other copyrights in addition to "Arm
Limited and Contributors".
That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting.
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.
I don't expect issues adding EFI_RESET_SYSTEM for FU540 (the reference platform majority of developers are using). It's basically GPIO active low to reset the SoC.
https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hif...
We should have GPIO support for FU540 in U-Boot thus we can do something similar to this:
https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layersca...
A small thing compared to everything else, but we probably can get EFI_RESET_SYSTEM working for FU540.
In U-Boot: CONFIG_SYSRESET=y for sifive_fu540_defconfig.
The device tree has
gpio-restart { compatible = "gpio-restart"; gpios = <0x0c 0x0a 0x01>; };Is there really anything missing for the SiFive HiFive Unleashed?
The following patch allows you to test if the UEFI ResetSystem() service is working when you compile with
CONFIG_EFI_LOADER=y CONFIG_EFI_SELFTEST=y
[1/1] efi_selftest: add a test for ResetSystem() https://lists.denx.de/pipermail/u-boot/2020-August/424075.html
https://patchwork.ozlabs.org/project/uboot/patch/20200820105445.23029-1-xypr...
This is the output from the Kendryte K210:
=> setenv efi_selftest 'reset system' => bootefi selftest Found 0 disks
Testing EFI API implementation
Selected test: 'reset system'
Setting up 'reset system' Setting up 'reset system' succeeded
Executing 'reset system' resetting ...
I don't think it actually reset the system. It just calls hang(). Is there an outstanding patch in U-Boot that I don't know about ? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/riscv/lib/reset.c#L1...
Best regards
Heinrich
On 8/20/20 8:10 PM, Atish Patra wrote:
On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:
On 8/20/20 6:45 PM, David Abdurachmanov wrote: > +Al Stone. > > On Thu, Aug 20, 2020 at 6:46 PM Grant Likely <grant.likely@arm.com <mailto:grant.likely@arm.com>> wrote: >> >> Hi Atish, >> >> I'm happy to add RISC-V content to EBBR. EBBR was originated as a >> community driven document, and though it was created to solve problems >> in the Arm ecosystem, it is not limited to Arm platforms. >> >> g. >> >> On 20/08/2020 01:03, Atish Patra wrote: >>> Hi All, >>> We are interested in adopting EBBR as the boot specification for the >>> embedded RISC-V platforms. >>> We firmly believe that EBBR is a very well defined specification for >>> boot requirement and there >>> is no need for reinventing the wheel for RISC-V. Hence, this is a >>> thread to discuss all the requirements >>> for adding RISC-V to EBBR. Here is my current understanding. Please >>> correct me if I am wrong. >>> >>> Logistic Requirement: >>> 1. As per the contribution guidelines[1], patches should be sent to >>> boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. >>> and the specification will be hosted under "ARM-software" Github. >>> I am hoping that introducing RISC-V >>> related changes are okay with the current maintainers. >> >> Yes, I will accept RISC-V content >> >>> 2. The specification is licensed under Creative Commons. The RISC-V >>> related changes will refer to >>> some of the RISC-V specifications as well. AFAIK, there shouldn't >>> be an issue with that. >> >> Yes >> >>> 3. It should be okay to add other copyrights in addition to "Arm >>> Limited and Contributors". >> >> That statement reflects the origin of the document, and I haven't >> changed it because I did want a long list of copyright holders on the >> front page. Go ahead and propose changes to the formatting. >> >>> Technical Requirement: >>> 1. Software status: >>> a. UEFI support for RISC-V Linux kernel is already available in >>> the mailing list[2]. The targeted upstream >>> merge is the 5.10 merge window. >>> b. U-Boot already supports UEFI for RISC-V. >>> c. EDK2 upstreaming is currently under progress [3] as well. >>> >>> Is it okay to start sending patches for EBBR RISC-V related changes >>> now or do we need to wait for EDK2 and Linux >>> kernel patches to be available upstream ? >> >> Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but >> the general guidance on EBBR is to only require features that are >> achievable. If any feature isn't feasible in the near future, then I'd >> caution against adding it to EBBR. >> >>> 2. RISC-V related sections in EBBR >>> a. UEFI: >>> Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot >>> service as firmware doesn't have a standard way >>> to reset the system. There is a proposal to add a system reset >>> function to Supervisor Binary Specification(SBI) which >>> can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from >>> that, I believe RISC-V supports all UEFI boot and >>> run time services mandated by EBBR. Is it a blocker for RISC-V >>> EBBR compatibility? >> >> Reset system if a fundamental interface. I'm not keen to relax this >> requirement. > > I don't expect issues adding EFI_RESET_SYSTEM for FU540 (the reference > platform majority of developers are using). It's basically GPIO active > low to reset the SoC. > > https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts#L45 > > We should have GPIO support for FU540 in U-Boot thus we can do > something similar to this: > https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layerscape/cpu.c#L1248 > > A small thing compared to everything else, but we probably can get > EFI_RESET_SYSTEM working for FU540. > In U-Boot: CONFIG_SYSRESET=y for sifive_fu540_defconfig. The device tree has gpio-restart { compatible = "gpio-restart"; gpios = <0x0c 0x0a 0x01>; }; Is there really anything missing for the SiFive HiFive Unleashed? The following patch allows you to test if the UEFI ResetSystem() service is working when you compile with CONFIG_EFI_LOADER=y CONFIG_EFI_SELFTEST=y [1/1] efi_selftest: add a test for ResetSystem() https://lists.denx.de/pipermail/u-boot/2020-August/424075.html https://patchwork.ozlabs.org/project/uboot/patch/20200820105445.23029-1-xypron.glpk@gmx.de/ This is the output from the Kendryte K210: => setenv efi_selftest 'reset system' => bootefi selftest Found 0 disks Testing EFI API implementation Selected test: 'reset system' Setting up 'reset system' Setting up 'reset system' succeeded Executing 'reset system' resetting ...
The Kendryte K210 uses
CONFIG_SYSRESET=y CONFIG_RESET_SYSCON=y
So arch/riscv/lib/reset.c is not compiled.
The reset is effected in function syscon_reboot_request() using the register defined in the device tree by arch/riscv/dts/k210.dtsi:
reboot { compatible = "syscon-reboot"; regmap = <&sysctl>; offset = <K210_SYSCTL_SOFT_RESET>; mask = <1>; value = <1>; };
Best regards
Heinrich
I don't think it actually reset the system. It just calls hang(). Is there an outstanding patch in U-Boot that I don't know about ? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/riscv/lib/reset.c#L1...
Best regards Heinrich-- Regards, Atish
On Thu, Aug 20, 2020 at 12:39 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 8:10 PM, Atish Patra wrote:
On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:
On 8/20/20 6:45 PM, David Abdurachmanov wrote: > +Al Stone. > > On Thu, Aug 20, 2020 at 6:46 PM Grant Likely <grant.likely@arm.com <mailto:grant.likely@arm.com>> wrote: >> >> Hi Atish, >> >> I'm happy to add RISC-V content to EBBR. EBBR was originated as a >> community driven document, and though it was created to solve problems >> in the Arm ecosystem, it is not limited to Arm platforms. >> >> g. >> >> On 20/08/2020 01:03, Atish Patra wrote: >>> Hi All, >>> We are interested in adopting EBBR as the boot specification forthe
>>> embedded RISC-V platforms. >>> We firmly believe that EBBR is a very well defined specificationfor
>>> boot requirement and there >>> is no need for reinventing the wheel for RISC-V. Hence, this is a >>> thread to discuss all the requirements >>> for adding RISC-V to EBBR. Here is my current understanding.Please
>>> correct me if I am wrong. >>> >>> Logistic Requirement: >>> 1. As per the contribution guidelines[1], patches should be sentto
>>> boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. >>> and the specification will be hosted under "ARM-software" Github. >>> I am hoping that introducing RISC-V >>> related changes are okay with the current maintainers. >> >> Yes, I will accept RISC-V content >> >>> 2. The specification is licensed under Creative Commons. TheRISC-V
>>> related changes will refer to >>> some of the RISC-V specifications as well. AFAIK, there shouldn't >>> be an issue with that. >> >> Yes >> >>> 3. It should be okay to add other copyrights in addition to "Arm >>> Limited and Contributors". >> >> That statement reflects the origin of the document, and I haven't >> changed it because I did want a long list of copyright holders onthe
>> front page. Go ahead and propose changes to the formatting. >> >>> Technical Requirement: >>> 1. Software status: >>> a. UEFI support for RISC-V Linux kernel is alreadyavailable in
>>> the mailing list[2]. The targeted upstream >>> merge is the 5.10 merge window. >>> b. U-Boot already supports UEFI for RISC-V. >>> c. EDK2 upstreaming is currently under progress [3] as well. >>> >>> Is it okay to start sending patches for EBBR RISC-V related changes >>> now or do we need to wait for EDK2 and Linux >>> kernel patches to be available upstream ? >> >> Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but >> the general guidance on EBBR is to only require features that are >> achievable. If any feature isn't feasible in the near future, then I'd >> caution against adding it to EBBR. >> >>> 2. RISC-V related sections in EBBR >>> a. UEFI: >>> Currently, RISC-V doesn't support a EFI_RESET_SYSTEMboot
>>> service as firmware doesn't have a standard way >>> to reset the system. There is a proposal to add a system reset >>> function to Supervisor Binary Specification(SBI) which >>> can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from >>> that, I believe RISC-V supports all UEFI boot and >>> run time services mandated by EBBR. Is it a blocker for RISC-V >>> EBBR compatibility? >> >> Reset system if a fundamental interface. I'm not keen to relaxthis
>> requirement. > > I don't expect issues adding EFI_RESET_SYSTEM for FU540 (thereference
> platform majority of developers are using). It's basically GPIOactive
> low to reset the SoC. > >https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hif...
> > We should have GPIO support for FU540 in U-Boot thus we can do > something similar to this: >https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layersca...
> > A small thing compared to everything else, but we probably can get > EFI_RESET_SYSTEM working for FU540. > In U-Boot: CONFIG_SYSRESET=y for sifive_fu540_defconfig. The device tree has gpio-restart { compatible = "gpio-restart"; gpios = <0x0c 0x0a 0x01>; }; Is there really anything missing for the SiFive HiFive Unleashed? The following patch allows you to test if the UEFI ResetSystem()service
is working when you compile with CONFIG_EFI_LOADER=y CONFIG_EFI_SELFTEST=y [1/1] efi_selftest: add a test for ResetSystem() https://lists.denx.de/pipermail/u-boot/2020-August/424075.htmlhttps://patchwork.ozlabs.org/project/uboot/patch/20200820105445.23029-1-xypr...
This is the output from the Kendryte K210: => setenv efi_selftest 'reset system' => bootefi selftest Found 0 disks Testing EFI API implementation Selected test: 'reset system' Setting up 'reset system' Setting up 'reset system' succeeded Executing 'reset system' resetting ...The Kendryte K210 uses
CONFIG_SYSRESET=y CONFIG_RESET_SYSCON=y
So arch/riscv/lib/reset.c is not compiled.
The reset is effected in function syscon_reboot_request() using the register defined in the device tree by arch/riscv/dts/k210.dtsi:
Ahh I missed that. Thanks.
reboot { compatible = "syscon-reboot"; regmap = <&sysctl>; offset = <K210_SYSCTL_SOFT_RESET>; mask = <1>; value = <1>; };
Best regards
Heinrich
I don't think it actually reset the system. It just calls hang(). Is there an outstanding patch in U-Boot that I don't know about ?
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/riscv/lib/reset.c#L1...
Best regards Heinrich-- Regards, Atish
+Paul
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely grant.likely@arm.com wrote:
Hi Atish,
I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms.
g.
On 20/08/2020 01:03, Atish Patra wrote:
Hi All, We are interested in adopting EBBR as the boot specification for the embedded RISC-V platforms. We firmly believe that EBBR is a very well defined specification for boot requirement and there is no need for reinventing the wheel for RISC-V. Hence, this is a thread to discuss all the requirements for adding RISC-V to EBBR. Here is my current understanding. Please correct me if I am wrong.
Logistic Requirement:
- As per the contribution guidelines[1], patches should be sent to
boot-architecture@lists.linaro.org. and the specification will be hosted under "ARM-software" Github. I am hoping that introducing RISC-V related changes are okay with the current maintainers.
Yes, I will accept RISC-V content
- The specification is licensed under Creative Commons. The RISC-V
related changes will refer to some of the RISC-V specifications as well. AFAIK, there shouldn't be an issue with that.
Yes
- It should be okay to add other copyrights in addition to "Arm
Limited and Contributors".
That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting.
Technical Requirement:
- Software status: a. UEFI support for RISC-V Linux kernel is already available in
the mailing list[2]. The targeted upstream merge is the 5.10 merge window. b. U-Boot already supports UEFI for RISC-V. c. EDK2 upstreaming is currently under progress [3] as well.
Is it okay to start sending patches for EBBR RISC-V related changes now or do we need to wait for EDK2 and Linux kernel patches to be available upstream ?
Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.
Got it. Thanks for the clarification.
- RISC-V related sections in EBBR a. UEFI: Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot
service as firmware doesn't have a standard way to reset the system. There is a proposal to add a system reset function to Supervisor Binary Specification(SBI) which can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from that, I believe RISC-V supports all UEFI boot and run time services mandated by EBBR. Is it a blocker for RISC-V EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.
As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 8/20/20 9:32 PM, Atish Patra wrote:
+Paul
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
Hi Atish, I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms. g. On 20/08/2020 01:03, Atish Patra wrote: > Hi All, > We are interested in adopting EBBR as the boot specification for the > embedded RISC-V platforms. > We firmly believe that EBBR is a very well defined specification for > boot requirement and there > is no need for reinventing the wheel for RISC-V. Hence, this is a > thread to discuss all the requirements > for adding RISC-V to EBBR. Here is my current understanding. Please > correct me if I am wrong. > > Logistic Requirement: > 1. As per the contribution guidelines[1], patches should be sent to > boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. > and the specification will be hosted under "ARM-software" Github. > I am hoping that introducing RISC-V > related changes are okay with the current maintainers. Yes, I will accept RISC-V content > 2. The specification is licensed under Creative Commons. The RISC-V > related changes will refer to > some of the RISC-V specifications as well. AFAIK, there shouldn't > be an issue with that. Yes > 3. It should be okay to add other copyrights in addition to "Arm > Limited and Contributors". That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting. > Technical Requirement: > 1. Software status: > a. UEFI support for RISC-V Linux kernel is already available in > the mailing list[2]. The targeted upstream > merge is the 5.10 merge window. > b. U-Boot already supports UEFI for RISC-V. > c. EDK2 upstreaming is currently under progress [3] as well. > > Is it okay to start sending patches for EBBR RISC-V related changes > now or do we need to wait for EDK2 and Linux > kernel patches to be available upstream ? Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.Got it. Thanks for the clarification.
> 2. RISC-V related sections in EBBR > a. UEFI: > Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot > service as firmware doesn't have a standard way > to reset the system. There is a proposal to add a system reset > function to Supervisor Binary Specification(SBI) which > can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from > that, I believe RISC-V supports all UEFI boot and > run time services mandated by EBBR. Is it a blocker for RISC-V > EBBR compatibility? Reset system if a fundamental interface. I'm not keen to relax this requirement.As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
Usages of the service can be found in:
* GRUB (command reboot) * iPXE (commands reboot, poweroff) * EFI shell (command reset)
Linux uses it in
* arch/x86/kernel/reboot.c * arch/arm64/kernel/process.c
via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
Best regards
Heinrich
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.-- Regards, Atish
On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 9:32 PM, Atish Patra wrote:
+Paul
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
Hi Atish, I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms. g. On 20/08/2020 01:03, Atish Patra wrote: > Hi All, > We are interested in adopting EBBR as the boot specification for the > embedded RISC-V platforms. > We firmly believe that EBBR is a very well defined specification for > boot requirement and there > is no need for reinventing the wheel for RISC-V. Hence, this is a > thread to discuss all the requirements > for adding RISC-V to EBBR. Here is my current understanding. Please > correct me if I am wrong. > > Logistic Requirement: > 1. As per the contribution guidelines[1], patches should be sent to > boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. > and the specification will be hosted under "ARM-software" Github. > I am hoping that introducing RISC-V > related changes are okay with the current maintainers. Yes, I will accept RISC-V content > 2. The specification is licensed under Creative Commons. The RISC-V > related changes will refer to > some of the RISC-V specifications as well. AFAIK, there shouldn't > be an issue with that. Yes > 3. It should be okay to add other copyrights in addition to "Arm > Limited and Contributors". That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting. > Technical Requirement: > 1. Software status: > a. UEFI support for RISC-V Linux kernel is already available in > the mailing list[2]. The targeted upstream > merge is the 5.10 merge window. > b. U-Boot already supports UEFI for RISC-V. > c. EDK2 upstreaming is currently under progress [3] as well. > > Is it okay to start sending patches for EBBR RISC-V related changes > now or do we need to wait for EDK2 and Linux > kernel patches to be available upstream ? Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.Got it. Thanks for the clarification.
> 2. RISC-V related sections in EBBR > a. UEFI: > Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot > service as firmware doesn't have a standard way > to reset the system. There is a proposal to add a system reset > function to Supervisor Binary Specification(SBI) which > can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from > that, I believe RISC-V supports all UEFI boot and > run time services mandated by EBBR. Is it a blocker for RISC-V > EBBR compatibility? Reset system if a fundamental interface. I'm not keen to relax this requirement.As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
Usages of the service can be found in:
- GRUB (command reboot)
- iPXE (commands reboot, poweroff)
- EFI shell (command reset)
Linux uses it in
- arch/x86/kernel/reboot.c
- arch/arm64/kernel/process.c
via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
As per my understanding, efi_reboot uses the runtime efi service that gets called after ExitBootService(). This is marked optional in the EBBR spec. I was talking about the reset_system user as a boot service.
As per EBBR spec, "ResetSystem() is required to be implemented in boot services, but it is optional for runtime services"
Best regards
Heinrich
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.-- Regards, Atish
On 8/20/20 10:09 PM, Atish Patra wrote:
On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 9:32 PM, Atish Patra wrote:
+Paul
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
Hi Atish, I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms. g. On 20/08/2020 01:03, Atish Patra wrote: > Hi All, > We are interested in adopting EBBR as the boot specification for the > embedded RISC-V platforms. > We firmly believe that EBBR is a very well defined specification for > boot requirement and there > is no need for reinventing the wheel for RISC-V. Hence, this is a > thread to discuss all the requirements > for adding RISC-V to EBBR. Here is my current understanding. Please > correct me if I am wrong. > > Logistic Requirement: > 1. As per the contribution guidelines[1], patches should be sent to > boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. > and the specification will be hosted under "ARM-software" Github. > I am hoping that introducing RISC-V > related changes are okay with the current maintainers. Yes, I will accept RISC-V content > 2. The specification is licensed under Creative Commons. The RISC-V > related changes will refer to > some of the RISC-V specifications as well. AFAIK, there shouldn't > be an issue with that. Yes > 3. It should be okay to add other copyrights in addition to "Arm > Limited and Contributors". That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting. > Technical Requirement: > 1. Software status: > a. UEFI support for RISC-V Linux kernel is already available in > the mailing list[2]. The targeted upstream > merge is the 5.10 merge window. > b. U-Boot already supports UEFI for RISC-V. > c. EDK2 upstreaming is currently under progress [3] as well. > > Is it okay to start sending patches for EBBR RISC-V related changes > now or do we need to wait for EDK2 and Linux > kernel patches to be available upstream ? Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.Got it. Thanks for the clarification.
> 2. RISC-V related sections in EBBR > a. UEFI: > Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot > service as firmware doesn't have a standard way > to reset the system. There is a proposal to add a system reset > function to Supervisor Binary Specification(SBI) which > can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from > that, I believe RISC-V supports all UEFI boot and > run time services mandated by EBBR. Is it a blocker for RISC-V > EBBR compatibility? Reset system if a fundamental interface. I'm not keen to relax this requirement.As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
Usages of the service can be found in:
- GRUB (command reboot)
- iPXE (commands reboot, poweroff)
- EFI shell (command reset)
Linux uses it in
- arch/x86/kernel/reboot.c
- arch/arm64/kernel/process.c
via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
As per my understanding, efi_reboot uses the runtime efi service that gets called after ExitBootService(). This is marked optional in the EBBR spec. I was talking about the reset_system user as a boot service.
As per EBBR spec, "ResetSystem() is required to be implemented in boot services, but it is optional for runtime services"
Yes, only GRUB, iPXE, and EFI shell are usages before ExitBootServices().
If you want an operating system example of usage before ExitBootServices():
OpenBSD has a boot prompt that is executed before ExitBootServices() and offers commands 'reboot' and 'poweroff' via UEFI's ResetSystem().
Best regards
Heinrich
On Thu, Aug 20, 2020 at 1:40 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 10:09 PM, Atish Patra wrote:
On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 9:32 PM, Atish Patra wrote:
+Paul
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
Hi Atish, I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms. g. On 20/08/2020 01:03, Atish Patra wrote: > Hi All, > We are interested in adopting EBBR as the boot specification for the > embedded RISC-V platforms. > We firmly believe that EBBR is a very well defined specification for > boot requirement and there > is no need for reinventing the wheel for RISC-V. Hence, this is a > thread to discuss all the requirements > for adding RISC-V to EBBR. Here is my current understanding. Please > correct me if I am wrong. > > Logistic Requirement: > 1. As per the contribution guidelines[1], patches should be sent to > boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. > and the specification will be hosted under "ARM-software" Github. > I am hoping that introducing RISC-V > related changes are okay with the current maintainers. Yes, I will accept RISC-V content > 2. The specification is licensed under Creative Commons. The RISC-V > related changes will refer to > some of the RISC-V specifications as well. AFAIK, there shouldn't > be an issue with that. Yes > 3. It should be okay to add other copyrights in addition to "Arm > Limited and Contributors". That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting. > Technical Requirement: > 1. Software status: > a. UEFI support for RISC-V Linux kernel is already available in > the mailing list[2]. The targeted upstream > merge is the 5.10 merge window. > b. U-Boot already supports UEFI for RISC-V. > c. EDK2 upstreaming is currently under progress [3] as well. > > Is it okay to start sending patches for EBBR RISC-V related changes > now or do we need to wait for EDK2 and Linux > kernel patches to be available upstream ? Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.Got it. Thanks for the clarification.
> 2. RISC-V related sections in EBBR > a. UEFI: > Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot > service as firmware doesn't have a standard way > to reset the system. There is a proposal to add a system reset > function to Supervisor Binary Specification(SBI) which > can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from > that, I believe RISC-V supports all UEFI boot and > run time services mandated by EBBR. Is it a blocker for RISC-V > EBBR compatibility? Reset system if a fundamental interface. I'm not keen to relax this requirement.As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
Usages of the service can be found in:
- GRUB (command reboot)
- iPXE (commands reboot, poweroff)
- EFI shell (command reset)
Linux uses it in
- arch/x86/kernel/reboot.c
- arch/arm64/kernel/process.c
via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
As per my understanding, efi_reboot uses the runtime efi service that gets called after ExitBootService(). This is marked optional in the EBBR spec. I was talking about the reset_system user as a boot service.
As per EBBR spec, "ResetSystem() is required to be implemented in boot services, but it is optional for runtime services"
Yes, only GRUB, iPXE, and EFI shell are usages before ExitBootServices().
If you want an operating system example of usage before ExitBootServices():
OpenBSD has a boot prompt that is executed before ExitBootServices() and offers commands 'reboot' and 'poweroff' via UEFI's ResetSystem().
Got it. Thanks.
Best regards
Heinrich
On Fri, Aug 21, 2020 at 1:39 AM Atish Patra atishp@atishpatra.org wrote:
On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 9:32 PM, Atish Patra wrote:
+Paul
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
Hi Atish, I'm happy to add RISC-V content to EBBR. EBBR was originated as a community driven document, and though it was created to solve problems in the Arm ecosystem, it is not limited to Arm platforms. g. On 20/08/2020 01:03, Atish Patra wrote: > Hi All, > We are interested in adopting EBBR as the boot specification for the > embedded RISC-V platforms. > We firmly believe that EBBR is a very well defined specification for > boot requirement and there > is no need for reinventing the wheel for RISC-V. Hence, this is a > thread to discuss all the requirements > for adding RISC-V to EBBR. Here is my current understanding. Please > correct me if I am wrong. > > Logistic Requirement: > 1. As per the contribution guidelines[1], patches should be sent to > boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. > and the specification will be hosted under "ARM-software" Github. > I am hoping that introducing RISC-V > related changes are okay with the current maintainers. Yes, I will accept RISC-V content > 2. The specification is licensed under Creative Commons. The RISC-V > related changes will refer to > some of the RISC-V specifications as well. AFAIK, there shouldn't > be an issue with that. Yes > 3. It should be okay to add other copyrights in addition to "Arm > Limited and Contributors". That statement reflects the origin of the document, and I haven't changed it because I did want a long list of copyright holders on the front page. Go ahead and propose changes to the formatting. > Technical Requirement: > 1. Software status: > a. UEFI support for RISC-V Linux kernel is already available in > the mailing list[2]. The targeted upstream > merge is the 5.10 merge window. > b. U-Boot already supports UEFI for RISC-V. > c. EDK2 upstreaming is currently under progress [3] as well. > > Is it okay to start sending patches for EBBR RISC-V related changes > now or do we need to wait for EDK2 and Linux > kernel patches to be available upstream ? Landing features in mainline U-Boot/Linux/EDK2/etc. is not required, but the general guidance on EBBR is to only require features that are achievable. If any feature isn't feasible in the near future, then I'd caution against adding it to EBBR.Got it. Thanks for the clarification.
> 2. RISC-V related sections in EBBR > a. UEFI: > Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot > service as firmware doesn't have a standard way > to reset the system. There is a proposal to add a system reset > function to Supervisor Binary Specification(SBI) which > can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from > that, I believe RISC-V supports all UEFI boot and > run time services mandated by EBBR. Is it a blocker for RISC-V > EBBR compatibility? Reset system if a fundamental interface. I'm not keen to relax this requirement.As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
Usages of the service can be found in:
- GRUB (command reboot)
- iPXE (commands reboot, poweroff)
- EFI shell (command reset)
Linux uses it in
- arch/x86/kernel/reboot.c
- arch/arm64/kernel/process.c
via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
As per my understanding, efi_reboot uses the runtime efi service that gets called after ExitBootService(). This is marked optional in the EBBR spec. I was talking about the reset_system user as a boot service.
As per EBBR spec, "ResetSystem() is required to be implemented in boot services, but it is optional for runtime services"
The SBI Reset extension was proposed to address following problems in the RISC-V world:
1. When RISC-V system is partitioned into secure and non-secure worlds, the non-secure world should not reset/poweroff the system without going through a secure monitor. The SBI Reset extension provides an interface for the non-secure world to request system reset/poweroff.
2. Most hypervisors provide a para-virt machine to Guest/VM where most of the MMIO/PCIe devices are para-virt (e.g. VirtIO). There is not para-virt device dedicated for system reset/shutdown. Instead of letting each hypervsior coming-up with their own way of system reset/poweroff, it is best of provide a standard SBI Reset extension for this purpose.
Apart from above, the EFI_RESET_SYSTEM provider can also use the SBI reset call (just like PSCI SYSTEM_RESET in ARM world). This will allow EFI_RESET_SYSTEM work fine natively and inside Guest/VM without any hypervisor/platform specific changes.
The SBI extensions are defined as optional and we have probe the SBI extension once before using the SBI calls. This means the SBI reset extension is also optional and SBI implementations can choose not to implement it.
Regards, Anup
On Thu, Aug 20, 2020 at 01:09:03PM -0700, Atish Patra wrote:
On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 9:32 PM, Atish Patra wrote:
On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote: > 2. RISC-V related sections in EBBR > a. UEFI: > Currently, RISC-V doesn't support a EFI_RESET_SYSTEM boot > service as firmware doesn't have a standard way > to reset the system. There is a proposal to add a system reset > function to Supervisor Binary Specification(SBI) which > can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from > that, I believe RISC-V supports all UEFI boot and > run time services mandated by EBBR. Is it a blocker for RISC-V > EBBR compatibility?
Reset system if a fundamental interface. I'm not keen to relax this requirement.As per the specification, Reset system is only mandatory for boot services. But I couldn't find anything in the EFI stub in the kernel that actually invokes it. I see only watchdog in U-boot using it to comply with the watchdog requirement of UEFI spec. I am not sure if EDK2 has other usages. Is it supposed to be used by the firmware/boot loader only ?
Usages of the service can be found in:
- GRUB (command reboot)
- iPXE (commands reboot, poweroff)
- EFI shell (command reset)
Linux uses it in
- arch/x86/kernel/reboot.c
- arch/arm64/kernel/process.c
via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
As per my understanding, efi_reboot uses the runtime efi service that gets called after ExitBootService(). This is marked optional in the EBBR spec. I was talking about the reset_system user as a boot service.
As per EBBR spec, "ResetSystem() is required to be implemented in boot services, but it is optional for runtime services"
That might actually be an Armism creeping in!
IIRC reboot discussions were annoyingly complex because, on Arm, systems both UEFI *and* PSCI provided a means to reboot the device (and naturally there had been historic firmware bugs where only one of them worked). Hence the language about falling back to architecture specific things (e.g. PSCI).
If RISC-V platforms don't have any alternative architecture specific approaches then they are would likely benefit from ResetSystem() being mandatory.
Daniel.
boot-architecture@lists.linaro.org
-
Anup Patel -
Ard Biesheuvel -
Atish Patra -
Chang, Abner (HPS SW/FW Technologist) -
Daniel Thompson -
David Abdurachmanov -
François Ozog -
Grant Likely -
Heinrich Schuchardt -
Palmer Dabbelt