summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorBin Meng <bmeng.cn@gmail.com>2015-06-07 11:33:14 +0800
committerSimon Glass <sjg@chromium.org>2015-07-14 18:03:15 -0600
commitaefaff8ed83472da5ba96e179231eee665e2d843 (patch)
tree8830f24841d9c3691e4be03dd8c400b6fc03c285 /drivers
parent002610f620553bec06e5724052fc5cc5f34eb1e8 (diff)
downloadu-boot-imx-aefaff8ed83472da5ba96e179231eee665e2d843.zip
u-boot-imx-aefaff8ed83472da5ba96e179231eee665e2d843.tar.gz
u-boot-imx-aefaff8ed83472da5ba96e179231eee665e2d843.tar.bz2
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>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions