summaryrefslogtreecommitdiff
path: root/lib/efi_loader/efi_disk.c
AgeCommit message (Collapse)Author
2019-04-23efi_loader: consistent naming of protocol GUIDsHeinrich Schuchardt
We should consistently use the same name for protocol GUIDs as defined in the UEFI specification. Not adhering to this rule has led to duplicate definitions for the EFI_LOADED_IMAGE_PROTOCOL_GUID. Adjust misnamed protocol GUIDs. Adjust the text for the graphics output protocol in the output of the `efidebug dh` command. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2018-12-02efi_loader: rename parent to headerHeinrich Schuchardt
Rename the component parent of some EFI objects to header. This avoids misunderstandings. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02efi_loader: eliminate handle memberHeinrich Schuchardt
A pointer to a struct efi_object is a handle. We do not need any handle member in this structure. Let's eliminate it. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-10Remove <inttypes.h> includes and PRI* usages in printf() entirelyMasahiro Yamada
In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-10SPDX: Convert a few files that were missed beforeTom Rini
As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-10efi_loader: correct efi_disk_registerHeinrich Schuchardt
efi_disk_register should return as status code (efi_status_t). Disks with zero blocks should be reported as 'not ready' without throwing an error. This patch solves a problem running OpenBSD on system configured with CONFIG_BLK=n (e.g. i.MX6). Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22efi_loader: correct EFI_BLOCK_IO_PROTOCOL definitionsHeinrich Schuchardt
Add the revision constants. Depending on the revision additional fields are needed in the media descriptor. Use efi_uintn_t for number of bytes to read or write. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22efi_loader: make efi_disk_create_partitions a global symbolHeinrich Schuchardt
Up to now we have been using efi_disk_create_partitions() to create partitions for block devices that existed before starting an EFI application. We need to call it for block devices created by EFI applications at run time. The EFI application will define the handle for the block device and install a device path protocol on it. We have to use this device path as stem for the partition device paths. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22efi_loader: make efi_block_io_guid a global symbolHeinrich Schuchardt
The GUID of the EFI_BLOCK_IO_PROTOCOL is needed in different code parts. To avoid duplication make efi_block_io_guid a global symbol. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22efi_loader: efi_disk_register: correctly determine if_type_nameHeinrich Schuchardt
The interface type name can be used to look up the interface type. Don't confound it with the driver name which may be different. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22efi_loader: correct find simple file system protocolHeinrich Schuchardt
In contrast to the description the code did not split the device path into device part and file part. The code should use the installed protocol and not refer to the internal structure of the the disk object. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22efi_loader: address of the simple file system protocolHeinrich Schuchardt
When installing the the simple file system protocol we have to path the address of the structure and not the address of a pointer to the structure. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-19efi_loader: Setup logical_partition media informationEmmanuel Vadot
When adding a partition, set the logical_partition member in the media structure as mandated by the UEFI spec. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2017-12-01efi_loader: Fix partition offsetsAlexander Graf
Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) tried to introduce the el torito scheme to all partition table types: Spawn individual disk objects for each partition on a disk. Unfortunately, that code ended up creating partitions with offset=0 which meant that anyone accessing these objects gets data from the raw block device instead of the partition. Furthermore, all the el torito logic to spawn devices for partitions was duplicated. So let's merge the two code paths and give partition disk objects good offsets to work from, so that payloads can actually make use of them. Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions) Reported-by: Yousaf Kaukab <yousaf.kaukab@suse.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-01efi_loader: helper function to add EFI object to listHeinrich Schuchardt
To avoid duplicate coding provide a helper function that initializes an EFI object and adds it to the EFI object list. efi_exit() is the only place where we dereference a handle to obtain a protocol interface. Add a comment to the function. Suggested-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-01efi_loader: manage protocols in a linked listHeinrich Schuchardt
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-01efi_loader: efi_disk: use efi_add_protocolHeinrich Schuchardt
Use efi_add_protocol to install protocols. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-01efi_loader: efi_disk: check return value of callocHeinrich Schuchardt
Calloc may return NULL. We should check the return value. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-10-10efi_loader: don't increment part twice per loopJonathan Gray
Correct a mistake in the part number handling of commit 16a73b249d138fedeb188710533902ed7aac1ddc and only increment part once per loop. Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-10-10efi_loader: search all possible disk partitionsJonathan Gray
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 <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-10-09efi_loader: Fix disk dp's for pre-DM/legacy devicesRob Clark
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 <jsg@jsg.id.au> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20efi_loader: add file/filesys supportRob Clark
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 <robdclark@gmail.com> [agraf: whitespace fixes, unsigned fixes] Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20efi_loader: use proper device-paths for partitionsRob Clark
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 <robdclark@gmail.com> [agraf: s/unsigned/unsigned int/] Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-18efi_disk: efi_disk_rw_blocks is not an API functionHeinrich Schuchardt
There is no need to use attribute EFIAPI for efi_disk_rw_blocks. It is not an API function. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-26efi_loader: remove more double EFI_EXIT() in efi_disk.cRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-19efi_loader: disk: iterate only over valid block devicesxypron.glpk@gmx.de
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 <xypron.glpk@gmx.de> Reviewed-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-19efi_loader: refactor efi_open_protocolxypron.glpk@gmx.de
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 <xypron.glpk@gmx.de> [agraf: fix efi gop support] Signed-off-by: Alexander Graf <agraf@suse.de>
2017-01-28disk: convert CONFIG_ISO_PARTITION to KconfigPatrick Delaunay
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
2016-10-19efi: Fix missing EFIAPI specifiersSimon Glass
These are missing in some functions. Add them to keep things consistent. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-08-08efi_loader: disk: Sanitize exposed devicesAlexander Graf
When a target device is 0 bytes long, there's no point in exposing it to the user. Let's just skip them. Also, when an offset is passed into the efi disk creation, we should remove this offset from the total number of sectors we can handle. This patch fixes both things. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-08-08efi_loader: disk: Fix CONFIG_BLK breakageAlexander Graf
When using CONFIG_BLK, there were 2 issues: 1) The name we generate the device with has to match the name we set in efi_set_bootdev() 2) The device we pass into our block functions was wrong, we should not rediscover it but just use the already known pointer. This patch fixes both issues. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-06-06efi_loader: Move to normal debug infrastructureAlexander Graf
We introduced special "DEBUG_EFI" defines when the efi loader support was new. After giving it a bit of thought, turns out we really didn't have to - the normal #define DEBUG infrastructure works well enough for efi loader as well. So this patch switches to the common debug() and #define DEBUG way of printing debug information. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-27Merge git://git.denx.de/u-boot-dmTom Rini
For odroid-c2 (arch-meson) for now disable designware eth as meson now needs to do some harder GPIO work. Signed-off-by: Tom Rini <trini@konsulko.com> Conflicts: lib/efi_loader/efi_disk.c Modified: configs/odroid-c2_defconfig
2016-05-27efi_loader: Add bounce buffer supportAlexander Graf
Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-27dm: efi: Update for CONFIG_BLKSimon Glass
This code does not currently build with driver model enabled for block devices. Update it to correct this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de>
2016-05-17dm: part: Drop the block_drvr tableSimon Glass
This is not needed since we can use the functions provided by the legacy block device support. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-04-18efi_loader: Increase path string to 32 charactersAlexander Graf
Whenever we want to tell our payload about a path, we limit ourselves to a reasonable amount of characters. So far we only passed in device names - exceeding 16 chars was unlikely there. However by now we also pass real file path information, so let's increase the limit to 32 characters. That way common paths like "boot/efi/bootaa64.efi" fit just fine. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-04-18efi_loader: Add el torito supportAlexander Graf
When loading an el torito image, uEFI exposes said image as a raw block device to the payload. Let's do the same by creating new block devices with added offsets for the respective el torito partitions. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-04-18efi_loader: Split drive add into functionAlexander Graf
The snippet of code to add a drive to our drive list needs to get called from 2 places in the future. Split it into a separate function. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-15efi_loader: Pass proper device path in on bootAlexander Graf
EFI payloads can query for the device they were booted from. Because we have a disconnect between loading binaries and running binaries, we passed in a dummy device path so far. Unfortunately that breaks grub2's logic to find its configuration file from the same device it was booted from. This patch adds logic to have the "load" command call into our efi code to set the device path to the one we last loaded a binary from. With this grub2 properly detects where we got booted from and can find its configuration file, even when searching by-partition. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-15efi_loader: Add disk interfacesAlexander Graf
A EFI applications usually want to access storage devices to load data from. This patch adds support for EFI disk interfaces. It loops through all block storage interfaces known to U-Boot and creates an EFI object for each existing one. EFI applications can then through these objects call U-Boot's read and write functions. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Update for various DM changes since posting] Signed-off-by: Tom Rini <trini@konsulko.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-07 11:40:30 +0000