> -----Original Message----- > From: Atish Patra [mailto:[email protected]] > Sent: Tuesday, September 22, 2020 2:08 PM > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]> > Cc: Heinrich Schuchardt <[email protected]>; 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 > > On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW Technologist) > <[email protected]> wrote: > > > > > > > > > -----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." > > > > Thanks. > > > 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. > > > > That's correct. We can't run UEFI applications run time services in M-mode as > it requires virtual memory in current setup. > I think it is better to keep that way there is a specific demand and value in > running UEFI applications in M-mode. > > > > > > > > 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. > > > > > Thanks again :). As per Heinrich's suggestion, it would also be good to add > some text about the state of gp & tp.
Ok. I add some text, copied from psABI spec. :) "........ Registers tp and gp should not be modified in the function, because signal handlers may rely upon their values. See “Link to UEFI Specification-Related Document” on https://uefi.org/uefi under the heading “RISC-V EFL psABI Specification” for the more descriptions of RISC-V calling convention." I will upload this update to USWG once Heinrich agrees with above. > > > > > 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 > > > > -- > Regards, > Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
