On Sun, Aug 6, 2017 at 2:21 PM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: >> From: Rob Clark <robdcl...@gmail.com> >> Date: Sun, 6 Aug 2017 13:49:43 -0400 >> >> On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis <mark.kette...@xs4all.nl> >> wrote: >> >> From: Rob Clark <robdcl...@gmail.com> >> >> Date: Sun, 6 Aug 2017 11:34:15 -0400 >> >> >> >> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark <robdcl...@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.. > > I suspect qemu simply doesn't emulate the alignment trap. The u-boot > startup code explicitly enables alignment fauls on armv7. See > arch/arm/cpu/armv7/start.S:152. This helps catching bugs!
Hmm, that is a really bad idea with EFI_LOADER.. since the efi payload is inheriting this setting. BR, -R _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot