On Sun, Aug 6, 2017 at 10:28 AM, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>> Date: Sun, 6 Aug 2017 15:16:09 +0200 (CEST)
>> From: Mark Kettenis <mark.kette...@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


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.

U-Boot mailing list

Reply via email to