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" > 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 > -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
