Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

boot: Remove <common.h> and add needed includes

Remove <common.h> from all "boot/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

boot: correct finding the default EFI binary

* The sandbox must not use an arbitrary file name bootsbox.efi but the
file name matching the host architecture to properly boot the respective
file. We already have an include which provides a macro with the name of
the EFI binary. Use it.

* The path to the EFI binary should be absolute.

* The path and the file name must be capitalized to conform to the UEFI
specification. This is important when reading from case sensitive
file systems.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

boot: correct the default sequence of boot methods

The default sequence of boot methods is determined by alphabetical sorting
during linkage.

* efi_mgr must run before efi to be UEFI compliant
* pxe should run as last resort

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

bootmeth: pass size to efi_binary_run()

If we call efi_binary_run() with size parameter set to zero, we get an error

Not a PE-COFF file

Fill the missing value.

Fixes: 1373ffde52e1 ("Merge tag 'v2024.01-rc5' into next")
Fixes: 7017fc54a5bc ("bootmeth: use efi_loader interfaces instead of bootefi command")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Merge tag 'v2024.01-rc5' into next

Prepare v2024.01-rc5

bootmeth: use efi_loader interfaces instead of bootefi command

Now that efi_loader subsystem provides interfaces that are equivalent
with bootefi command, we can replace command invocations with APIs.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

bootflow: bootmeth_efi: don't free buffer

bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Handle fdt not available.

While booting with efi, if fdt isn't available externally,
just use the built-in one.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: set bflow->fname from bootfile name

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Set bootp_arch as hex

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Remove <common.h> and add needed includes

Remove <common.h> from all "boot/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

boot: correct finding the default EFI binary

* The sandbox must not use an arbitrary file name bootsbox.efi but the
file name matching the host architecture to properly boot the respective
file. We already have an include which provides a macro with the name of
the EFI binary. Use it.

* The path to the EFI binary should be absolute.

* The path and the file name must be capitalized to conform to the UEFI
specification. This is important when reading from case sensitive
file systems.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

boot: correct the default sequence of boot methods

The default sequence of boot methods is determined by alphabetical sorting
during linkage.

* efi_mgr must run before efi to be UEFI compliant
* pxe should run as last resort

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

bootmeth: pass size to efi_binary_run()

If we call efi_binary_run() with size parameter set to zero, we get an error

Not a PE-COFF file

Fill the missing value.

Fixes: 1373ffde52e1 ("Merge tag 'v2024.01-rc5' into next")
Fixes: 7017fc54a5bc ("bootmeth: use efi_loader interfaces instead of bootefi command")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Merge tag 'v2024.01-rc5' into next

Prepare v2024.01-rc5

bootmeth: use efi_loader interfaces instead of bootefi command

Now that efi_loader subsystem provides interfaces that are equivalent
with bootefi command, we can replace command invocations with APIs.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

bootflow: bootmeth_efi: don't free buffer

bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Handle fdt not available.

While booting with efi, if fdt isn't available externally,
just use the built-in one.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: set bflow->fname from bootfile name

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Set bootp_arch as hex

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: correct finding the default EFI binary

* The sandbox must not use an arbitrary file name bootsbox.efi but the
file name matching the host architecture to properly boot the respective
file. We already have an include which provides a macro with the name of
the EFI binary. Use it.

* The path to the EFI binary should be absolute.

* The path and the file name must be capitalized to conform to the UEFI
specification. This is important when reading from case sensitive
file systems.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

boot: correct the default sequence of boot methods

The default sequence of boot methods is determined by alphabetical sorting
during linkage.

* efi_mgr must run before efi to be UEFI compliant
* pxe should run as last resort

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

bootmeth: pass size to efi_binary_run()

If we call efi_binary_run() with size parameter set to zero, we get an error

Not a PE-COFF file

Fill the missing value.

Fixes: 1373ffde52e1 ("Merge tag 'v2024.01-rc5' into next")
Fixes: 7017fc54a5bc ("bootmeth: use efi_loader interfaces instead of bootefi command")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Merge tag 'v2024.01-rc5' into next

Prepare v2024.01-rc5

bootmeth: use efi_loader interfaces instead of bootefi command

Now that efi_loader subsystem provides interfaces that are equivalent
with bootefi command, we can replace command invocations with APIs.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

bootflow: bootmeth_efi: don't free buffer

bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Handle fdt not available.

While booting with efi, if fdt isn't available externally,
just use the built-in one.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: set bflow->fname from bootfile name

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Set bootp_arch as hex

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootmeth: pass size to efi_binary_run()

If we call efi_binary_run() with size parameter set to zero, we get an error

Not a PE-COFF file

Fill the missing value.

Fixes: 1373ffde52e1 ("Merge tag 'v2024.01-rc5' into next")
Fixes: 7017fc54a5bc ("bootmeth: use efi_loader interfaces instead of bootefi command")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Merge tag 'v2024.01-rc5' into next

Prepare v2024.01-rc5

bootmeth: use efi_loader interfaces instead of bootefi command

Now that efi_loader subsystem provides interfaces that are equivalent
with bootefi command, we can replace command invocations with APIs.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

bootflow: bootmeth_efi: don't free buffer

bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Handle fdt not available.

While booting with efi, if fdt isn't available externally,
just use the built-in one.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: set bflow->fname from bootfile name

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Set bootp_arch as hex

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootflow: bootmeth_efi: don't free buffer

bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Handle fdt not available.

While booting with efi, if fdt isn't available externally,
just use the built-in one.

Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: set bflow->fname from bootfile name

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Set bootp_arch as hex

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootmeth: efi: Make distro_efi_boot() static

As it is only called in bootmeth_efi.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Init the size before reading the devicetree

The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.

Fix this.

This was reported by someone but I cannot now find the email.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Avoid allocating memory for the EFI file

The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.

However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.

Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.

So overall it seems better to make a change.

Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>

bootstd: Use a function to detect network in EFI bootmeth

This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tidy up reporting of errors

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support booting EFI where multiple options exist

The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.

This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.

To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Tweak bootflow logic for device tree

We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.

This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Replicate the dtb-filename quirks of distroboot

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Also some boards can use a prior-stage FDT if one is not found in the
normal way. Support this and show a message in that case.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Treat DHCP and PXE as bootdev labels

These are associated with the ethernet boot device but do not match its
uclass name, so handle them as special cases.

Provide a way to pass flags through with the bootdev so that we know
how to process it. The flags are checked by the bootmeths, to ensure that
only the selected bootmeth is used.

While these both use the network device, they work quite differently. It
is common to run only one of these, or to run PXE before DHCP. Provide
bootflow flags to control which methods are used. Check these in the two
bootmeths so that only the chosen one is used.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Support reading the device tree with EFI

With EFI booting the device tree is required but is not actually specified
in any way. The normal method is to use a fdtfile environment variable to
get the filename, then look for that file on the media.

Implement this in the bootmeth.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Allow reading an EFI file from the network

At present this bootmeth only supports reading from a filesystem. Add
support for reading from a network also, using DHCP with autoload.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Rename bootdev checkers

These functions return 0 if the check passes, so the names are somewhat
confusing. Rename them.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add an implementation of EFI boot

Add a bootmeth driver which handles EFI boot, using EFI_LOADER.

In effect, this provides the same functionality as the 'bootefi' command
and shares the same code. But the interface into it is via a bootmeth,
so it does not require any special scripts, etc.

For now this requires the 'bootefi' command be enabled. Future work may
tidy this up so that it can be used without CONFIG_CMDLINE being enabled.

There was much discussion about whether this is needed, but it seems
that it is, at least for now.

Signed-off-by: Simon Glass <sjg@chromium.org>