[PATCH] lmb: Reinstate access to memory above ram_top

[Ilias Apalodimas]

Hi Marek,


[...]

> >>>>>
> >>>>> "
> >>>>> 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.
> >>>
> >>> Perhaps a good short-term fix it to use gd->ram_top here rather than hardcoding
> >>> 4 GiB. This way it should work on all systems without a config option.
> >> Looking at my notes from last DMA32 investigation, this may indeed do the
> >> trick in the meantime. But it would be really good to have this temporary
> >> workaround guarded by some Kconfig symbol, so it can be fixed up once the
> >> DMA32 allocator is available.
> >
> > As my recent patches show, I'm digging around a bunch of Kconfig things
> > at the moment and I want to cauation against thinking that a symbol
> > guard will lead to someone doing some required fixup work. At least
> > filing an issue under https://source.denx.de/u-boot/u-boot/-/issues/
> > means we can track it for later and put links to relevant threads as
> > comments, when someone has time and interest in picking it up.
> Unrelated to whether this is going to be an issue or not, I think we
> have two things to do here:
>
> - Consider ram_top , get input from Heinrich on that
> - DMA32 ... how to design that, should that be a special LMB pool ? How
> do we handle hardware which has no memory below 4 GiB, iommu maybe ?

Why don't we add hints in the driver model that explains the device
limitations? That would make the core code more readable as all the
info we need to decide on the memory allocation is packed with the
device

Cheers
/Ilias