On Sun, Jan 22, 2017 at 04:19:36PM -0600, Andrew F. Davis wrote: > spl_init on some boards is called after stack and heap relocation, on > some platforms spl_relocate_stack_gd is called to handle setting the > limit to its value CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN when simple > SPL malloc is enabled during relocation. spl_init should then not > re-assign the old pre-relocation limit when this is defined. > > Signed-off-by: Andrew F. Davis <a...@ti.com> > --- > common/spl/spl.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index 462c3a2b97..abff85a725 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -187,7 +187,9 @@ int spl_init(void) > #ifdef CONFIG_MALLOC_F_ADDR > gd->malloc_base = CONFIG_MALLOC_F_ADDR; > #endif > +#ifndef CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN > gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN; > +#endif > gd->malloc_ptr = 0; > #endif
With fuller context of the function, I don't like this solution. When
we do have CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN we are setting both
malloc_limit and malloc_base down in spl_relocate_stack_gd() and would
not want to overwrite either of them, yes? So what's happening (I
think) is that CONFIG_SYS_MALLOC_F_LEN set for U-Boot proper but are in
the case where it's also not the valid size for SPL. Yes?
So I think, in sum, we should change the just-above-context line:
#if defined(CONFIG_SYS_MALLOC_F_LEN)
into:
#if defined(CONFIG_SYS_MALLOC_F_LEN) && \
!defined(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN)
And comment above it what is going on.
--
Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
