On Mon, 7 Sep 2020 at 11:31, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > > On 07.09.20 09:00, Maxim Uvarov wrote: > > On Fri, 4 Sep 2020 at 18:50, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > >> > >> In the memory map the regions with the lowest addresses may be of type > >> EFI_RESERVED_TYPE. The reserved areas may be discontinuous relative to the > >> rest of the memory. So for calculating the maximum loading address for the > >> device tree and the initial ramdisk image these reserved areas should not > >> be taken into account. > >> > >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx> > >> --- > >> drivers/firmware/efi/libstub/efi-stub.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/firmware/efi/libstub/efi-stub.c b/drivers/firmware/efi/libstub/efi-stub.c > >> index c2484bf75c5d..13058ac75765 100644 > >> --- a/drivers/firmware/efi/libstub/efi-stub.c > >> +++ b/drivers/firmware/efi/libstub/efi-stub.c > >> @@ -106,7 +106,8 @@ static unsigned long get_dram_base(void) > >> map.map_end = map.map + map_size; > >> > >> for_each_efi_memory_desc_in_map(&map, md) { > >> - if (md->attribute & EFI_MEMORY_WB) { > >> + if (md->attribute & EFI_MEMORY_WB && > >> + md->type != EFI_RESERVED_TYPE) { > > > > shouldn't the type here be CONVENTIONAL? > > In 32bit ARM reserve_kernel_base() the following are considered: > > * EFI_LOADER_CODE > * EFI_LOADER_DATA > * EFI_BOOT_SERVICES_CODE > * EFI_BOOT_SERVICES_DATA > * EFI_CONVENTIONAL_MEMORY > > What I have not yet fully understood is why Linux on ARM 32bit tries to > put the kernel into the first 128 MiB. Cf. handle_kernel_image() in > drivers/firmware/efi/libstub/arm32-stub.c. > Are you looking to the latest kernel? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/arm32-stub.c?h=v5.9-rc4#n211 efi_bs_call(allocate_pages,..) is only for EFI_CONVENTIONAL_MEMORY. > According to the comments this is due to some implementation detail in > the Linux zImage decompressor and not required by UEFI or the hardware: > > Verify that the DRAM base address is compatible with the ARM > boot protocol, which determines the base of DRAM by masking > off the low 27 bits of the address at which the zImage is > loaded. These assumptions are made by the decompressor, > before any memory map is available. I think that is also fixed with: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/efi/libstub/arm32-stub.c?h=v5.9-rc4&id=d0f9ca9be11f25ef4151195eab7ea36d136084f6 Maxim. > > Best regards > > Heinrich > > > > >> if (membase > md->phys_addr) > >> membase = md->phys_addr; > >> } > >> -- > >> 2.28.0 > >> >