(adding Heinrich and Guillaume again)
On Mon, 18 Nov 2019 at 19:51, Mark Rutland <mark.rutland@xxxxxxx> wrote:
>
> On Mon, Nov 18, 2019 at 07:15:04PM +0100, Ard Biesheuvel wrote:
> > On Mon, 18 Nov 2019 at 19:10, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> > >
> > > On Mon, Nov 18, 2019 at 07:42:51PM +0200, Cristian Ciocaltea wrote:
> > > > I'm trying to boot the Linux kernel on RaspberryPi Zero via GRUB2,
> > > > which in turn is executed by U-Boot as an UEFI binary.
> > > >
> > > > However, I'm facing data abort issues in efi_get_memory_map()
> > > > that seem to be related to some ldrd instructions generated by the
> > > > compiler.
> > > >
> > > > To simplify the investigation, I temporarily gave up on GRUB2 and
> > > > started directly the Linux kernel via U-Boot bootefi command.
> > > > The result is an immediate crash at PC 0x92c8:
> > > >
> > > > data abort
> > > > pc : [<1c6b12c8>] lr : [<1c6b1558>]
> > > > reloc pc : [<fe76a2c8>] lr : [<fe76a558>]
> > > > sp : 1db43b30 ip : 00000000 fp : 1db43cc0
> > > > r10: 20494249 r9 : ffffffff r8 : 00000000
> > > > r7 : 1db43b3c r6 : 00000000 r5 : 1db43bfa r4 : 1db43bb0
> > > > r3 : 1db43b9c r2 : 00000028 r1 : 00000000 r0 : 1df4f828
> > > > Flags: nZCv IRQs off FIQs off Mode SVC_32
> > > > Code: e3a02028 e3a01000 e527100c e5832000 (e1c420d4)
> > > > UEFI image [0x1c6a8000:0x1cb2ffff] pc=0x92c8 '/boot\zImage'
> > > > Resetting CPU ...
> > > >
> > > > The related disassembled section shows the *ldrd* instruction
> > > > in the context of the following statement:
> > > > *map->map_size = *map->desc_size * 32;
> > > >
> > > > drivers/firmware/efi/libstub/efi-stub-helper.c:90
> > > > *map->desc_size = sizeof(*m);
> > > > 92ac: e5913008 ldr r3, [r1, #8]
> > > > drivers/firmware/efi/libstub/efi-stub-helper.c:84
> > > > {
> > > > 92b0: e1a04001 mov r4, r1
> > > > drivers/firmware/efi/libstub/efi-stub-helper.c:85
> > > > efi_memory_desc_t *m = NULL;
> > > > 92b4: e28d7018 add r7, sp, #24
> > > > linux/drivers/firmware/efi/libstub/efi-stub-helper.c:90
> > > > *map->desc_size = sizeof(*m);
> > > > 92b8: e3a02028 mov r2, #40 ; 0x28
> > > > 92c4: e5832000 str r2, [r3]
> > > > linux/drivers/firmware/efi/libstub/efi-stub-helper.c:91
> > > > *map->map_size = *map->desc_size * 32;
> > > > 92c8: e1c420d4 ldrd r2, [r4, #4]
> > >
> > > At this point, r4 is 16-byte aligned, so that's a misaligned LDRD.
> > >
> > > Looking at version 2.8of the UEFI spec, in section 2.3.5 "AArch32
> > > Platforms", it states that SCTLR should be configured:
> > >
> > > | A=0, U=1 on ARMv6 and ARMv7
> > >
> > > ... which IIUC should permit a misaligned LDRD. Is U-Boot definitely
> > > configuring SCTLR that way? Or has it perhaps set A=1, U=0?
> >
> > LDRD requires word alignment only, no?
>
> Looking at the ARMv6 ARM ARM, I see mention of modulo-8 alignemnt
> checking (specifically for LDRD/STRD) when A=1, U=0. Unless I've
> misunder
>
> See A2.7.3 "Endian configuration and control" in ARM DDI 0100I. Table
> A2-6 and A2-8 both suggest that, with A2-8 saying that a Data Abort
> would result.
>
You are right.
I have added Heinrich to cc [again] - perhaps he knows whether u-boot
always adheres to this UEFI requirement?
