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. > > > 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
