]> git.kernelconcepts.de Git - karo-tx-uboot.git/commit
x86: fsp: Move FspInitEntry call to board_init_f()
authorBin Meng <bmeng.cn@gmail.com>
Sun, 7 Jun 2015 03:33:14 +0000 (11:33 +0800)
committerLothar Waßmann <LW@KARO-electronics.de>
Wed, 9 Sep 2015 11:29:21 +0000 (13:29 +0200)
commit13095552018b8a6d926ea922b51dc0114921f5e2
tree3fc5d59e9be1de358fc94bb4fe5a43065b1de4e4
parentd4cc812b34c8c05abc51431f6432810998e34ae9
x86: fsp: Move FspInitEntry call to board_init_f()

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@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Tested-by: Simon Glass <sjg@chromium.org>
arch/x86/cpu/start.S
arch/x86/include/asm/u-boot-x86.h
arch/x86/lib/fsp/fsp_car.S
arch/x86/lib/fsp/fsp_common.c
common/board_f.c