> -----Original Message----- > From: Atish Patra [mailto:[email protected]] > Sent: Tuesday, September 22, 2020 2:28 AM > To: Heinrich Schuchardt <[email protected]> > Cc: Atish Patra <[email protected]>; [email protected]; > Grant Likely <[email protected]>; Ard Biesheuvel <[email protected]>; > Rick Chen <[email protected]>; Chang, Abner (HPS SW/FW Technologist) > <[email protected]> > Subject: Re: EBBR: RISC-V handoff to OS > > 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). Yes, this is a pretty old section in UEFI spec even before OpenSBI as I can remember and haven't been updated to sync with latest status RISC-V works.
> > > > 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 ? Yes, the ECR was submitted to USWG for review, however the meeting canceled often recently and the process goes slow. I will keep following up > Maybe you also attach the latest ECR here for a broader review. I may not allowed to public ECR here unless all people in the mailing list are the members of UEFI org… but the sentence we revised in ECR is as below, "When UEFI firmware handoff control to Supervisor mode OS, RISC-V boot hart must be operated in Supervisor mode, and the memory addressing must be operated in Bare mode which is no memory address translation or protection through the virtual page table entry." We didn’t mention hand-off to M-Mode if CPU only support M-Mode because we only verified edk2 RISC-V port in S-Mode with OpenSBI, but didn’t try it on M-Mode even though the code is ready there. > > > 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 ? To have this external link is good, I will add this link in ECR. > > > 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
