On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt <[email protected]> wrote:
> On 8/20/20 6:45 PM, David Abdurachmanov wrote: > > +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. > > > > In U-Boot: CONFIG_SYSRESET=y for sifive_fu540_defconfig. > > The device tree has > > gpio-restart { > compatible = "gpio-restart"; > gpios = <0x0c 0x0a 0x01>; > }; > > Is there really anything missing for the SiFive HiFive Unleashed? > > The following patch allows you to test if the UEFI ResetSystem() service > is working when you compile with > > CONFIG_EFI_LOADER=y > CONFIG_EFI_SELFTEST=y > > [1/1] efi_selftest: add a test for ResetSystem() > https://lists.denx.de/pipermail/u-boot/2020-August/424075.html > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > > This is the output from the Kendryte K210: > > => setenv efi_selftest 'reset system' > => bootefi selftest > Found 0 disks > > Testing EFI API implementation > > Selected test: 'reset system' > > Setting up 'reset system' > Setting up 'reset system' succeeded > > Executing 'reset system' > resetting ... > > I don't think it actually reset the system. It just calls hang(). Is there an outstanding patch in U-Boot that I don't know about ? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/riscv/lib/reset.c#L10 > Best regards > > Heinrich > -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
