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
> ---
> 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
