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