Home
last modified time | relevance | path

Searched hist:"8 c06f0d9" (Results 1 – 1 of 1) sorted by relevance

/openbmc/linux/arch/powerpc/boot/
H A Dcrt0.S8c06f0d9 Tue Feb 10 22:55:44 CST 2015 Jeremy Kerr <jk@ozlabs.org> powerpc/boot: Fix stack corruption in epapr entry point

Currently, a 64-bit little-endian zImage.epapr won't boot in epapr mode,
as we never return from platform_init.

Before entering C, we initialise our stack by setting r1 16 bytes below
the end of the _bss_stack:

stwu r0,-16(r1) /* establish a stack frame */

However, the called function will save the caller's lr in the caller's
frame's lr save area, at -16(r1) to -32(r1).

This means that writes to the fdt variable will corrupt the saved link
register:

0000000020c06018 l O .bss 0000000000001000 _bss_stack
0000000020c07018 l O .bss 0000000000000008 fdt

We'll need at least 32 bytes in the initial stack frame, to handle the
LR save area. We bump this to 112 bytes, as that'll be the max required
by ABIv1.

Thanks to Alistair Popple for debugging help.

Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
8c06f0d9 Tue Feb 10 22:55:44 CST 2015 Jeremy Kerr <jk@ozlabs.org> powerpc/boot: Fix stack corruption in epapr entry point

Currently, a 64-bit little-endian zImage.epapr won't boot in epapr mode,
as we never return from platform_init.

Before entering C, we initialise our stack by setting r1 16 bytes below
the end of the _bss_stack:

stwu r0,-16(r1) /* establish a stack frame */

However, the called function will save the caller's lr in the caller's
frame's lr save area, at -16(r1) to -32(r1).

This means that writes to the fdt variable will corrupt the saved link
register:

0000000020c06018 l O .bss 0000000000001000 _bss_stack
0000000020c07018 l O .bss 0000000000000008 fdt

We'll need at least 32 bytes in the initial stack frame, to handle the
LR save area. We bump this to 112 bytes, as that'll be the max required
by ABIv1.

Thanks to Alistair Popple for debugging help.

Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>