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