On Thu, 23 Apr 2020 at 13:15, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Wed, 22 Apr 2020 at 20:48, Atish Patra <Atish.Patra@xxxxxxx> wrote: > > > > On Wed, 2020-04-22 at 19:24 +0200, Ard Biesheuvel wrote: > > > From: Atish Patra <atish.patra@xxxxxxx> > > > > > > Add a RISC-V architecture specific stub code that actually copies the > > > actual kernel image to a valid address and jump to it after boot > > > services > > > are terminated. Enable UEFI related kernel configs as well for RISC- > > > V. > > > > > > Signed-off-by: Atish Patra <atish.patra@xxxxxxx> > > > Link: > > > https://lore.kernel.org/r/20200421033336.9663-4-atish.patra@xxxxxxx > > > [ardb: - move hartid fetch into check_platform_features() > > > - use image_size not reserve_size > > > - moved asm/efi.h addition into separate patch ] > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > --- > > > arch/riscv/Kconfig | 20 ++++ > > > arch/riscv/Makefile | 1 + > > > arch/riscv/configs/defconfig | 1 + > > > drivers/firmware/efi/Kconfig | 4 +- > > > drivers/firmware/efi/libstub/Makefile | 10 ++ > > > drivers/firmware/efi/libstub/riscv-stub.c | 109 ++++++++++++++++++++ > > > 6 files changed, 143 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > index f05dd09acd48..54c78cafcd35 100644 > > > --- a/arch/riscv/Kconfig > > > +++ b/arch/riscv/Kconfig > > > @@ -379,10 +379,30 @@ config CMDLINE_FORCE > > > > > > endchoice > > > > > > +config EFI_STUB > > > + bool > > > + > > > +config EFI > > > + bool "UEFI runtime support" > > > + depends on OF > > > + select LIBFDT > > > + select UCS2_STRING > > > + select EFI_PARAMS_FROM_FDT > > > + select EFI_STUB > > > + select EFI_GENERIC_STUB > > > > As palmer suggested RISCV_ISA_C should be selected here to avoid > > unintentional errors. Otherwise, every looks good. > > > > Ah, I must have misunderstood. I thought using c.li instead of li was > sufficient here. > > > In any case, once Palmer confirms that he is ok with the approach I > suggested, he can fix that up when applying the patches. > Actually, I can do slightly better, and put the asm/efi.h patch back into this one. I'll do a respin once we've agreed that this is the approach we are taking.
