From: Rob Clark <robdclark@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/4] efi_loader: fix disk objects + device-paths
Date: Fri, 21 Jul 2017 14:43:35 -0400 [thread overview]
Message-ID: <20170721184339.3042-1-robdclark@gmail.com> (raw)
Currently u-boot completely gets block-io objects (and their associated
device-paths) wrong, which prevents grub2 from figuring out the boot
device+partition, which prevents it from automatically finding it's
grub.cfg.
Currently efi_loader creates a block-io object per disk, for example on
a board with 3 partitions on an sd-card and 4 partitions on a usb disk:
/File(sdhci at 07864000.blk)/EndEntire
/File(usb_mass_storage.lun0)/EndEntire
at least grub manages to match up the loaded_image device-path, but it
cannot figure out which partition it was on. So you end up with
prefix=(hd1)/EFI/fedora instead of prefix=(hd1,msdos1)/EFI/fedora.
With this patchset, you end up with:
/ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,0000000000000000,1,0)/EndEntire
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,200000,0000000000000000,1,0)/EndEntire
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,0000000000000000,1,0)/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,0000000000000000,1,0)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,0000000000000000,1,0)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,0000000000000000,1,0)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,0000000000000000,1,0)/EndEntire
(Note that "UnknownMessaging(1d)" is actually the MMC node in the device-
path, but grub wasn't updated to print out some of the newer device-path
sub-types.)
Since we use DM to generate the device-paths from u-boot's device
hierarchy, legacy devices will still be broken. I kept them working
as they did previously and tried to minimize the ifdeffery, but things
will get much cleaner when legacy support is removed.
Peter Jones (1):
efi: add some more device path structures
Rob Clark (3):
efi_loader: add udevice to EFI device-path mapping
efi_loader: make disk objects for partitions
efi_loader: use efi_devpath to get correct boot device-path
cmd/bootefi.c | 31 ++++++--
include/efi_api.h | 49 +++++++++++-
include/efi_loader.h | 9 +++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_devpath.c | 175 +++++++++++++++++++++++++++++++++++++++++++
lib/efi_loader/efi_disk.c | 73 +++++++++++++-----
6 files changed, 311 insertions(+), 27 deletions(-)
create mode 100644 lib/efi_loader/efi_devpath.c
--
2.13.0
next reply other threads:[~2017-07-21 18:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 18:43 Rob Clark [this message]
2017-07-21 18:43 ` [U-Boot] [PATCH 1/4] efi: add some more device path structures Rob Clark
2017-07-21 18:43 ` [U-Boot] [PATCH 2/4] efi_loader: add udevice to EFI device-path mapping Rob Clark
2017-07-25 13:57 ` Rob Clark
2017-07-25 16:46 ` Alexander Graf
2017-07-25 17:05 ` Heinrich Schuchardt
2017-07-21 18:43 ` [U-Boot] [PATCH 3/4] efi_loader: make disk objects for partitions Rob Clark
2017-07-23 10:25 ` [U-Boot] [U-Boot, " Heinrich Schuchardt
2017-07-23 19:48 ` Rob Clark
2017-07-21 18:43 ` [U-Boot] [PATCH 4/4] efi_loader: use efi_devpath to get correct boot device-path Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170721184339.3042-1-robdclark@gmail.com \
--to=robdclark@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox