On Wed, Feb 08, 2017 at 10:35:02AM -0600, Timur Tabi wrote:
On 02/08/2017 10:29 AM, Ard Biesheuvel wrote:
How do you reckon this constitutes a limit?+ status = handle_cmdline_files(sys_table, image, cmdline_ptr,
+ "initrd=", dram_base + SZ_512M,
+ (unsigned long *)&initrd_addr,
+ (unsigned long *)&initrd_size);
So I know this patch is almost three years old, but why is there a
512M limit on the initrd size?
handle_cmdline_files() calls efi_high_alloc() with that limit. I'm
still trying to understand all the details myself, but apparently
our firmware and initrd need to fit within the first 512MB because
of dram_base + SZ_512M. When we change "dram_base + SZ_512M" to
"~0", everything works.
Just to check, how big is that initrd?
I guess it's possible that there simply isn't sufficient contiguous free
memory in that range, even if the initrd isn't that large. Can you share
the EFI memory map dump from booting with efi=debug?
We originally needed to restrict this to ensure that the kernel could
map the initrd (and I think the 512M restriction specifically was
inherited from the DTB mapping restriction). Since then, we have relaxed
things in the kernel, and today Documentation/arm64/booting.txt says:
If an initrd/initramfs is passed to the kernel at boot, it must
reside entirely within a 1 GB aligned physical memory window of
up to 32 GB in size that fully covers the kernel Image as well.
... so I think the EFI stub should be able to take advantage of that
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html