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 <dki...@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 <dki...@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.lindh...@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
