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
