+Al Stone. On Thu, Aug 20, 2020 at 6:46 PM Grant Likely <[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]. > > 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. > > > 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.
I don't expect issues adding EFI_RESET_SYSTEM for FU540 (the reference platform majority of developers are using). It's basically GPIO active low to reset the SoC. https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts#L45 We should have GPIO support for FU540 in U-Boot thus we can do something similar to this: https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layerscape/cpu.c#L1248 A small thing compared to everything else, but we probably can get EFI_RESET_SYSTEM working for FU540. david > > 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. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
