On 6 June 2015 at 21:33, Bin Meng <bmeng...@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...@gmail.com> > Acked-by: Simon Glass <s...@chromium.org> > Tested-by: Andrew Bradford <andrew.bradf...@kodakalaris.com> > Tested-by: Simon Glass <s...@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! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
