> From: Rob Clark <robdcl...@gmail.com>
> Date: Sat, 5 Aug 2017 10:35:08 -0400
> On Sat, Aug 5, 2017 at 10:28 AM, Mark Kettenis <mark.kette...@xs4all.nl>
> >> Date: Sat, 5 Aug 2017 16:01:51 +0200 (CEST)
> >> From: Mark Kettenis <mark.kette...@xs4all.nl>
> >> Unfortunately something in this patch series breaks things for me on a
> >> Banana Pi:
> > And according to git bisect:
> > 4e3e748a50fc3f43e20c7ff407184596d7c9a589 is the first bad commit
> > commit 4e3e748a50fc3f43e20c7ff407184596d7c9a589
> > Author: Peter Jones <pjo...@redhat.com>
> > Date: Wed Jun 21 16:39:02 2017 -0400
> > efi: add some more device path structures
> > Signed-off-by: Peter Jones <pjo...@redhat.com>
> > Signed-off-by: Rob Clark <robdcl...@gmail.com>
> hmm, odd.. it is only adding some #define's and structs that are not
> used until a later commit..
> although it does also make 'struct efi_device_path_mac_addr' __packed,
> which it should have been before. Is this an armv7? I wonder if we
> have some troubles with unaligned accesses on armv7 that we don't have
> on aarch64 (or maybe compiler isn't turning access to device-path
> nodes into byte accesses if it can't do unaligned accesses. (The node
> in the device-path structure are byte-packed.)
This is indeed armv7.
> addr2line the faulting address I guess should confirm that. If this
> is the issue, it's going to be a bit sad since we'll have to do a lot
> of copying back/forth of efi_device_path ptrs to aligned addresses :-/
Sadly that's not going to help you:
$ arm-none-eabi-addr2line -e u-boot 7ef8d878
I suppose it is faulting somewhere in BOOTARM.EFI,
Anyway, removing __packed from struct efi_device_path_file_path makes
me boot again with a tree checked out out with that commit.
Our bootloader code doesn't explicitly enable alignment faults. But
of course the UEFI standard says that for AArc32 platforms:
* Unaligned access should be enabled if supported; Alignment faults
are enabled otherwise.
So the efi_loader code has to align things properly I fear.
U-Boot mailing list