When first added, the ARM64 generic DT image started with `adr x1, 0'.
With the addition of the optional EFI entry point, a nop with an
optional MZ magic needed to be added at the start of the binary and so
`adr x1, 0' moved further down.
This 0 however is interpreted relative to the program counter and thus
the stack was now setup not from the start of the image down, but from
the location at which the adr instruction is located.
This happens to be 0x48, which not only overwrites the header during
execution, but also is not aligned to 16 bytes.
This issue went unnoticed so far, because the stack is only used to
find out the available memory (either from FDT or EFI boot service)
after which the stack is set up at a properly aligned fixed location
for the remainder of barebox' execution.
Under KVM however, this quickly crashes on the first stack access:
ldr x0, =0x4007fff8
mov sp, x0
stp x0, x1, [sp] // <-- data abort
Thus fix the code to grow the stack down from the first address.
Fixes: 742e78976dd4 ("ARM64: add optional EFI stub")
Signed-off-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
---
arch/arm/cpu/board-dt-2nd-aarch64.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/board-dt-2nd-aarch64.S b/arch/arm/cpu/board-dt-2nd-aarch64.S
index 030366c1cbf5..2ea13d20b450 100644
--- a/arch/arm/cpu/board-dt-2nd-aarch64.S
+++ b/arch/arm/cpu/board-dt-2nd-aarch64.S
@@ -22,7 +22,7 @@ ENTRY("start_dt_2nd")
.int .Lpe_header_offset /* reserved (PE-COFF offset) */
.asciz "barebox" /* unused for now */
2:
- adr x1, 0
+ adr x1, _text - .
mov sp, x1
/* Stack now grows into the 0x80000 image load offset specified
* above. This is more than enough until FDT /memory is decoded.
--
2.39.5
