On Thu, Aug 20, 2020 at 12:39 PM Heinrich Schuchardt <[email protected]> wrote:
> On 8/20/20 8:10 PM, Atish Patra wrote: > > > > > > On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt <[email protected] > > <mailto:[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] > > <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. > > >> > > >>> 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 ... > > The Kendryte K210 uses > > CONFIG_SYSRESET=y > CONFIG_RESET_SYSCON=y > > So arch/riscv/lib/reset.c is not compiled. > > The reset is effected in function syscon_reboot_request() using the > register defined in the device tree by arch/riscv/dts/k210.dtsi: > > Ahh I missed that. Thanks. > reboot { > compatible = "syscon-reboot"; > regmap = <&sysctl>; > offset = <K210_SYSCTL_SOFT_RESET>; > mask = <1>; > value = <1>; > }; > > Best regards > > Heinrich > > > > > > > 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 > > -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
