On Thu, Aug 20, 2020 at 10:35 AM Heinrich Schuchardt 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
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:
- As per the contribution guidelines[1], patches should be sent to
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
- 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
- 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:
- 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.
- 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/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.html
https://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 ...
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