[U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

Sat Aug 5 14:01:51 UTC 2017

> Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=gmail.com;
> 	dkim=pass header.d=gmail.com; dmarc=pass header.from=gmail.com
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=gmail.com; s=20161025;
>         h=mime-version:in-reply-to:references:from:date:message-id:subject:to
>          :cc;
>         bh=qkk49+XF6+Jn7RUjFU/ZFP7/ho5kdUEUNpSrCpqy9yw=;
>         b=knLDTd1vrl7R3BnRReKrxUD1UxYSIahqh5VTND3PEt1cLHtskGRiDc280ADRTm6ffV
>          izImBjr6hq94Qu/Jnbd6kn7+jSDuhDva9FU1/ZndFaNkTUhsatlgtvrK5RzJ38FpwvLa
>          0X7Y8NuVm99K+ijWdKI34YruaZfz47t863L40UYJhjdaj3/TLdIWrC/NzEBiQ/fXemHU
>          8mN1HM9JBD7STB64mMlDSttSTC2vJOPyX81CCbDnXLI/puqcyXewaJ+kW8Km+VDra2xs
>          PIWVzyA0PoV7nIihMbkrv95K7GQgpSOUUL7nlEmAreQoEbCCb8Iw2inSe6LqhN6IbJ4u
>          Js9A==
> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=1e100.net; s=20161025;
>         h=x-gm-message-state:mime-version:in-reply-to:references:from:date
>          :message-id:subject:to:cc;
>         bh=qkk49+XF6+Jn7RUjFU/ZFP7/ho5kdUEUNpSrCpqy9yw=;
>         b=kiBq9lLF93IqOIhjRAbghuqi5rcOJ7mf7OvAvgo8T4qg72k9iEBX84R7yIY7KVyDpX
>          DxV+JJDPePbOtIN3qxpmIZF6vqT/HJ0w+z8RnsUiUGJxGCxTA9R97e+tcB1Ovh7zRIJe
>          JPSP/6/TqRmFgrlIsZdoPZAsypVgTx/AHfdMA/z3l4EOOdSOcd3AOd+sDdGnhCAm2G0+
>          QyAXxkxleKeB3t2AvXKiXpJknXzSb9FxM+0ug0gAPlTTT7d2JFEOZ43gzgLCTTsCVDdL
>          lWiJepjIeynmIuGKwcZJpFdV6C8nx2RMztWLpbhPMrbbR+eLkQcaJnJJrgv859lzbUrM
>          9XhQ==
> X-Gm-Message-State: AHYfb5hmb8q9IgSaZxMt3OsQOUjxd0l+fyjrLiox4JEB/7NaaHlf1K9h
> 	HiWJc8WMqU156stR2hj9qS4oZRxkCuHp0xg=
> X-Received: by 10.25.59.29 with SMTP id i29mr1058615lfa.224.1501880271850;
>  Fri, 04 Aug 2017 13:57:51 -0700 (PDT)
> From: Rob Clark <robdclark at gmail.com>
> Date: Fri, 4 Aug 2017 16:57:50 -0400
> Cc: U-Boot Mailing List <u-boot at lists.denx.de>,
>         Heinrich Schuchardt <xypron.glpk at gmx.de>,
>         Peter Jones <pjones at redhat.com>
> X-CNFS-Analysis: v=2.2 cv=eoad9chX c=1 sm=0 tr=0
> 	a=bdpqe3ZLSLbgpdprsY8WZA==:117 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10
> 	a=D2htVsi0J-IA:10 a=KeKAF7QvOSUA:10 a=pGLkceISAAAA:8 a=NEAV23lmAAAA:8
> 	a=YyEjxAJ5dRpCWmjka9UA:9 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -0.1 () DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU,
> 	FREEMAIL_FROM, SPF_PASS
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis at xs4all.nl
> 
> On Fri, Aug 4, 2017 at 4:41 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >> From: Rob Clark <robdclark at gmail.com>
> >> Date: Fri,  4 Aug 2017 15:31:55 -0400
> >
> > Hi Rob,
> >
> > OpenBSD has been an early adopter of efi_loader and pretty much
> > completely relies on it for booting OpenBSD/armv7 and OpenBSD/arm64.
> > We use our own bootloader which is fairly lightweight.  Obviously we'd
> > like to keep it working if this patchset gets adopted.  We don't make
> > use of EFI variables and don't really plan to make use of them on our
> > ARM platforms.  But obviously we have to deal with device paths...
> >
> >> 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 at 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.
> >
> > ..and what you're sketching out here should work with recent enough
> > versions of our bootloader.
> >
> > However, to me having an ACPI Device Path component in there doesn't
> > make much sense on a board without ACPI.  It certainly doesn't help
> > mapping a boot path back to an actual hardware device.  Wouldn't it be
> > more logical to a Hardware Device Path there instead?  In particular a
> > Memory Mapped Device Path would make a lot of sense as the start
> > address would make it fairly easy to do the mapping.
> >
> 
> It was pretty much an arbitrary choice, and it wouldn't be hard to
> change.  From my reading of the grub code, all it really cares about
> is that there is *some* parent of the "partition" HD device.  I'm not
> really sure what maps best in a UEFI world to the "soc" node in a
> device tree world.  I'm certainly open to changing this.
> 
> It would be cool if you have a chance to give this a try w/ OpenBSD
> and let me know if you run into issues.  I want this to be something
> that works across-distro so I'll try to help as much as I can.  (Not
> sure if there is an OpenBSD port for db410c, but I guess there is
> always qemu..).  Fwiw, if git pull/cherry-pick is easier than grabbing
> patches from list, then [1].

OpenBSD doesn't run on the db410c.  However, our EFI bootloader should
just run.  You can download it from:

  http://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI

for the 64-bit (AArch64) and

  http://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/BOOTARM.EFI

for the 32-bit version (AArch32).

Unfortunately something in this patch series breaks things for me on a
Banana Pi:

U-Boot SPL 2017.09-rc1-00020-g2ad6933c64-dirty (Aug 05 2017 - 15:26:15)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1

U-Boot 2017.09-rc1-00020-g2ad6933c64-dirty (Aug 05 2017 - 15:26:15 +0200) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: LeMaker Banana Pi
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

Setting up a 720x576i composite-pal console (overscan 32x20)
In:    serial
Out:   vga
Err:   vga
SCSI:  Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet at 01c50000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on scsi...
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 6 disks
data abort
pc : [<7ef8d878>]          lr : [<7ef8d874>]
reloc pc : [<4a039878>]    lr : [<4a039874>]
sp : 7af29660  ip : 00000000     fp : 7af29774
r10: 7efec230  r9 : 7af33ee0     r8 : 00000000
r7 : 00000009  r6 : 7ef9e8b8     r5 : 7af296a0  r4 : 7efa4495
r3 : 7af296a0  r2 : 0000008c     r1 : 7af29658  r0 : 00000004
Flags: nzCV  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...                        

resetting ...

Normally it would print something like:

  >> OpenBSD/armv7 BOOTARM 0.8
  boot>

at that stage.