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

Sat Aug 5 14:19:10 UTC 2017

On Sat, Aug 5, 2017 at 10:01 AM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>>
>> 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).

oh, good point..  I can try that

> 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.

hmm, well I'll give a quick try w/ your bootaa64.efi, but I guess this
is probably something board specific.

Could you:

  $(CROSS_COMPILE)-addr2line -e u-boot 7ef8d878

while you still have the build handy?

BR,
-R