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 ...
Best regards
Heinrich
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
