[U-Boot] [PATCH 2/5] x86: fsp: Reserve different malloc size before relocation

[Simon Glass]

Hi Bin,

On 27 July 2015 at 01:33, Bin Meng <bmeng.cn at gmail.com> wrote:
> Currently Intel queensbay fsp initializes a CAR size with only 4KiB,
> which is not enough when dm pci is enabled before relocation. Change
> arch/x86/start.s to reserve a small size before fsp_init() is called
> and some bigger size after fsp_init() which can be configured via
> the exisiting CONFIG_MALLOC_F_LEN.
>
> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
> ---
>
>  arch/x86/Kconfig     |  5 +++++
>  arch/x86/cpu/start.S | 10 +++++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e8968a7..afd4a84 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -227,6 +227,11 @@ config FSP_TEMP_RAM_ADDR
>           Stack top address which is used in FspInit after DRAM is ready and
>           CAR is disabled.
>
> +config SYS_MALLOC_F_LEN_PRE_FSP
> +       hex
> +       depends on HAVE_FSP
> +       default 0x800
> +
>  config SMP
>         bool "Enable Symmetric Multiprocessing"
>         default n
> diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
> index 00e585e..cc6fbe9 100644
> --- a/arch/x86/cpu/start.S
> +++ b/arch/x86/cpu/start.S
> @@ -137,7 +137,15 @@ skip_hob:
>         movl    %esp, %ecx
>
>  #if defined(CONFIG_SYS_MALLOC_F_LEN)
> -       subl    $CONFIG_SYS_MALLOC_F_LEN, %esp
> +#ifdef CONFIG_HAVE_FSP
> +       test    %esi, %esi
> +       jnz     1f
> +       subl    $CONFIG_SYS_MALLOC_F_LEN_PRE_FSP, %esp
> +       jmp     2f
> +#endif
> +1:
> +       subl    $CONFIG_SYS_MALLOC_F_LEN, %esp
> +2:
>         movl    %eax, %edx
>         addl    $GD_MALLOC_BASE, %edx
>         movl    %esp, (%edx)
> --
> 1.8.2.1
>

This is a bit of an unfortunate problem. While CONFIG_SYS_MALLOC_F_LEN
is a generic thing (and in fact I'm about to send a series to make x86
use board_init_f_mem() instead of all this code)
CONFIG_SYS_MALLOC_F_LEN_PRE_FSP is not.

One option (with my new series) is to simply change the stack after
board_init_f_mem() returns. Let's see what you think of that series
and then we can revisit this.

Regards,
Simon