On Thu, 20 Aug 2020 10:35:31 PDT (-0700), [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 hardware to actually reset the chip :). SiFive's reset methadology is to
minimize the set of flops with reset pins, which means the devices aren't reset
and can be put in states where they will proceed to lock up the bus after reset
comes back up.
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 ...
Best regards
Heinrich
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
