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.)
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?
