Commit graph

9 commits

Author SHA1 Message Date
Mathew McBride
484e701d74 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>
2023-04-26 08:43:05 -04:00
Simon Glass
d80bb4f958 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>
2023-04-26 08:43:04 -04:00
Simon Glass
9f8351659a 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>
2023-04-26 08:43:04 -04:00
Simon Glass
47dd6b4d7d 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>
2023-03-08 11:40:49 -08:00
Simon Glass
d9f48579dc 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>
2023-01-23 18:11:41 -05:00
Simon Glass
e890e8c4cb 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>
2023-01-23 18:11:40 -05:00
Simon Glass
3e18860e3f 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>
2023-01-23 18:11:40 -05:00
Simon Glass
865328c314 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>
2023-01-23 18:11:40 -05:00
Simon Glass
acfa9bdfa7 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>
2022-04-25 10:00:04 -04:00