On Thu, 20 Aug 2020 at 14:55, Chang, Abner (HPS SW/FW Technologist) < [email protected]> wrote:
> > > > > *From:* François Ozog [mailto:[email protected]] > *Sent:* Thursday, August 20, 2020 7:38 PM > *To:* Chang, Abner (HPS SW/FW Technologist) <[email protected]> > *Cc:* Ard Biesheuvel <[email protected]>; Atish Patra <[email protected]>; > Grant Likely <[email protected]>; Boot Architecture Mailman List < > [email protected]>; Anup Patel <[email protected]>; > David Abdurachmanov <[email protected]>; Palmer Dabbelt < > [email protected]>; Heinrich Schuchardt <[email protected]>; Schaefer, > Daniel <[email protected]> > *Subject:* Re: Adding RISC-V to EBBR > > > > > > > > On Thu, 20 Aug 2020 at 12:48, Chang, Abner (HPS SW/FW Technologist) < > [email protected]> wrote: > > *From:* François Ozog [mailto:[email protected]] > *Sent:* Thursday, August 20, 2020 6:19 PM > *To:* Chang, Abner (HPS SW/FW Technologist) <[email protected]> > *Cc:* Ard Biesheuvel <[email protected]>; Atish Patra <[email protected]>; > Grant Likely <[email protected]>; Boot Architecture Mailman List < > [email protected]>; Anup Patel <[email protected]>; > David Abdurachmanov <[email protected]>; Palmer Dabbelt < > [email protected]>; Heinrich Schuchardt <[email protected]>; Schaefer, > Daniel <[email protected]> > *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) < > [email protected]> 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 **J* > *.* > You are right: because of Trusted Substrate, EBBR shall reference other interfaces/standards than UEFI. Candidates are, for instance, Parsec, PSA-API, TBFU... > 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 Android <https://aka.ms/ghei36> > ------------------------------ > > *From:* Ard Biesheuvel <[email protected]> > *Sent:* Thursday, August 20, 2020 2:45:38 PM > *To:* Atish Patra <[email protected]>; Grant Likely < > [email protected]>; François Ozog <[email protected]> > *Cc:* Boot Architecture Mailman List <[email protected]>; > Anup Patel <[email protected]>; David Abdurachmanov < > [email protected]>; Palmer Dabbelt <[email protected]>; > Heinrich Schuchardt <[email protected]>; Chang, Abner (HPS SW/FW > Technologist) <[email protected]>; Schaefer, Daniel < > [email protected]> > *Subject:* Re: Adding RISC-V to EBBR > > > > (+ Grant, Francois) > > On Thu, 20 Aug 2020 at 02:04, Atish Patra <[email protected]> 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 > > [email protected]. > > 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,20,2,0,76053051 > > [4] > 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 > > > > > -- > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > [email protected] | Skype: ffozog > > > > > > > -- > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > [email protected] | Skype: ffozog > > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
