On Thu, Aug 20, 2020 at 12:39 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/20/20 8:10 PM, Atish Patra wrote:
On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:
On 8/20/20 6:45 PM, David Abdurachmanov wrote: > +Al Stone. > > On Thu, Aug 20, 2020 at 6:46 PM Grant Likely <grant.likely@arm.com <mailto:grant.likely@arm.com>> 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 forthe
>>> embedded RISC-V platforms. >>> We firmly believe that EBBR is a very well defined specificationfor
>>> 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 sentto
>>> boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org>. >>> 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. TheRISC-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 onthe
>> front page. Go ahead and propose changes to the formatting. >> >>> Technical Requirement: >>> 1. Software status: >>> a. UEFI support for RISC-V Linux kernel is alreadyavailable 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_SYSTEMboot
>>> 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 relaxthis
>> requirement. > > I don't expect issues adding EFI_RESET_SYSTEM for FU540 (thereference
> platform majority of developers are using). It's basically GPIOactive
> low to reset the SoC. > >https://github.com/torvalds/linux/blob/master/arch/riscv/boot/dts/sifive/hif...
> > 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-layersca...
> > 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.htmlhttps://patchwork.ozlabs.org/project/uboot/patch/20200820105445.23029-1-xypr...
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#L1...
Best regards Heinrich-- Regards, Atish