On 11/19/23 01:43, Simon Glass wrote:
Hi Heinrich,
On Sat, 18 Nov 2023 at 15:52, Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
On 11/18/23 22:28, Shantur Rathore wrote:
Hi Heinrich,
On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
On 11/16/23 19:45, Shantur Rathore wrote:
On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
On 11/16/23 17:52, Shantur Rathore wrote:
Hi Simon,
Currently bootstd - bootmethod_efi only looks for the default
bootxx64.efi in /EFI/boot folder only.
Generally many distros end up putting their bootloaders in
EFI/<distro> folders like EFI/ubuntu and EFI/debian etc.
In x86 worlds, the NVRAM is modified and new boot entries are added to
support these but in the U-boot world the NVRAM variables are
read-only.
I guess you are referring to UEFI boot options. These typically are not
stored in non-volatile RAM but on a SPI flash device.
Thanks for correcting me.
What would be the best way to implement this?
I was thinking of having a "efi_prefixes" environment variable which
can be set to "ubuntu debian centos" etc and bootmethod_efi can try
all of them. Will bootmethod_efi be able to support multiple entries (
thinking of multiboot ) ?
On my laptop I have:
EFI/Microsoft/Boot/bootmgr.efi
EFI/Microsoft/Boot/memtest.efi
EFI/Boot/bootx64.efi
EFI/Boot/fbx64.efi
EFI/Boot/mmx64.efi
EFI/debian/shimx64.efi
EFI/debian/grubx64.efi
EFI/debian/mmx64.efi
EFI/debian/fbx64.efi
EFI/ubuntu/grubx64.efi
EFI/ubuntu/shimx64.efi
EFI/ubuntu/mmx64.efi
Obviously each installed operating system provides multiple EFI binaries
and non uses the fallback file name BOOT<ARCH>.EFI. A value "ubuntu
debian centos" would not be able to describe which file you are looking
for.
We already have the U-Boot command line eficonfig and efidebug commands
to set up UEFI boot options which can describe which EFI binary to load
and which command line to pass to it. These are considered by the
existing boot flows.
So, I am building a new RockPro64 based cluster and using Canonical
MAAS to set them up automatically, booting them up using DHCP and
installing them over the network.
I configured an Armbian image using Packer to be compatible with MAAS
and it happily installs it. As part of installation process, a
grub-install is run which installs the grub efi,
this EFI ends up in EFI/debian instead of expected EFI/boot.
To be able to make it boot, I have to add commands to move it to
EFI/boot. I am trying to find a way in U-Boot that would allow me to
skip this step.
With eficonfig if I understand correctly, it would need manual
intervention to create boot entries.
If you are installing the shim-signed package on Ubuntu, the EFI boot
option for Ubuntu is set up by EFI/BOOT/BOOT<ARCH>.EFI using the content
of EFI/ubuntu/BOOT<ARCH>.CSV. This is done before ExitBootServices() and
therefore should work with current U-Boot.
Patches are pending upstream to make EFI variables writable from Linux
if they are stored in the RPMB partition in the eMMC. See this series:
https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/
Would it be possible to save it in SPI Flash as the U-Boot environment ?
Currently this is not supported by U-Boot.
The U-Boot environment variables can be stored in lots of different
places SPI flash is only one of these. But none of these locations is
protected from OS access which would be preferable for UEFI variables
for security reasons.
To support boards without eMMC the right way forward would be writing a
new implementation of the OP-TEE standalone MM which writes the
variables to SPI flash instead of the RPMB partition and ensures that
the SPI flash' MMIO registers are protected against access from the
non-secure world.
Thanks for explaining this to me.
This seems like a long way to go, for now what would be an acceptable
solution, some options are
1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu
debian") variable which is ready by bootmeth_efi and used as
efi/<efi_prefix> instead of efi/boot.
2. Improve bootmeth_efi to find all bootxxxx.efi in efi/ folder and
present all them as bootflows to bootstd.
As mentioned in a prior mail ubuntu/bootxxxx.efi and debian/bootxxxx.efi
don't exist. I would prefer not to add any distro specific stuff in
upstream U-Boot. Instead we will continue to drive what Linaro has
suggested to improve U-Boot EFI variables support in Linux.
Is there any metadata in the distro which U-Boot could read to find
out where the EFI file is?
The standardized way to define that meta-data are boot options.
Besides EFI/<vendor>/*.efi installers typically leave a
/EFI/BOOT/BOOT<arch>.EFI on the ESP which U-Boot will pick up by default
if no boot option is specified. If Armbian does not do this, it might be
something to fix there.
Best regards
Heinrich
