On 8/20/20 10:09 PM, Atish Patra wrote:
> On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt <[email protected]> 
> wrote:
>>
>> On 8/20/20 9:32 PM, Atish Patra wrote:
>>> +Paul
>>>
>>> On Thu, Aug 20, 2020 at 8:46 AM 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.
>>>
>>>
>>> Got it. Thanks for the clarification.
>>>
>>>
>>>     > 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.
>>>
>>>
>>> As per the specification, Reset system is only mandatory for boot
>>> services. But I couldn't find anything in the EFI stub in the kernel
>>> that actually invokes it. I see only watchdog in U-boot using it to
>>> comply with the watchdog requirement of UEFI spec.
>>> I am not sure if EDK2 has other usages. Is it supposed to be used by the
>>> firmware/boot loader only ?
>>
>> Usages of the service can be found in:
>>
>> * GRUB (command reboot)
>> * iPXE (commands reboot, poweroff)
>> * EFI shell (command reset)
>>
>> Linux uses it in
>>
>> * arch/x86/kernel/reboot.c
>> * arch/arm64/kernel/process.c
>>
>> via function efi_reboot() implemented in drivers/firmware/efi/reboot.c.
>>
> As per my understanding, efi_reboot uses the runtime efi service that
> gets called after ExitBootService().
> This is marked optional in the EBBR spec. I was talking about the
> reset_system user as a boot service.
>
> As per EBBR spec,
> "ResetSystem() is required to be implemented in boot services, but it
> is optional for runtime services"
>

Yes, only GRUB, iPXE, and EFI shell are usages before ExitBootServices().

If you want an operating system example of usage before ExitBootServices():

OpenBSD has a boot prompt that is executed before ExitBootServices() and
offers commands 'reboot' and 'poweroff' via UEFI's ResetSystem().

Best regards

Heinrich
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to