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

[Rob Clark]

On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> From: Rob Clark <robdclark at gmail.com>
>> Date: Sun, 6 Aug 2017 11:34:15 -0400
>>
>> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark <robdclark at gmail.com> wrote:
>> >
>> > I've started trying to hack up test_efi_loader.py to add a test that
>> > loads OpenBSD's bootloader..  kinda muddling through it at this point,
>> > since not a py expert or too familiar w/ u-boot's test framework.  But
>> > I'll see if I can get to the point where I can run the same thing on
>> > various arm7 and aarch64 devices in qemu.
>> >
>>
>> Making a bit of progress on this (running it on a vexpress_ca15_tc2
>> board in qemu).. any hint where I can find BOOTARM.EFI src code?
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/efiboot.c?rev=1.17&content-type=text/x-cvsweb-markup
>
> Your failure below looks a bit different from what I'm getting on the
> Banana Pi now.  There I get stuck because the 2nd BS->HandleProtocol()
> call in efi_main() fails.  Somehow the device path of the registered
> disk devices isn't matched correctly to the boot device path...

that is.. odd.. mind adding in lib/efi_loader/Makefile:

  ccflags-y += -DDEBUG=1

?

(you can make the console output easier to read again w/ #undef DEBUG
at top of efi_console.c)

With my complete patchset (ie. assuming this isn't in the middle of a
bisect between 13/20 and 15/20) the device paths for the diskobj and
EFI_LOADED_IMAGE::DeviceHandle should be constructed identically.
(Ie. the patchset consolidates the two different places it was
constructed before... and also fixes the thing I notice you work
around in efi_diskprobe())

> BTW, the OpenBSD code runs fine without the alignment hack.  Our code
> is pretty minimal and doesn't actualy look into the device path
> components.  It just matches the components based on type and by soing
> memcmp.

Hmm, well I do suspect there are still cases where u-boot could crash
because of unaligned access without the hack.  Although I'm less
convinced that we should need the hack on armv7 and more thinking this
is something specific about banana-pi (or allwinner?).  The
vexpress_ca15_tc2 "board" in qemu seems to be working properly..

Mind sending me or pastebin'ing your u-boot .config?  There are some
different device-path construction depending on legacy vs
CONFIG_DM+CONFIG_BLK (the legacy case *looks* right to me, and is used
by vexpress_ca15_tc2.. so I think it should work..)

If OpenBSD supports the vexpress boards, I guess with a suitable qemu
-sd disk.img I should be able to try booting all the way to OS..

BR,
-R