Re: [PATCH 1/1] efi/libstub: DRAM base calculation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(+ Atish, Palmer)

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) {
>                         if (membase > md->phys_addr)
>                                 membase = md->phys_addr;
>                 }
> --
> 2.28.0
>

This is not the right fix - on RPi2, for instance, which has some
reserved memory at the base of DRAM, this change will result in the
first 16 MB of memory to be wasted.

What I would prefer to do is get rid of get_dram_base() entirely -
arm64 does not use its return value in the first place, and for ARM,
the only reason we need it is so that we can place the uncompressed
kernel image as low in memory as possible, and there are probably
better ways to do that. RISC-V just started using it too, but only
passes it from handle_kernel_image() to efi_relocate_kernel(), and
afaict, passing 0x0 there instead would not cause any problems.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux