On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote:
> Hi,
>
> Looks like commit 5638790dadae ("zboot: fix stack protector in
> compressed boot phase") breaks booting on arm.
>
> This is all I get from the bootloader on omap3:
>
> Starting kernel ...
>
> data abort
> pc : [<810002d0>] lr : [<100110a8>]
> reloc pc : [<9d6002d0>] lr : [<2c6110a8>]
> sp : 81467c18 ip : 81466bf0 fp : 81466bf0
> r10: 80fc2c40 r9 : 81000258 r8 : 86fec000
> r7 : ffffffff r6 : 81466bf8 r5 : 00000000 r4 : 80008000
> r3 : 81466c14 r2 : 81466c18 r1 : 000a0dff r0 : 00466bf8
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Resetting CPU ...
>
> resetting ...
The reason for this is the following code that was introduced by the
referenced patch:
+ ldr r0, =__stack_chk_guard
+ ldr r1, =0x000a0dff
+ str r1, [r0]
This uses the absolute address of __stack_chk_guard in the decompressor,
which is a self-relocatable image. As with all constructs like the
above, this absolute address doesn't get fixed up, and so it ends up
pointing at invalid memory (in this case 0x466bf8) vs RAM at 0x80000000,
and the decompressor looks to be around 0x81000000.
Such constructs can not be used in the decompressor for exactly this
reason - they need to use PC-relative addressing instead just like
everything else does in head.S.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
