(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
>
