u-boot.git/lib/efi_loader/efi_disk.c, branch v2017.11

efi_loader: don't increment part twice per loop

2017-10-10T16:14:05+00:00

Correct a mistake in the part number handling of commit
16a73b249d138fedeb188710533902ed7aac1ddc and only increment part once
per loop.

Signed-off-by: Jonathan Gray 
Tested-by: Peter Robinson 
Signed-off-by: Alexander Graf

efi_loader: search all possible disk partitions

2017-10-10T07:56:04+00:00

When searching for partitions don't stop if a partition is not present
for a given partition number as there may be valid partitions after.

Search for up to MAX_SEARCH_PARTITIONS matching the other callers of
part_get_info().

This allows OpenBSD to boot via the efi_loader on rpi_3 again after
changes made after U-Boot 2017.09.  With MBR partitioning OpenBSD will
by default use the fourth partition for the 0xA6 (OpenBSD) partition.

Signed-off-by: Jonathan Gray 
Signed-off-by: Alexander Graf

efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09T05:00:38+00:00

This fixes an issue with OpenBSD's bootloader, and I think should also
fix a similar issue with grub2 on legacy devices.  In the legacy case
we were creating disk objects for the partitions, but not also the
parent device.

Reported-by: Jonathan Gray 
Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_loader: add file/filesys support

2017-09-20T08:43:54+00:00

fallback.efi (and probably other things) use UEFI's simple-file-system
protocol and file support to search for OS's to boot.

Signed-off-by: Rob Clark 
[agraf: whitespace fixes, unsigned fixes]
Signed-off-by: Alexander Graf

efi_loader: use proper device-paths for partitions

2017-09-20T08:34:42+00:00

Also, create disk objects for the disk itself, in addition to the
partitions.  (UEFI terminology is a bit confusing, a "disk" object is
really a partition.)  This helps grub properly identify the boot device
since it is trying to match up partition "disk" object with it's parent
device.

Now instead of seeing devices like:

  /File(sdhci@07864000.blk)/EndEntire
  /File(usb_mass_storage.lun0)/EndEntire

You see:

  /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
  /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c00000000,1,1)/EndEntire
  /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,200000,dd904a8c00000000,1,1)/EndEntire
  /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c00000000,1,1)/EndEntire
  /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire
  /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,60000,38ca680200000000,1,1)/EndEntire
  /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca680200000000,1,1)/EndEntire
  /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca680200000000,1,1)/EndEntire
  /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca680200000000,1,1)/EndEntire

This is on a board with single USB disk and single sd-card.  The
UnknownMessaging(1d) node in the device-path is the MMC device,
but grub_efi_print_device_path() hasn't been updated yet for some
of the newer device-path sub-types.

This patch is inspired by a patch originally from Peter Jones, but
re-worked to use efi_device_path, so it doesn't much resemble the
original.

Signed-off-by: Rob Clark 
[agraf: s/unsigned/unsigned int/]
Signed-off-by: Alexander Graf

efi_disk: efi_disk_rw_blocks is not an API function

2017-09-18T21:53:56+00:00

There is no need to use attribute EFIAPI for
efi_disk_rw_blocks. It is not an API function.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf

efi_loader: remove more double EFI_EXIT() in efi_disk.c

2017-07-26T06:56:15+00:00

Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_loader: disk: iterate only over valid block devices

2017-07-19T12:14:41+00:00

The efi_loader currently stops iterating over the available
block devices stopping at the first device that fails.
This may imply that no block device is found.

With the patch efi_loader only iterates over valid devices.

It is based on patch
06d592bf52f6 (dm: core: Add uclass_first/next_device_check())
which is currently in u-boot-dm.git.

For testing I used an odroid-c2 with a dts including
&sd_emmc_a {
	status = "okay";
};
This device does not exist on the board and cannot be initialized.

Without the patch:

=> bootefi hello
## Starting EFI application at 01000000 ...
WARNING: Invalid device tree, expect boot to fail
mmc_init: -95, time 1806
Found 0 disks
Hello, world!
## Application terminated, r = 0

With the patch:

=> bootefi hello
## Starting EFI application at 01000000 ...
WARNING: Invalid device tree, expect boot to fail
mmc_init: -95, time 1806
Scanning disk mmc@70000.blk...
Scanning disk mmc@72000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 9
Scanning disk mmc@74000.blk...
Found 3 disks
Hello, world!
## Application terminated, r = 0

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Andreas Färber 
Signed-off-by: Alexander Graf

efi_loader: refactor efi_open_protocol

2017-07-19T12:14:23+00:00

efi_open_protocol was implemented to call a protocol specific open
function to retrieve the protocol interface.

The UEFI specification does not know of such a function.

It is not possible to implement InstallProtocolInterface with the
current design.

With the patch the protocol interface itself is stored in the list
of installed protocols of an efi_object instead of an open function.

Signed-off-by: Heinrich Schuchardt 
[agraf: fix efi gop support]
Signed-off-by: Alexander Graf

disk: convert CONFIG_ISO_PARTITION to Kconfig

2017-01-28T13:47:35+00:00

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrick Delaunay