lkml.org 
[lkml]   [2020]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v7 0/9] Add UEFI support for RISC-V
From
On Fri, 28 Aug 2020 10:20:27 PDT (-0700), Atish Patra wrote:
> This series adds UEFI support for RISC-V.
>
> Linux kernel: v5.9-rc2
> U-Boot: v2020.07
> OpenSBI: master
>
> Patch 1-3 are generic riscv feature addition required for UEFI support.
> Patch 4-7 adds the efi stub support for RISC-V which was reviewed few months back.
> https://www.spinics.net/lists/linux-efi/msg19144.html
> Patch 8 just renames arm-init code so that it can be used across different
> architectures.
> Patch 9 adds the runtime services for RISC-V.
>
> The working set of patches can also be found in following git repo.
> https://github.com/atishp04/linux/tree/uefi_riscv_5.10_v7
>
> The patches have been verified on following platforms:
> 1. Qemu (both RV32 & RV64) for the following bootflow
> OpenSBI->U-Boot->Linux
> EDK2->Linux
> 2. HiFive unleashed using (RV64) for the following bootflow
> OpenSBI->U-Boot->Linux
> EDK2->Linux
>
> Thanks Abner & Daniel for all work done for EDK2.
> The EDK2 instructions are available here.
> https://github.com/JohnAZoidberg/riscv-edk2-docker/
>
> Note:
> 1. Currently, EDK2 RISC-V port doesn't support OVMF package. That's why
> EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER should be enabled to load initrd via
> commandline until OVMF patches are available.
>
> 2. For RV32, maximum allocated memory should be 1G as RISC-V kernel can not map
> beyond 1G of physical memory for RV32.
>
> 3. Runtime services have been verified with fwts on EDK2.
>
> ***********************************************************************
> [root@fedora-riscv ~]# fwts uefirtvariable
> Running 1 tests, results appended to results.log
> Test: UEFI Runtime service variable interface tests.
> Test UEFI RT service get variable interface. 1 passed
> Test UEFI RT service get next variable name interface. 4 passed
> Test UEFI RT service set variable interface. 7 passed, 1 warning
> Test UEFI RT service query variable info interface. 1 passed
> Test UEFI RT service variable interface stress test. 2 passed
> Test UEFI RT service set variable interface stress t.. 4 passed
> Test UEFI RT service query variable info interface s.. 1 passed
> Test UEFI RT service get variable interface, invalid.. 5 passed
> Test UEFI RT variable services supported status. 1 skipped
>
> Test |Pass |Fail |Abort|Warn |Skip |Info |
> uefirtvariable | 25| | | 1| 1| |
> Total: | 25| 0| 0| 1| 1| 0|
>
> ***********************************************************************
>
> Changes from v6->v7:
> 1. Fixed build error reported on linux-next for patch2.
>
> Changes from v5->v6:
> 1. Fixed the static declaration for pt_ops.
> 2. Added Reviewed/Acked-by.
>
> Changes from v4->v5:
> 1. Late mappings allocations are now done through function pointers.
> 2. EFI run time services are verified using full linux boot and fwts using EDK2.
>
> Changes from v3->v4:
> 1. Used pgd mapping to avoid copying DT to bss.
>
> Changes from v2->v3:
> 1. Fixed few bugs in run time services page table mapping.
> 2. Dropped patch 1 as it is already taken into efi-tree.
> 3. Sent few generic mmu fixes as a separate series to ease the merge conflicts.
>
> Changes from v1->v2:
> 1. Removed patch 1 as it is already taken into efi-tree.
> 2. Fixed compilation issues with patch 9.
> 3. Moved few function prototype declaration to header file to keep kbuild happy.
>
> Changes from previous version:
> 1. Added full ioremap support.
> 2. Added efi runtime services support.
> 3. Fixes mm issues
>
> Anup Patel (1):
> RISC-V: Move DT mapping outof fixmap
>
> Atish Patra (8):
> RISC-V: Add early ioremap support
> RISC-V: Implement late mapping page table allocation functions
> include: pe.h: Add RISC-V related PE definition
> RISC-V: Add PE/COFF header for EFI stub
> RISC-V: Add EFI stub support.
> efi: Rename arm-init to efi-init common for all arch
> RISC-V: Add EFI runtime services
> RISC-V: Add page table dump support for uefi
>
> arch/riscv/Kconfig | 25 +++
> arch/riscv/Makefile | 1 +
> arch/riscv/configs/defconfig | 1 +
> arch/riscv/include/asm/Kbuild | 1 +
> arch/riscv/include/asm/efi.h | 56 +++++
> arch/riscv/include/asm/fixmap.h | 16 +-
> arch/riscv/include/asm/io.h | 1 +
> arch/riscv/include/asm/mmu.h | 2 +
> arch/riscv/include/asm/pgtable.h | 5 +
> arch/riscv/include/asm/sections.h | 13 ++
> arch/riscv/kernel/Makefile | 5 +
> arch/riscv/kernel/efi-header.S | 104 ++++++++++
> arch/riscv/kernel/efi.c | 105 ++++++++++
> arch/riscv/kernel/head.S | 17 +-
> arch/riscv/kernel/head.h | 2 -
> arch/riscv/kernel/image-vars.h | 51 +++++
> arch/riscv/kernel/setup.c | 18 +-
> arch/riscv/kernel/vmlinux.lds.S | 22 +-
> arch/riscv/mm/init.c | 191 +++++++++++++-----
> arch/riscv/mm/ptdump.c | 48 ++++-
> drivers/firmware/efi/Kconfig | 3 +-
> drivers/firmware/efi/Makefile | 4 +-
> .../firmware/efi/{arm-init.c => efi-init.c} | 0
> drivers/firmware/efi/libstub/Makefile | 10 +
> drivers/firmware/efi/libstub/efi-stub.c | 11 +-
> drivers/firmware/efi/libstub/riscv-stub.c | 110 ++++++++++
> drivers/firmware/efi/riscv-runtime.c | 143 +++++++++++++
> include/linux/pe.h | 3 +
> 28 files changed, 901 insertions(+), 67 deletions(-)
> create mode 100644 arch/riscv/include/asm/efi.h
> create mode 100644 arch/riscv/include/asm/sections.h
> create mode 100644 arch/riscv/kernel/efi-header.S
> create mode 100644 arch/riscv/kernel/efi.c
> create mode 100644 arch/riscv/kernel/image-vars.h
> rename drivers/firmware/efi/{arm-init.c => efi-init.c} (100%)
> create mode 100644 drivers/firmware/efi/libstub/riscv-stub.c
> create mode 100644 drivers/firmware/efi/riscv-runtime.c

Thanks. I've also got the tag "riscv-for-efi-5.10", which consists of

6bf710098245 ("efi: Rename arm-init to efi-init common for all arch")
f7305a30f0ec ("include: pe.h: Add RISC-V related PE definition")
d012a7190fc1 ("Linux 5.9-rc2")

and is the base of my for-next. The rest of the patches are also on for-next,
but quite a bit later.

Ard: IIUC that's what you were looking for? Those two as-is definately aren't
going to break bisecting, so I think we should be good to start both of our
for-next branches there. LMK if you were looking for something else.

\
 
 \ /
  Last update: 2020-09-09 03:17    [W:0.100 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site