On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Rob Clark robdclark@gmail.com Date: Sun, 6 Aug 2017 11:34:15 -0400
On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark robdclark@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/e...
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