[PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base

[Ard Biesheuvel]

On Wed, 9 Sep 2020 at 18:26, Grant Likely <grant.likely at arm.com> wrote:
>
>
>
> On 09/09/2020 16:16, Ard Biesheuvel wrote:
> > Maxim reports boot failures on platforms that describe reserved memory
> > regions in DT that are disjoint from system DRAM, and which are converted
> > to EfiReservedMemory regions by the EFI subsystem in u-boot.
> >
> > As it turns out, the whole notion of discovering the base of DRAM is
> > problematic, and it would be better to simply rely on the EFI memory
> > allocation routines instead, and derive the FDT and initrd allocation
> > limits from the actual placement of the kernel (which is what defines
> > the start of the linear region anyway)
> >
> > Finally, we should be able to get rid of get_dram_base() entirely.
> > However, as RISC-V only just started using it, we will need to address
> > that at a later time.
>
> Looks reasonable to me. Presumably all special cases (platform specific
> spin tables, etc) are covered as reserved in the UEFI memory map, correct?
>

Yes. The only reason the code is as it is today is for a proprietary
HP Inc. platform that had a bootservicesdata allocation at the base of
DRAM of 8 KiB, but this should now be covered in the same way as any
other reserved region living in the window below TEXT_OFFSET. (Note
that the current logic is flawed in any case: even though boot
services regions are released to the OS at ExitBootServices(), there
are types of EFI configuration tables that keep their contents in
BsData regions as well, and those may get clobbered by the
decompressed image)

In summary, I am not expecting these changes to regress any platforms
we care about (famous last words), and if it works, we can start
removing the dram base handling code altogether (which currently gets
called on arm64 as well, even though we never use the result)