Re: [PATCH 0/1] Temporary fix for data abort on armv6z EFI boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/18/19 7:02 PM, Ard Biesheuvel wrote:
(adding some people that may be able to help, and removing some others)

On Mon, 18 Nov 2019 at 18:42, Cristian Ciocaltea
<cristian.ciocaltea@xxxxxxxxx> 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]


This instruction looks absolutely fine, so I don't know why this is aborting.
0x1db43bb0+4 is word aligned, as required, and the address seems to be mapped.



I changed the code to avoid the memory access and eventually get
rid of the ldrd instruction:
*map->map_size =        sizeof(*m) * 32;

A subsequent data abort was caused by a similar ldrd instruction
generated in the context of the statement:
*map->map_size += *map->desc_size * EFI_MMAP_NR_SLACK_SLOTS;

The workaround to avoid the ldrd instruction was trickier in that case,
as you may see in the patch, but eventually the kernel was able to boot
successfully, with or without GRUB2 chain-loading. The system looks
stable for the moment, but most probably there are many other similar
statements which were not enabled for this particular use case and still
have the potential to trigger data aborts.

Unfortunately I'm not sure how to further investigate this issue and,
therefore, I would kindly ask for some feedback or suggestions.

Some additional notes:
  - Used GCC 7.3.0 and GCC 8.2.0 based armv6-eabihf toolchains:
    https://toolchains.bootlin.com/releases_armv6-eabihf.html
  - Kernel and root filesystem build process handled by buildroot
  - Tested with kernels: 4.2, 4.3, 4.4

--
2.17.1



As described in

efi_loader: restrict EFI_LOADER to armv7 and armv8 on ARM
https://lists.denx.de/pipermail/u-boot/2019-November/390613.html

booting ARMv5 and ARMv6 via UEFI is not supported by U-Boot.

What would be needed is an implementation of function allow_unaligned()
in arch/arm/cpu/arm1176/sctlr.S (cf. arch/arm/cpu/armv7/sctlr.S).

Best regards

Heinrich




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux