On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt <[email protected]> wrote:
>
> Hello Atish,
>
> the UEFI spec has this sentence:
>
> "When UEFI firmware handoff control to OS, the RISC-V is operated in
> machine-mode privilege." (M-mode is the equivalent to EL3 in ARM).
>
> This does not make any sense to me when using a secure execution
> environement (SEE) like OpenSBI.
>
> The hand-off should occur in S-Mode if the CPU supports it and only in
> M-Mode when the CPU only supports M-mode.
>
+Abner

Yes. Abner has already submitted an ECR for this & few other RISC-V related
changes to UEFI spec. I am not sure about the current status though.

@Abner: Do you know the latest status ?
Maybe you also attach the latest ECR here for a broader review.

> We should prescribe this in the EBBR and somehow get the UEFI spec fixed
> afterwards.
>

I will add it to the RISC-V EBBR PR (haven't sent it yet).

> An other issue is the calling convention. Chapter "2.3.7.3 Detailed
> Calling Convention" does not describe which registers are saved by the
> UEFI payload's entry point and restored by the payload before calling
> the UEFI API or returning to the UEFI payload. This concerns especially
> registers gp (x3) and tp (x4).
>
> Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF psABI
> specification"
> https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
> which is referenced by "The RISC-V Instruction Set Manual".
>
> From the "RISC-V ELF psABI specification" one might conclude that the
> UEFI payload should not be allowed to change gp and tp before calling
> ExitBootServices() or SetVirtualAddressMap() whichever occurs last.
>

Agreed. Thanks for pointing this out. I think this should go into the UEFI spec
instead of EBBR spec. Any suggestions ?

> Due to this missing clarification U-Boot is currently saving gp before
> calling the entry point of the payload and restores it on reentry or on
> entry of an API call. Nothing is done for tp.
>
> Best regards
>
> Heinrich
>
> _______________________________________________
> boot-architecture mailing list
> [email protected]
> https://lists.linaro.org/mailman/listinfo/boot-architecture



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

Reply via email to