mbox series

[0/7] efi: improved correctness, arm unification, and cleanup

Message ID 20170612145341.3351-1-leif.lindholm@linaro.org
Headers show
Series efi: improved correctness, arm unification, and cleanup | expand

Message

Leif Lindholm June 12, 2017, 2:53 p.m. UTC 
This patch series is really three different ones, but they unite around
the need for (and the implementation) of more flexible control of memory
allocation on UEFI systems.

1: Adding new interfaces
- A function for detecting the start address of RAM
  Since ARM platforms have no standardised memory map, implement a
  function that picks the lowest-address region supporting the
  write-back cache atribute from the UEFI memory map.
- Implement and expose a new memory allocation function giving access to
  the allocation type and memory type arguments to the AllocatePages
  boot service.

2: ARM unification
- The fdt helper library for arm64-efi is really an efi/fdt function.
  So move it to neutral ground in loader/efi.
- The arm64 efi linux loader was written for arm64 only, so clean it up a
  bit with regards to 32/64-bit portability, and abstract out some
  definitions and function prototypes.
- Move the arm efi port to use the arm64 linux loader instead of the one
  shared with the u-boot port. Clean up the u-boot loder by deleting the
  efi-specific bits and other code only used by that.

3: Correctness improvements
- There are some restrictions on the placement of initrd images in
  relation to the runtime kernel images, for both arm and arm64 - but the
  arm64 one did not use to be explicitly documented (and only triggerable
  on systems with > 40GB of RAM), and the u-boot loader always placed the
  images nearly adjacent. Use the new interfaces to place the initrd as
  approrpiate for each architecture.
- The allocation of memory for the grub heap is done of memory type
  GRUB_EFI_LOADER_DATA. Since UEFI can return memory with non-executable
  mappings for this request, and modules are loaded onto the heap, change
  this allocation to GRUB_EFI_LOADER_CODE instead.

I first sent this series out on 28 February this year.
Changes since previous submission:
- Rebased (to deal with arm coreboot upstream changes).
- Moved EFI page size definitions to common header.
- Moved a few stray 32/64-bit fixes from 3/7 to 4/7.

Leif Lindholm (7):
  efi: add grub_efi_get_dram_base() function for arm*
  efi: refactor grub_efi_allocate_pages
  efi: move fdt helper library
  arm64: make efi linux loader more generic
  arm: reuse arm64 linux loader on efi systems
  efi: restrict arm/arm64 linux loader initrd placement
  efi: change heap allocation type to GRUB_EFI_LOADER_CODE

 grub-core/Makefile.am                 |   1 -
 grub-core/Makefile.core.def           |   6 +-
 grub-core/kern/arm/efi/misc.c         | 202 ----------------------------------
 grub-core/kern/efi/mm.c               |  92 ++++++++++++----
 grub-core/loader/arm/linux.c          |  39 +------
 grub-core/loader/arm64/linux.c        |  73 ++++++++----
 grub-core/loader/arm64/xen_boot.c     |  15 +--
 grub-core/loader/{arm64 => efi}/fdt.c |  11 +-
 include/grub/arm/efi/loader.h         |  26 -----
 include/grub/arm/efi/memory.h         |   3 +
 include/grub/arm/linux.h              |  30 ++---
 include/grub/arm64/linux.h            |  13 +--
 include/grub/efi/efi.h                |  10 ++
 include/grub/{arm64 => efi}/fdtload.h |   3 -
 include/grub/efi/memory.h             |   3 +
 include/grub/efi/pe32.h               |   2 +
 16 files changed, 176 insertions(+), 353 deletions(-)
 delete mode 100644 grub-core/kern/arm/efi/misc.c
 rename grub-core/loader/{arm64 => efi}/fdt.c (93%)
 delete mode 100644 include/grub/arm/efi/loader.h
 rename include/grub/{arm64 => efi}/fdtload.h (89%)

-- 
2.11.0


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Comments

Daniel Kiper June 20, 2017, 12:08 p.m. UTC | #1 
On Mon, Jun 12, 2017 at 03:53:34PM +0100, Leif Lindholm wrote:
> This patch series is really three different ones, but they unite around

> the need for (and the implementation) of more flexible control of memory

> allocation on UEFI systems.


Thanks for posting this. If nobody takes care then I will take a look in
2-4 weeks. I am busy with other stuff right now. Sorry for delays.

Daniel

PS Next time please CC me.

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel