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