[PATCH] lmb: Reinstate access to memory above ram_top

Mark Kettenis mark.kettenis at xs4all.nl
Mon Mar 23 00:25:43 CET 2026


> Date: Sun, 22 Mar 2026 22:59:53 +0100
> 
> On 3/22/26 10:45 PM, Gary Guo wrote:
> 
> [...]
> 
> >> Is your malloc area by any chance above the 4 GiB boundary ? Or how come
> >> does EFI allocate pages from above 4 GiB range? It should not be doing
> >> that and that is what should be fixed, at least until the DMA32
> >> allocator is in place.
> >>
> >> Please keep in mind, that revering this patch breaks other use cases,
> >> like loading into the DRAM above 4 GiB.

Well, technically it doesn't break things as this is new
functionality.

> > Code in lib/efi_loader uses efi_allocate_pool (in lib/efi_loader/efi_memory.c)
> > whenever it allocates, which calls efi_allocate_pages, which calls into
> > lmb_alloc_mem. There's no malloc here.
> Does something like this make the issue go away ?
> 
> "
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index b77c2f980cc..44eccc0cf35 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -475,8 +475,10 @@ efi_status_t efi_allocate_pages(enum 
> efi_allocate_type type,
>          flags = LMB_NOOVERWRITE | LMB_NONOTIFY;
>          switch (type) {
>          case EFI_ALLOCATE_ANY_PAGES:
> +               addr = map_to_sysmem((void *)(uintptr_t)0xffff0000);
> +
>                  /* Any page */
> -               err = lmb_alloc_mem(LMB_MEM_ALLOC_ANY, EFI_PAGE_SIZE, &addr,
> +               err = lmb_alloc_mem(LMB_MEM_ALLOC_MAX, EFI_PAGE_SIZE, &addr,
>                                      len, flags);
>                  if (err)
>                          return EFI_OUT_OF_RESOURCES;
> "
> 
> If so, then maybe we need a temporary config option which limits the 
> EFI_ALLOCATE_ANY_PAGES below 4 GiB on hardware that has DMA limitations.

Note that some arm64 systems (e.g. Apple Silicon) have *no* memory
below 4 GiB.  So that change must indeed be behind a config option and
care must be taken on what systems to enabled it.

To come back to my earlier statement that some SoCs don't fully
support DMA above the 4 GiB boundary: I specifically mentioned
Raspberry Pi and various Rockchip SoCs.  I'm sorry I didn't get around
to testing those boards, but I recently did some work on adding
support for the RK3576 SoC to OpenBSD and can confirm that its SD
controller does not support DMA above the 4 GiB boundary.  That means
that with the diff that has now been commited, any attempt to load
into DRAM above 4 GiB from SD card or MMC is probably going to corrup
some memory below 4 GiB.  The Ethernet controller on those boards does
support DMA above 4 GiB though.

That said, I'd say that on a platform where some of the supported
storage or network devices don't support DMA above 4 GiB, lmb should
not make that memory available until bounce buffers are implemented.


More information about the U-Boot mailing list