Re: [Buildroot] [PATCH v2 1/6] boot/grub2: add support to build multiple Grub2 configurations in the same build

From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: "Köry Maincent" <kory.maincent@bootlin.com>
Cc: thomas.petazzoni@bootlin.com, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2 1/6] boot/grub2: add support to build multiple Grub2 configurations in the same build
Date: Tue, 21 Sep 2021 21:41:05 +0200	[thread overview]
Message-ID: <20210921194105.GA3176@scaer> (raw)
In-Reply-To: <20210921194944.53b0cacc@kmaincent-XPS-13-7390>

Köry, All,

On 2021-09-21 19:49 +0200, Köry Maincent spake thusly:
> On Tue, 21 Sep 2021 18:37:27 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > >  GRUB2_CONF_OPTS = \
> > > -	--target=$(GRUB2_TARGET) \
> > > -	--with-platform=$(GRUB2_PLATFORM) \
> > > +	--host=$(GNU_TARGET_NAME) \
> > > +	--build=$(GNU_HOST_NAME) \
> > >  	--prefix=/ \
> > >  	--exec-prefix=/ \
> > >  	--disable-grub-mkfont \
> > > @@ -147,34 +160,48 @@ HOST_GRUB2_CONF_OPTS = \
> > >  	--enable-libzfs=no \
> > >  	--disable-werror  
> > As Thomas previously suggested, I think we can just drop GRUB2_CONF_OPTS
> > and just put the options, even shared , directly in the loop [...]
> His suggestion was to only keep out of GRUB2_CONF_OPTS the two parameterized
> options "--target" and "--with-platform". If you prefer to drop all the
> options from GRUB2_CONF_OPTS, I can do that.

Ah, right, I misread what he wrote. But once we move some options out of
GRUB2_CONF_OPTS, and since it is used in a single place, does it make
sense to keep it now that we no longer are an autotools-package?

> > > +		$(INSTALL) -D -m 0644 boot/grub2/grub.cfg
> > > $(GRUB2_CFG_$(tuple)) ; \
> > > +		$(if $(findstring $(GRUB2_PLATFORM_$(tuple)), pc), \
> > > +			cat $(HOST_DIR)/lib/grub/$(tuple)/cdboot.img
> > > $(GRUB2_IMAGE_$(tuple)) > \
> > > +				$(BINARIES_DIR)/grub-eltorito.img \
> > > +		) \
> > > +		$(if $(findstring $(GRUB2_PLATFORM_$(tuple)), efi), \
> > > +			echo $(notdir $(GRUB2_IMAGE_$(tuple))) > \
> > > +
> > > $(BINARIES_DIR)/efi-part/startup_$(GRUB2_TARGET_$(tuple)).nsh \  
> > 
> > But the previous path 'efi-part/startup.nsh' is where the post-build
> > scripts and genimage config files look for:
> > 
> >     $ git grep -E '\.nsh'
> > 
> > So, by changing the place where the .nsh is stored, you are breaking
> > those boards... Unless I missed something?
> 
> Yes, indeed it will break few post-build script.

Then those that are broken must be fixed.

> By default the EFI will look at efi/boot/bootx64.efi or efi/boot/bootia32.efi
> if the startup.nsh file is not present. So board should boot without that file.

But then, is startup_{i386,x86_64,arm,aarch64}.nsh even consulted?

As I understand it, and without access to the UEFI specifications, it
looks like startup.nsh is the only file to be read by a (compliant?)
UEFI bios.

> > And I am not sure how to fix that, in the end... Especially the systemd
> > case (meh).
> Me neither. Maybe we can let it like v1, and the 64-bit EFI configuration will
> be the one used if both 32-bit EFI and 64-bit EFI are selected.

Well, the ultimate goal is to haev a single USB-stick or CDROM that can
boot on all three systems:
  - legacy BIOS
  - 32-bit UEFI
  - 64-bit UEFI

So, if the startup.nsh script is to be provided, it should cover the two
UEFI cases. A 32-bit UEFI bios can't load a 64-bit payload, and
conversely, a 65-bit UEFI bios can't load a 32-bit payload.

So, if startup.nsh is mandatory, we have an impossible situation...

So, I wonder if startup.nsh is even needed at all, and if we should not
just drop it altogether, and just rely, s you explained earlier, on the
actual naming of the payload: efi/boot/bootia32.efi on 32-bit UEFI, or
efi/boot/bootx64.efi on 64-bit UEFI.

And drop the creation of startup.nsh in gummiboot and systemd.

And fixup the post-build scripts accordingly...

But as I said earlier: I do not have access to the UEFI specifications
(they are free-as-in-beer to download and read, not implement or use,
so by downloading them, I would have to stop reviewing this series as
that would count as a use of the specs...)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@lists.buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot