On Thu, Aug 20, 2020 at 1:40 PM Heinrich Schuchardt <[email protected]> wrote: > > On 8/20/20 10:09 PM, Atish Patra wrote: > > On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt <[email protected]> > > wrote: > >> > >> On 8/20/20 9:32 PM, Atish Patra wrote: > >>> +Paul > >>> > >>> On Thu, Aug 20, 2020 at 8:46 AM Grant Likely <[email protected] > >>> <mailto:[email protected]>> 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 > >>> > [email protected] > >>> <mailto:[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. > >>> > >>> 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 -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
