> -----Original Message----- > From: Chang, Abner (HPS SW/FW Technologist) > Sent: Tuesday, September 22, 2020 9:11 AM > To: Atish Patra <[email protected]>; Heinrich Schuchardt > <[email protected]> > Cc: Atish Patra <[email protected]>; [email protected]; > Grant Likely <[email protected]>; Ard Biesheuvel <[email protected]>; > Rick Chen <[email protected]> > Subject: RE: EBBR: RISC-V handoff to OS > > > > > -----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.m > > > d 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. I add below sentence at the end of section 2.3.7.3. " See “Link to UEFI Specification-Related Document” on https://uefi.org/uefi under the heading “RISC-EFL psABI Specification” for the more descriptions of RISC-V calling convention."
> > > > > 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
