| Message ID | 20170612145341.3351-7-leif.lindholm@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | efi: improved correctness, arm unification, and cleanup | expand |
On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > The 32-bit arm Linux kernel is built as a zImage, which self-decompresses > down to near start of RAM. In order for an initrd/initramfs to be > accessible, it needs to be placed within the first ~768MB of RAM. > The initrd loader built into the kernel EFI stub restricts this down to > 512MB for simplicity - so enable the same restriction in grub. > > For arm64, the requirement is within a 1GB aligned 32GB window also > covering the (runtime) kernel image. Since the EFI stub loader itself > will attempt to relocate to near start of RAM, force initrd to be loaded > completely within the first 32GB of RAM. > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > --- > grub-core/loader/arm64/linux.c | 39 ++++++++++++++++++++++++++++++++++++++- > 1 file changed, 38 insertions(+), 1 deletion(-) > > diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c > index 8cd44230d..7e989c2b9 100644 > --- a/grub-core/loader/arm64/linux.c > +++ b/grub-core/loader/arm64/linux.c > @@ -35,6 +35,23 @@ > > GRUB_MOD_LICENSE ("GPLv3+"); > > +/* > + * As per linux/Documentation/arm/Booting > + * ARM initrd needs to be covered by kernel linear mapping, > + * so place it in the first 512MB of DRAM. > + * > + * As per linux/Documentation/arm64/booting.txt > + * ARM64 initrd needs to be contained entirely within a 1GB aligned window > + * of up to 32GB of size that covers the kernel image as well. > + * Since the EFI stub loader will attempt to load the kernel near start of > + * RAM, place the buffer in the first 32GB of RAM. > + */ > +#ifdef __arm__ > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > +#else /* __aarch64__ */ > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > +#endif > + > static grub_dl_t my_mod; > static int loaded; > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > return GRUB_ERR_NONE; > } > > +/* > + * This function returns a pointer to a legally allocated initrd buffer, > + * or NULL if unsuccessful > + */ > +static void * > +allocate_initrd_mem (int initrd_pages) > +{ > + grub_addr_t max_addr; > + > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > + return NULL; > + > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; I do not understand this. Why do not pass simply INITRD_MAX_ADDRESS_OFFSET instead of max_addr to grub_efi_allocate_pages_real()? > + return grub_efi_allocate_pages_real (max_addr, initrd_pages, > + GRUB_EFI_ALLOCATE_MAX_ADDRESS, > + GRUB_EFI_LOADER_DATA); > +} Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote: > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > > The 32-bit arm Linux kernel is built as a zImage, which self-decompresses > > down to near start of RAM. In order for an initrd/initramfs to be > > accessible, it needs to be placed within the first ~768MB of RAM. > > The initrd loader built into the kernel EFI stub restricts this down to > > 512MB for simplicity - so enable the same restriction in grub. > > > > For arm64, the requirement is within a 1GB aligned 32GB window also > > covering the (runtime) kernel image. Since the EFI stub loader itself > > will attempt to relocate to near start of RAM, force initrd to be loaded > > completely within the first 32GB of RAM. > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > > --- > > grub-core/loader/arm64/linux.c | 39 > ++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > diff --git a/grub-core/loader/arm64/linux.c > b/grub-core/loader/arm64/linux.c > > index 8cd44230d..7e989c2b9 100644 > > --- a/grub-core/loader/arm64/linux.c > > +++ b/grub-core/loader/arm64/linux.c > > @@ -35,6 +35,23 @@ > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > +/* > > + * As per linux/Documentation/arm/Booting > > + * ARM initrd needs to be covered by kernel linear mapping, > > + * so place it in the first 512MB of DRAM. > > + * > > + * As per linux/Documentation/arm64/booting.txt > > + * ARM64 initrd needs to be contained entirely within a 1GB aligned > window > > + * of up to 32GB of size that covers the kernel image as well. > > + * Since the EFI stub loader will attempt to load the kernel near start > of > > + * RAM, place the buffer in the first 32GB of RAM. > > + */ > > +#ifdef __arm__ > > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > > +#else /* __aarch64__ */ > > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > > +#endif > > + > > static grub_dl_t my_mod; > > static int loaded; > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > > return GRUB_ERR_NONE; > > } > > > > +/* > > + * This function returns a pointer to a legally allocated initrd buffer, > > + * or NULL if unsuccessful > > + */ > > +static void * > > +allocate_initrd_mem (int initrd_pages) > > +{ > > + grub_addr_t max_addr; > > + > > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > > + return NULL; > > + > > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; > > I do not understand this. Why do not pass simply INITRD_MAX_ADDRESS_OFFSET > instead of max_addr to grub_efi_allocate_pages_real()? > On ARM it's common for RAM to start at address different from 0 > > > + return grub_efi_allocate_pages_real (max_addr, initrd_pages, > > + GRUB_EFI_ALLOCATE_MAX_ADDRESS, > > + GRUB_EFI_LOADER_DATA); > > +} > > Daniel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko wrote: > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote: > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > > > The 32-bit arm Linux kernel is built as a zImage, which self-decompresses > > > down to near start of RAM. In order for an initrd/initramfs to be > > > accessible, it needs to be placed within the first ~768MB of RAM. > > > The initrd loader built into the kernel EFI stub restricts this down to > > > 512MB for simplicity - so enable the same restriction in grub. > > > > > > For arm64, the requirement is within a 1GB aligned 32GB window also > > > covering the (runtime) kernel image. Since the EFI stub loader itself > > > will attempt to relocate to near start of RAM, force initrd to be loaded > > > completely within the first 32GB of RAM. > > > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > > > --- > > > grub-core/loader/arm64/linux.c | 39 > > ++++++++++++++++++++++++++++++++++++++- > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > diff --git a/grub-core/loader/arm64/linux.c > > b/grub-core/loader/arm64/linux.c > > > index 8cd44230d..7e989c2b9 100644 > > > --- a/grub-core/loader/arm64/linux.c > > > +++ b/grub-core/loader/arm64/linux.c > > > @@ -35,6 +35,23 @@ > > > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > > > +/* > > > + * As per linux/Documentation/arm/Booting > > > + * ARM initrd needs to be covered by kernel linear mapping, > > > + * so place it in the first 512MB of DRAM. > > > + * > > > + * As per linux/Documentation/arm64/booting.txt > > > + * ARM64 initrd needs to be contained entirely within a 1GB aligned > > window > > > + * of up to 32GB of size that covers the kernel image as well. > > > + * Since the EFI stub loader will attempt to load the kernel near start > > of > > > + * RAM, place the buffer in the first 32GB of RAM. > > > + */ > > > +#ifdef __arm__ > > > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > > > +#else /* __aarch64__ */ > > > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > > > +#endif > > > + > > > static grub_dl_t my_mod; > > > static int loaded; > > > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > > > return GRUB_ERR_NONE; > > > } > > > > > > +/* > > > + * This function returns a pointer to a legally allocated initrd buffer, > > > + * or NULL if unsuccessful > > > + */ > > > +static void * > > > +allocate_initrd_mem (int initrd_pages) > > > +{ > > > + grub_addr_t max_addr; > > > + > > > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > > > + return NULL; > > > + > > > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; > > > > I do not understand this. Why do not pass simply INITRD_MAX_ADDRESS_OFFSET > > instead of max_addr to grub_efi_allocate_pages_real()? > > > On ARM it's common for RAM to start at address different from 0 OK, but, AIUI we have to load initrd no higher than INITRD_MAX_ADDRESS_OFFSET. So, we do not care where the region starts. We care where region ends. Am I missing something? Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote: > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko > wrote: > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote: > > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > > > > The 32-bit arm Linux kernel is built as a zImage, which > self-decompresses > > > > down to near start of RAM. In order for an initrd/initramfs to be > > > > accessible, it needs to be placed within the first ~768MB of RAM. > > > > The initrd loader built into the kernel EFI stub restricts this down > to > > > > 512MB for simplicity - so enable the same restriction in grub. > > > > > > > > For arm64, the requirement is within a 1GB aligned 32GB window also > > > > covering the (runtime) kernel image. Since the EFI stub loader itself > > > > will attempt to relocate to near start of RAM, force initrd to be > loaded > > > > completely within the first 32GB of RAM. > > > > > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > > > > --- > > > > grub-core/loader/arm64/linux.c | 39 > > > ++++++++++++++++++++++++++++++++++++++- > > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/grub-core/loader/arm64/linux.c > > > b/grub-core/loader/arm64/linux.c > > > > index 8cd44230d..7e989c2b9 100644 > > > > --- a/grub-core/loader/arm64/linux.c > > > > +++ b/grub-core/loader/arm64/linux.c > > > > @@ -35,6 +35,23 @@ > > > > > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > > > > > +/* > > > > + * As per linux/Documentation/arm/Booting > > > > + * ARM initrd needs to be covered by kernel linear mapping, > > > > + * so place it in the first 512MB of DRAM. > > > > + * > > > > + * As per linux/Documentation/arm64/booting.txt > > > > + * ARM64 initrd needs to be contained entirely within a 1GB aligned > > > window > > > > + * of up to 32GB of size that covers the kernel image as well. > > > > + * Since the EFI stub loader will attempt to load the kernel near > start > > > of > > > > + * RAM, place the buffer in the first 32GB of RAM. > > > > + */ > > > > +#ifdef __arm__ > > > > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > > > > +#else /* __aarch64__ */ > > > > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > > > > +#endif > > > > + > > > > static grub_dl_t my_mod; > > > > static int loaded; > > > > > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > > > > return GRUB_ERR_NONE; > > > > } > > > > > > > > +/* > > > > + * This function returns a pointer to a legally allocated initrd > buffer, > > > > + * or NULL if unsuccessful > > > > + */ > > > > +static void * > > > > +allocate_initrd_mem (int initrd_pages) > > > > +{ > > > > + grub_addr_t max_addr; > > > > + > > > > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > > > > + return NULL; > > > > + > > > > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; > > > > > > I do not understand this. Why do not pass simply > INITRD_MAX_ADDRESS_OFFSET > > > instead of max_addr to grub_efi_allocate_pages_real()? > > > > > On ARM it's common for RAM to start at address different from 0 > > OK, but, AIUI we have to load initrd no higher than > INITRD_MAX_ADDRESS_OFFSET. > So, we do not care where the region starts. We care where region ends. > Am I missing something? > The limit is relative to the start of RAM. > > Daniel > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Jul 27, 2017 at 03:41:25PM +0000, Vladimir 'phcoder' Serbinenko wrote: > On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote: > > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko > > wrote: > > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote: > > > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > > > > > The 32-bit arm Linux kernel is built as a zImage, which > > self-decompresses > > > > > down to near start of RAM. In order for an initrd/initramfs to be > > > > > accessible, it needs to be placed within the first ~768MB of RAM. > > > > > The initrd loader built into the kernel EFI stub restricts this down > > to > > > > > 512MB for simplicity - so enable the same restriction in grub. > > > > > > > > > > For arm64, the requirement is within a 1GB aligned 32GB window also > > > > > covering the (runtime) kernel image. Since the EFI stub loader itself > > > > > will attempt to relocate to near start of RAM, force initrd to be > > loaded > > > > > completely within the first 32GB of RAM. > > > > > > > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > > > > > --- > > > > > grub-core/loader/arm64/linux.c | 39 > > > > ++++++++++++++++++++++++++++++++++++++- > > > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/grub-core/loader/arm64/linux.c > > > > b/grub-core/loader/arm64/linux.c > > > > > index 8cd44230d..7e989c2b9 100644 > > > > > --- a/grub-core/loader/arm64/linux.c > > > > > +++ b/grub-core/loader/arm64/linux.c > > > > > @@ -35,6 +35,23 @@ > > > > > > > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > > > > > > > +/* > > > > > + * As per linux/Documentation/arm/Booting > > > > > + * ARM initrd needs to be covered by kernel linear mapping, > > > > > + * so place it in the first 512MB of DRAM. > > > > > + * > > > > > + * As per linux/Documentation/arm64/booting.txt > > > > > + * ARM64 initrd needs to be contained entirely within a 1GB aligned > > > > window > > > > > + * of up to 32GB of size that covers the kernel image as well. > > > > > + * Since the EFI stub loader will attempt to load the kernel near > > start > > > > of > > > > > + * RAM, place the buffer in the first 32GB of RAM. > > > > > + */ > > > > > +#ifdef __arm__ > > > > > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > > > > > +#else /* __aarch64__ */ > > > > > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > > > > > +#endif > > > > > + > > > > > static grub_dl_t my_mod; > > > > > static int loaded; > > > > > > > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > > > > > return GRUB_ERR_NONE; > > > > > } > > > > > > > > > > +/* > > > > > + * This function returns a pointer to a legally allocated initrd > > buffer, > > > > > + * or NULL if unsuccessful > > > > > + */ > > > > > +static void * > > > > > +allocate_initrd_mem (int initrd_pages) > > > > > +{ > > > > > + grub_addr_t max_addr; > > > > > + > > > > > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > > > > > + return NULL; > > > > > + > > > > > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; > > > > > > > > I do not understand this. Why do not pass simply > > INITRD_MAX_ADDRESS_OFFSET > > > > instead of max_addr to grub_efi_allocate_pages_real()? > > > > > > > On ARM it's common for RAM to start at address different from 0 > > > > OK, but, AIUI we have to load initrd no higher than > > INITRD_MAX_ADDRESS_OFFSET. > > So, we do not care where the region starts. We care where region ends. > > Am I missing something? > > > The limit is relative to the start of RAM. OK, then it make sense. Thanks for clarification. I would just ask for a comment to avoid reader confusion. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Jul 27, 2017 at 06:12:42PM +0200, Daniel Kiper wrote: > On Thu, Jul 27, 2017 at 03:41:25PM +0000, Vladimir 'phcoder' Serbinenko wrote: > > On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote: > > > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko > > > wrote: > > > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote: > > > > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > > > > > > The 32-bit arm Linux kernel is built as a zImage, which > > > self-decompresses > > > > > > down to near start of RAM. In order for an initrd/initramfs to be > > > > > > accessible, it needs to be placed within the first ~768MB of RAM. > > > > > > The initrd loader built into the kernel EFI stub restricts this down > > > to > > > > > > 512MB for simplicity - so enable the same restriction in grub. > > > > > > > > > > > > For arm64, the requirement is within a 1GB aligned 32GB window also > > > > > > covering the (runtime) kernel image. Since the EFI stub loader itself > > > > > > will attempt to relocate to near start of RAM, force initrd to be > > > loaded > > > > > > completely within the first 32GB of RAM. > > > > > > > > > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > > > > > > --- > > > > > > grub-core/loader/arm64/linux.c | 39 > > > > > ++++++++++++++++++++++++++++++++++++++- > > > > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/grub-core/loader/arm64/linux.c > > > > > b/grub-core/loader/arm64/linux.c > > > > > > index 8cd44230d..7e989c2b9 100644 > > > > > > --- a/grub-core/loader/arm64/linux.c > > > > > > +++ b/grub-core/loader/arm64/linux.c > > > > > > @@ -35,6 +35,23 @@ > > > > > > > > > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > > > > > > > > > +/* > > > > > > + * As per linux/Documentation/arm/Booting > > > > > > + * ARM initrd needs to be covered by kernel linear mapping, > > > > > > + * so place it in the first 512MB of DRAM. > > > > > > + * > > > > > > + * As per linux/Documentation/arm64/booting.txt > > > > > > + * ARM64 initrd needs to be contained entirely within a 1GB aligned > > > > > window > > > > > > + * of up to 32GB of size that covers the kernel image as well. > > > > > > + * Since the EFI stub loader will attempt to load the kernel near > > > start > > > > > of > > > > > > + * RAM, place the buffer in the first 32GB of RAM. > > > > > > + */ > > > > > > +#ifdef __arm__ > > > > > > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > > > > > > +#else /* __aarch64__ */ > > > > > > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > > > > > > +#endif > > > > > > + > > > > > > static grub_dl_t my_mod; > > > > > > static int loaded; > > > > > > > > > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > > > > > > return GRUB_ERR_NONE; > > > > > > } > > > > > > > > > > > > +/* > > > > > > + * This function returns a pointer to a legally allocated initrd > > > buffer, > > > > > > + * or NULL if unsuccessful > > > > > > + */ > > > > > > +static void * > > > > > > +allocate_initrd_mem (int initrd_pages) > > > > > > +{ > > > > > > + grub_addr_t max_addr; > > > > > > + > > > > > > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > > > > > > + return NULL; > > > > > > + > > > > > > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; > > > > > > > > > > I do not understand this. Why do not pass simply > > > INITRD_MAX_ADDRESS_OFFSET > > > > > instead of max_addr to grub_efi_allocate_pages_real()? > > > > > > > > > On ARM it's common for RAM to start at address different from 0 > > > > > > OK, but, AIUI we have to load initrd no higher than > > > INITRD_MAX_ADDRESS_OFFSET. > > > So, we do not care where the region starts. We care where region ends. > > > Am I missing something? > > > > > The limit is relative to the start of RAM. > > OK, then it make sense. Thanks for clarification. I would just > ask for a comment to avoid reader confusion. Would moving this function next to the comment block this patch adds to the top of the file be sufficient? / Leif _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
On Fri, Jul 28, 2017 at 07:44:15PM +0100, Leif Lindholm wrote: > On Thu, Jul 27, 2017 at 06:12:42PM +0200, Daniel Kiper wrote: > > On Thu, Jul 27, 2017 at 03:41:25PM +0000, Vladimir 'phcoder' Serbinenko wrote: > > > On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote: > > > > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko > > > > wrote: > > > > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote: > > > > > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote: > > > > > > > The 32-bit arm Linux kernel is built as a zImage, which > > > > self-decompresses > > > > > > > down to near start of RAM. In order for an initrd/initramfs to be > > > > > > > accessible, it needs to be placed within the first ~768MB of RAM. > > > > > > > The initrd loader built into the kernel EFI stub restricts this down > > > > to > > > > > > > 512MB for simplicity - so enable the same restriction in grub. > > > > > > > > > > > > > > For arm64, the requirement is within a 1GB aligned 32GB window also > > > > > > > covering the (runtime) kernel image. Since the EFI stub loader itself > > > > > > > will attempt to relocate to near start of RAM, force initrd to be > > > > loaded > > > > > > > completely within the first 32GB of RAM. > > > > > > > > > > > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> > > > > > > > --- > > > > > > > grub-core/loader/arm64/linux.c | 39 > > > > > > ++++++++++++++++++++++++++++++++++++++- > > > > > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/grub-core/loader/arm64/linux.c > > > > > > b/grub-core/loader/arm64/linux.c > > > > > > > index 8cd44230d..7e989c2b9 100644 > > > > > > > --- a/grub-core/loader/arm64/linux.c > > > > > > > +++ b/grub-core/loader/arm64/linux.c > > > > > > > @@ -35,6 +35,23 @@ > > > > > > > > > > > > > > GRUB_MOD_LICENSE ("GPLv3+"); > > > > > > > > > > > > > > +/* > > > > > > > + * As per linux/Documentation/arm/Booting > > > > > > > + * ARM initrd needs to be covered by kernel linear mapping, > > > > > > > + * so place it in the first 512MB of DRAM. > > > > > > > + * > > > > > > > + * As per linux/Documentation/arm64/booting.txt > > > > > > > + * ARM64 initrd needs to be contained entirely within a 1GB aligned > > > > > > window > > > > > > > + * of up to 32GB of size that covers the kernel image as well. > > > > > > > + * Since the EFI stub loader will attempt to load the kernel near > > > > start > > > > > > of > > > > > > > + * RAM, place the buffer in the first 32GB of RAM. > > > > > > > + */ > > > > > > > +#ifdef __arm__ > > > > > > > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > > > > > > > +#else /* __aarch64__ */ > > > > > > > +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > > > > > > > +#endif > > > > > > > + > > > > > > > static grub_dl_t my_mod; > > > > > > > static int loaded; > > > > > > > > > > > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void) > > > > > > > return GRUB_ERR_NONE; > > > > > > > } > > > > > > > > > > > > > > +/* > > > > > > > + * This function returns a pointer to a legally allocated initrd > > > > buffer, > > > > > > > + * or NULL if unsuccessful > > > > > > > + */ > > > > > > > +static void * > > > > > > > +allocate_initrd_mem (int initrd_pages) > > > > > > > +{ > > > > > > > + grub_addr_t max_addr; > > > > > > > + > > > > > > > + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) > > > > > > > + return NULL; > > > > > > > + > > > > > > > + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; > > > > > > > > > > > > I do not understand this. Why do not pass simply > > > > INITRD_MAX_ADDRESS_OFFSET > > > > > > instead of max_addr to grub_efi_allocate_pages_real()? > > > > > > > > > > > On ARM it's common for RAM to start at address different from 0 > > > > > > > > OK, but, AIUI we have to load initrd no higher than > > > > INITRD_MAX_ADDRESS_OFFSET. > > > > So, we do not care where the region starts. We care where region ends. > > > > Am I missing something? > > > > > > > The limit is relative to the start of RAM. > > > > OK, then it make sense. Thanks for clarification. I would just > > ask for a comment to avoid reader confusion. > > Would moving this function next to the comment block this patch adds > to the top of the file be sufficient? What if somebody adds another function before that one? So, please add a comment into the function body. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c index 8cd44230d..7e989c2b9 100644 --- a/grub-core/loader/arm64/linux.c +++ b/grub-core/loader/arm64/linux.c @@ -35,6 +35,23 @@ GRUB_MOD_LICENSE ("GPLv3+"); +/* + * As per linux/Documentation/arm/Booting + * ARM initrd needs to be covered by kernel linear mapping, + * so place it in the first 512MB of DRAM. + * + * As per linux/Documentation/arm64/booting.txt + * ARM64 initrd needs to be contained entirely within a 1GB aligned window + * of up to 32GB of size that covers the kernel image as well. + * Since the EFI stub loader will attempt to load the kernel near start of + * RAM, place the buffer in the first 32GB of RAM. + */ +#ifdef __arm__ +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) +#else /* __aarch64__ */ +#define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) +#endif + static grub_dl_t my_mod; static int loaded; @@ -194,6 +211,25 @@ grub_linux_unload (void) return GRUB_ERR_NONE; } +/* + * This function returns a pointer to a legally allocated initrd buffer, + * or NULL if unsuccessful + */ +static void * +allocate_initrd_mem (int initrd_pages) +{ + grub_addr_t max_addr; + + if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE) + return NULL; + + max_addr += INITRD_MAX_ADDRESS_OFFSET - 1; + + return grub_efi_allocate_pages_real (max_addr, initrd_pages, + GRUB_EFI_ALLOCATE_MAX_ADDRESS, + GRUB_EFI_LOADER_DATA); +} + static grub_err_t grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)), int argc, char *argv[]) @@ -222,7 +258,8 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)), grub_dprintf ("linux", "Loading initrd\n"); initrd_pages = (GRUB_EFI_BYTES_TO_PAGES (initrd_size)); - initrd_mem = grub_efi_allocate_pages (0, initrd_pages); + initrd_mem = allocate_initrd_mem (initrd_pages); + if (!initrd_mem) { grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
The 32-bit arm Linux kernel is built as a zImage, which self-decompresses down to near start of RAM. In order for an initrd/initramfs to be accessible, it needs to be placed within the first ~768MB of RAM. The initrd loader built into the kernel EFI stub restricts this down to 512MB for simplicity - so enable the same restriction in grub. For arm64, the requirement is within a 1GB aligned 32GB window also covering the (runtime) kernel image. Since the EFI stub loader itself will attempt to relocate to near start of RAM, force initrd to be loaded completely within the first 32GB of RAM. Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> --- grub-core/loader/arm64/linux.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) -- 2.11.0 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel