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