Re: [RFC PATCH 0/5] Add UEFI support for RISC-V

[Atish Patra]

On Wed, 2020-02-26 at 15:46 -0800, Palmer Dabbelt wrote:
> On Tue, 25 Feb 2020 17:10:32 PST (-0800), Atish Patra wrote:
> > This series adds UEFI support for RISC-V. Currently, only boot time
> > services have been added. Runtime services will be added in a
> > separate
> > series. This series depends on some core EFI patches
> > present in current in efi-next and following other patches.
> > 
> > U-Boot: Adds the boot hartid under chosen node.
> > https://lists.denx.de/pipermail/u-boot/2020-February/401227.html
> > 
> > Linux kernel: SBI v0.2 and HSM extension support. This series is a
> > mandatory
> > pre-requisite for UEFI support as only single core can boot EFI
> > stub and
> > Linux via UEFI. All other cores are brought up using SBI HSM
> > extension.
> > http://lists.infradead.org/pipermail/linux-riscv/2020-February/008513.html
> > 
> > OpenSBI: master (commit: ge3f69fc1e934)
> > 
> > Patch 1 just moves arm-stub code to a generic code so that it can
> > be used
> > across different architecture.
> > 
> > Patch 3 adds fixmap bindings so that CONFIG_EFI can be compiled and
> > we do not
> > have create separate config to enable boot time services.
> > As runtime services are not enabled at this time, full generic
> > early ioremap
> > support is also not added in this series.
> > 
> > Patch 4 and 5 adds the PE/COFF header and EFI stub code support for
> > RISC-V
> > respectively.
> > 
> > The patches can also be found in following git repo.
> > 
> > https://github.com/atishp04/linux/tree/wip_uefi_riscv
> > 
> > The patches have been verified on Qemu using bootefi command in U-
> > Boot.
> > Here is a boot log.
> > 
> > Atish Patra (5):
> > efi: Move arm-stub to a common file
> > include: pe.h: Add RISC-V related PE definition
> > RISC-V: Define fixmap bindings for generic early ioremap support
> > RISC-V: Add PE/COFF header for EFI stub
> > RISC-V: Add EFI stub support.
> > 
> > arch/arm/Kconfig                              |   2 +-
> > arch/arm64/Kconfig                            |   2 +-
> > arch/riscv/Kconfig                            |  21 +++
> > arch/riscv/Makefile                           |   1 +
> > arch/riscv/configs/defconfig                  |   1 +
> > arch/riscv/include/asm/Kbuild                 |   2 +-
> > arch/riscv/include/asm/fixmap.h               |  21 ++-
> > arch/riscv/include/asm/io.h                   |   1 +
> > arch/riscv/include/asm/sections.h             |  13 ++
> > arch/riscv/kernel/Makefile                    |   4 +
> > arch/riscv/kernel/efi-header.S                | 107 ++++++++++++++
> > arch/riscv/kernel/head.S                      |  15 ++
> > arch/riscv/kernel/image-vars.h                |  52 +++++++
> > arch/riscv/kernel/vmlinux.lds.S               |  27 +++-
> > drivers/firmware/efi/Kconfig                  |   6 +-
> > drivers/firmware/efi/libstub/Makefile         |  20 ++-
> > .../efi/libstub/{arm-stub.c => efi-stub.c}    |   7 +-
> > drivers/firmware/efi/libstub/riscv-stub.c     | 135
> > ++++++++++++++++++
> > include/linux/pe.h                            |   3 +
> > 19 files changed, 420 insertions(+), 20 deletions(-)
> > create mode 100644 arch/riscv/include/asm/sections.h
> > create mode 100644 arch/riscv/kernel/efi-header.S
> > create mode 100644 arch/riscv/kernel/image-vars.h
> > rename drivers/firmware/efi/libstub/{arm-stub.c => efi-stub.c}
> > (98%)
> > create mode 100644 drivers/firmware/efi/libstub/riscv-stub.c
> 
> I'm in favor of adding EFI support, and I'd rather have it sooner
> than later so
> we don't paint ourselves into a corner.  I'm not sure what happened
> to the
> RISC-V EFI spec process, though, which would be my only worry here
> (also I
> haven't looked at the code :)).  Do we have enough of a spec through
> the EFI
> process that this is all kosher on their end?
> 
The RISC-V platform is already merged in UEFI spec. The latest UEFI
spec can be found here.

https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf

Section 2.3.7: RISC-V Platforms

There are some modification required in the current spec. For example:

The current spec assumes that UEFI will execute in M mode only and
should perform handoff control to OS in M-mode as well. This is not
entirely correct as we can do this in S-mode as well.

We are in the process of creating an ECR so that next release will have
the correct information.

> Given that this definately isn't for these RCs, I'm going to leave it
> in my
> review queue.  It might be best to get the "move stuff to generic"
> work merged
> on its own, as then we can carry less diff around.
> 
> 

Yup. It's definitely not rc material. Given that RISC-V specific
section is already merged in UEFI spec, can we aim for 5.7 merge window? 

> Thanks!

-- 
Regards,
Atish