[U-Boot] [PATCH v3 3/3] x86: fsp: Move FspInitEntry call to board_init_f()
Simon Glass
sjg at chromium.org
Sun Jun 7 16:48:37 CEST 2015
On 6 June 2015 at 21:33, Bin Meng <bmeng.cn at gmail.com> wrote:
> The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
> It worked pretty well but looks not that good. Apart from doing too
> much work than just enabling CAR, it cannot read the configuration
> data from device tree at that time. Now we want to move it a little
> bit later as part of init_sequence_f[] being called by board_init_f().
> This way it looks and works better in the U-Boot initialization path.
>
> Due to FSP's design, after calling FspInitEntry it will not return to
> its caller, instead it jumps to a continuation function which is given
> by bootloader with a new stack in system memory. The original stack in
> the CAR is gone, but its content is perserved by FSP and described by
> a bootloader temporary memory HOB. Technically we can recover anything
> we had before in the previous stack, but that is way too complicated.
> To make life much easier, in the FSP continuation routine we just
> simply call fsp_init_done() and jump back to car_init_ret() to redo
> the whole board_init_f() initialization, but this time with a non-zero
> HOB list pointer saved in U-Boot's global data so that we can bypass
> the FspInitEntry for the second time.
>
> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
> Acked-by: Simon Glass <sjg at chromium.org>
> Tested-by: Andrew Bradford <andrew.bradford at kodakalaris.com>
> Tested-by: Simon Glass <sjg at chromium.org>
>
> ---
>
> Changes in v3:
> - Remove #ifdef around x86_fsp_init() declaration
>
> Changes in v2: None
>
> arch/x86/cpu/start.S | 6 +++++-
> arch/x86/include/asm/u-boot-x86.h | 3 +++
> arch/x86/lib/fsp/fsp_car.S | 26 +++++---------------------
> arch/x86/lib/fsp/fsp_common.c | 8 ++++++++
> common/board_f.c | 3 +++
> 5 files changed, 24 insertions(+), 22 deletions(-)
Applied to u-boot-x86, thanks!
More information about the U-Boot
mailing list