On Wed, 9 Sep 2020 at 18:26, Grant Likely <grant.likely@xxxxxxx> 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)
