Hi, > -----Original Message----- > From: Heinrich Schuchardt <xypron.glpk@xxxxxx> > Sent: 19 November 2019 04:16 > To: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Mark Rutland > <Mark.Rutland@xxxxxxx>; Guillaume Gardet <Guillaume.Gardet@xxxxxxx> > Cc: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxx>; Ingo Molnar > <mingo@xxxxxxxxxx>; Kairui Song <kasong@xxxxxxxxxx>; Hans de Goede > <hdegoede@xxxxxxxxxx>; Matthew Garrett <matthewgarrett@xxxxxxxxxx>; > linux-efi <linux-efi@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH 0/1] Temporary fix for data abort on armv6z EFI boot > > On 11/18/19 8:41 PM, Ard Biesheuvel wrote: > > (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: > > Hello Christian, > > could you, please, check if this patch applied to U-Boot v2019.10 resolves your > problem: > > https://github.com/xypron/u-boot-patches/blob/efi-next/0001-arm-arm11- > allow-unaligned-memory-access.patch > > Currently I do not have an ARMv6 board available for testing. (But I just ordered > one.) I tested your patch on top of u-boot v2019.10 and it fixes the armv6 data abort. Thanks a lot! Guillaume > > Best regards > > Heinrich Schuchardt > > >>>>> > >>>>> 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? > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
