On 01/08/2018 03:11 PM, Simon Glass wrote:
Hi Stephen,
On 8 January 2018 at 11:34, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 01/07/2018 08:40 PM, Simon Glass wrote:
Hi Stephen,
On 19 December 2017 at 18:30, Stephen Warren <swar...@wwwdotorg.org> wrote:
From: Stephen Warren <swar...@nvidia.com>
U-Boot typically uses a hard-coded value for the stack pointer before
relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
the initial SP at run-time. This is useful to avoid hard-coding addresses
into U-Boot, so that can be loaded and executed at arbitrary addresses and
thus avoid using arbitrary addresses at runtime. This option's value is
the offset added to &_bss_start in order to calculate the stack pointer.
This offset should be large enough so that the early malloc region, global
data (gd), and early stack usage do not overlap any appended DTB.
I don't see why this is an offset from bss_start - shouldn't it be bss_end?
BSS can vary in size based on the set of config options enabled, code
growth/shrinkage, etc. Thus, basing the initial SP address on bss_end would
provide too much variability, and hence would be unsafe, whereas basing the
initial SP address on bss_start always provides the exact same amount of
available stack space (assuming an identical DTB for the comparison).
OK. I suppose we are no worse off anyway, since the DTB can vary in size.
I've sent a patch to check for overflow.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
