Merge git://git.denx.de/u-boot-x86

x86: fsp: Configure SPI opcode registers before SPI is locked down

Some Intel FSP (like Braswell) does SPI lock-down during the call
to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done,

x86: fsp: Configure SPI opcode registers before SPI is locked down

Some Intel FSP (like Braswell) does SPI lock-down during the call
to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done,
it's bootloader's responsibility to configure the SPI controller's
opcode registers properly otherwise SPI controller driver doesn't
know how to communicate with the SPI flash device.

This introduces a Kconfig option CONFIG_FSP_LOCKDOWN_SPI for such
FSPs. When it is on, U-Boot will configure the SPI opcode registers
before the lock-down.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: fsp: Save stack address to CMOS for next S3 boot

At the end of pre-relocation phase, save the new stack address
to CMOS and use it as the stack on next S3 boot for fsp_init()
continuation funct

x86: fsp: Save stack address to CMOS for next S3 boot

At the end of pre-relocation phase, save the new stack address
to CMOS and use it as the stack on next S3 boot for fsp_init()
continuation function.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

show more ...

x86: Store and display previous sleep state

Add one member in the global data to store previous sleep state,
and display the state during boot in print_cpuinfo().

Signed-off-by: Bin Meng <bmeng.cn@

x86: Store and display previous sleep state

Add one member in the global data to store previous sleep state,
and display the state during boot in print_cpuinfo().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

show more ...

x86: fsp: acpi: Pass different boot mode to FSP init

When ACPI S3 resume is turned on, we should pass different boot mode
to FSP init instead of default BOOT_FULL_CONFIG.

Signed-off-by: Bin Meng <b

x86: fsp: acpi: Pass different boot mode to FSP init

When ACPI S3 resume is turned on, we should pass different boot mode
to FSP init instead of default BOOT_FULL_CONFIG.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

show more ...

board_f: x86: Use checkcpu() for CPU init

At present we misuse print_cpuinfo() do so CPU init on x86. This is done
because it is the next available call after the console is enabled. But
several arc

board_f: x86: Use checkcpu() for CPU init

At present we misuse print_cpuinfo() do so CPU init on x86. This is done
because it is the next available call after the console is enabled. But
several arches use checkcpu() instead. Despite the horrible name (which
we can fix), it seems a better choice.

Adjust the various x86 CPU implementations to move their init code into
checkcpu() and use print_cpuinfo() only for printing CPU info.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: x86: Rename x86_fsp_init() to arch_fsp_init()

While x86 is the only user and this could in principle be moved to
arch_cpu_init() there is some justification for this being a separate
call.

board_f: x86: Rename x86_fsp_init() to arch_fsp_init()

While x86 is the only user and this could in principle be moved to
arch_cpu_init() there is some justification for this being a separate
call. It provides a way to handle init which is not CPU-specific, but
must happen before the CPU can be set up.

Rename the function to be more generic.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

Fix board init code to respect the C runtime environment

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime en

Fix board init code to respect the C runtime environment

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.

Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.

Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Thomas Chou <thomas@wytron.com.tw>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-x86

x86: Remove legacy pci codes

Now that we have converted all x86 boards to use driver model pci,
remove these legacy pci codes.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sj

x86: Remove legacy pci codes

Now that we have converted all x86 boards to use driver model pci,
remove these legacy pci codes.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge git://git.denx.de/u-boot-x86

x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init()

fsp_init() call has a parameter nvs_buf which is used by FSP as the
MRC cache but currently is blindly set to NULL. Retreive

x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init()

fsp_init() call has a parameter nvs_buf which is used by FSP as the
MRC cache but currently is blindly set to NULL. Retreive the MRC
cache from SPI flash and pass it to fsp_init() call. After the call,
save FSP produced MRC cache to SPI flash too.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: fsp: Enlarge the size of malloc() pool before relocation

After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
En

x86: fsp: Enlarge the size of malloc() pool before relocation

After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
Enlarge the size of malloc() pool before relocation since we have
plenty of memory now.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: Drop FSP error defines and use EFI instead

Now that we have an efi.h header we can use that for FSP error defines.
Drop the FSP ones.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by:

x86: Drop FSP error defines and use EFI instead

Now that we have an efi.h header we can use that for FSP error defines.
Drop the FSP ones.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: Split out fsp_init_phase_pci() code into a new function

This code may be useful for boards that use driver model for PCI.

Note: It would be better to have driver model automatically call this

x86: Split out fsp_init_phase_pci() code into a new function

This code may be useful for boards that use driver model for PCI.

Note: It would be better to have driver model automatically call this
function somehow. However for now it is probably safer to have it under
board control.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

Merge git://git.denx.de/u-boot-x86

x86: Add some missing global_data declarations in files that use gd

Some files use global_data but don't declare it. Fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <b

x86: Add some missing global_data declarations in files that use gd

Some files use global_data but don't declare it. Fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge git://git.denx.de/u-boot-x86

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 wor

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>

show more ...

x86: fsp: Use reset_cpu()

Now that reset_cpu() functions correctly, use it instead of directly
accessing the port on boards that use a Firmware Support Package (FSP).

Signed-off-by: Simon Glass <sj

x86: fsp: Use reset_cpu()

Now that reset_cpu() functions correctly, use it instead of directly
accessing the port on boards that use a Firmware Support Package (FSP).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...