From: Jonathan Gray <jsg@jsg.id.au>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
Date: Tue, 10 Oct 2017 02:35:53 +1100 [thread overview]
Message-ID: <20171009153553.GC66255@largo.jsg.id.au> (raw)
In-Reply-To: <CAF6AEGvCVj6RufwObcsqSGbE2JB9ULy8iOi3uGn0GEQnor+dvw@mail.gmail.com>
On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote:
> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> >> 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>
> >> >
> >> > Thanks for looking into this. While this lets armv7/bootarm.efi
> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> >> >
> >> > What is the easiest way to get U-Boot to display these paths
> >> > to be able to compare the current behaviour to 2017.09?
> >> >
> >>
> >> in grub, there is the lsefi command, not sure if the OpenBSD
> >> bootloader has something similar?
> >>
> >> u-boot implements that device-path to text protocol, so it should be
> >> pretty easy to implement something like this if not.
> >>
> >> BR,
> >> -R
> >
> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> > is no longer seen. Is it possible having U-Boot on mmc but directing
> > it to load off usb is somehow involved here?
>
> There is no requirement that efi payload and u-boot are on the same
> device. The distro bootcmd stuff will just look for
> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> one.
>
> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM
> or legacy boards, in the former case we can construct something more
> realistic. Although the bootloader shouldn't really care.
I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code
in master only gives types of 1 (Hardware Device Path) and
3 (Messaging Device Path).
It is DM in this case:
U-Boot> dm tree
Class Probed Driver Name
----------------------------------------
root [ + ] root_drive root_driver
simple_bus [ + ] generic_si |-- soc
gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000
serial [ + ] serial_bcm | |-- serial at 7e215040
mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000
blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk
video [ + ] bcm2835_vi | |-- hdmi at 7e902000
vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0
usb [ + ] dwc2_usb | `-- usb at 7e980000
usb_hub [ + ] usb_hub | `-- usb_hub
usb_hub [ + ] usb_hub | `-- usb_hub
eth [ + ] smsc95xx_e | |-- smsc95xx_eth
usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage
blk [ ] usb_storag | `-- usb_mass_storage.lun0
simple_bus [ ] generic_si `-- clocks
>
> > efi_bootdp obtained from the loaded image protocol
> >
> > 2017.09
> >
> > Scanning usb 0:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > reading efi/boot/bootaa64.efi
> > 78959 bytes read in 76 ms (1013.7 KiB/s)
> > ## Starting EFI application at 01000000 ...
> > Scanning disk sdhci at 7e300000.blk...
> > Scanning disk usb_mass_storage.lun0...
> > Found 2 disks
> > efi_diskprobe
> > efi_device_path_depth looking for type 4 i=0 type 4
> > depth=0
> > i=0
> > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> > i=1
> > efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
> >>> OpenBSD/arm64 BOOTAA64 0.8
> > boot>
> > booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330
> >
> > git + patch
>
>
> I assume you are referring to this patch? It should only add
> additional per-partion "disk" objects. (In UEFI terminology each
> partition is a "disk" object.)
Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
The problem seems to be elsewhere as dropping that I still see:
## Starting EFI application at 01000000 ...
Scanning disk sdhci at 7e300000.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disks
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 1
efi_device_path_depth looking for type 4 i=1 type 3
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 3
efi_device_path_depth no match for type 4
depth=-1
i=0
i=1
i=2
i=3
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
od1000 (edk2) booting off sata:
INFO: PSCI Power Domain Map:
INFO: Domain Node : Level 1, parent_node -1, State ON (0x0)
INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
NOTICE: BL3-1:
NOTICE: BL3-1: Built : 14:04:15, Apr 9 2016
INFO: BL3-1: Initializing runtime services
INFO: BL3-1: Preparing for EL3 exit to normal world
INFO: BL3-1: Next image address = 0x8000e80000
INFO: BL3-1: Next image spsr = 0x3c9
Press ESCAPE for boot options .....efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 2
efi_device_path_depth looking for type 4 i=1 type 1
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 4
depth=3
i=0
efi_bootdp=A dp=A
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
next prev parent reply other threads:[~2017-10-09 15:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-08 15:33 [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices Rob Clark
2017-10-09 3:33 ` Jonathan Gray
2017-10-09 10:52 ` Rob Clark
2017-10-09 12:25 ` Jonathan Gray
2017-10-09 14:17 ` Rob Clark
2017-10-09 15:35 ` Jonathan Gray [this message]
2017-10-09 16:06 ` Rob Clark
2017-10-09 16:22 ` Heinrich Schuchardt
2017-10-09 17:02 ` Rob Clark
2017-10-09 16:41 ` Jonathan Gray
2017-10-09 17:06 ` Rob Clark
2017-10-09 17:48 ` Jonathan Gray
2017-10-09 18:20 ` Rob Clark
2017-10-09 18:36 ` Peter Robinson
2017-11-18 4:25 ` Jonathan Gray
2017-11-21 5:59 ` Jonathan Gray
2017-11-21 12:01 ` Jonathan Gray
2017-10-09 4:43 ` [U-Boot] " Alexander Graf
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=20171009153553.GC66255@largo.jsg.id.au \
--to=jsg@jsg.id.au \
--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