On Sun, Aug 6, 2017 at 10:28 AM, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Sun, 6 Aug 2017 15:16:09 +0200 (CEST) From: Mark Kettenis mark.kettenis@xs4all.nl
Things are already broken before that commit though, so there is another problem. I'll see if I can figure out what it is...
data abort pc : [<7ef59160>] lr : [<7ef59118>] reloc pc : [<4a003160>] lr : [<4a003118>] sp : 7af2b820 ip : 7af69635 fp : 7ef5aee4 r10: 00000005 r9 : 7af35ee0 r8 : 7efb4490 r7 : 7af695e8 r6 : 7af69620 r5 : 0000005c r4 : 7af2b828 r3 : 7efae477 r2 : 0000005c r1 : 0000002f r0 : 00000000 Flags: nzCv IRQs off FIQs off Mode SVC_32
addr2line -e u-boot.bin 0x4a003160 /home/kettenis/tmp/rclark/u-boot/include/efi_loader.h:204
which is the ascii2unicode() function which is used in efi_disk_add_dev() and indeed does 16-bit stores to potentiaslly unaligned memory. And yes, adding __packed to struct efi_device_file_path will trigger the unaligned access in this case.
Hmm, I could see that. Have you had a chance to try with "efi_loader: hack for archs that cannot do unaligned accesses"? (That patch should probably be squashed back in to various earlier patches, but I figured keeping it separate for now would be easier to review.) ascii2unicode() is probably only the first place that would hit unaligned accesses..
But that all said, [1] seems to imply armv7 *can* do unaligned accesses. So maybe this is a banana-pi specific issue. Maybe some cp15 bit not set correctly? (Otherwise I think I should have it this issue in travis with tests that load grub.efi on various qemu platforms.)
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.htm...
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.
BR, -R