This commit introduces a new configuration option X86_RUN_64BIT_NO_SPL
to allow building U-Boot as a 64-bit binary without using the SPL
(Secondary Program Loader). The motivation is to simplify the boot
process for certain x86-based platforms that do not require SPL, such as
those booting directly from a 64-bit coreboot firmware.

This update revises the `X86_RUN_64BIT` configuration to more accurately
describe its role as "32-bit SPL followed by 64-bit U-Boot." It
clarifies the sequence of operations during the boot process, where the
system transitions from a 32-bit SPL (Secondary Program Loader) to the
main 64-bit U-Boot.

Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Create a sysinfo driver to avoid needing a custom checkboard()
function. With this the following information is printed when booting
from coreboot under QEMU:

   Model: Standard PC (i440FX + PIIX, 1996)
   Manufacturer: QEMU
   Prior-stage version: 4.21-885-g2a87ef1eca56
   Prior-stage date: 11/11/2023

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

This is very annoying as it is quite slow on many machines. Also, U-Boot
has an existing 'preboot' mechanism to enable this feature if desired.

Drop this code so that it is possible to choose whether to init USB or
not.

Use the existing USE_PREBOOT mechanism instead.

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

Use VENDOR_COREBOOT instead of TARGET_COREBOOT so we can have multiple
coreboot boards, sharing options. Only SYS_CONFIG_NAME needs to be
defined TARGET_COREBOOT.

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

Coreboot runs in 32-bit mode and cannot run a 64-bit U-Boot. To get around
this we can build a combined image with 32-bit SPL and 64-bit U-Boot. Add
a build rule and binman definition for this.

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

On x86 platforms the timer is reset to 0 when the SoC is reset. Having
this as the timer base is useful since it provides an indication of how
long it takes before U-Boot is running.

When U-Boot sets the timer base to something else, time is lost and we
no-longer have an accurate account of the time since reset. This
particularly affects bootstage.

Change the default to not read the timer base, leaving it at 0. Add an
option for when U-Boot is the secondary bootloader.

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

Currently building U-Boot as the coreboot payload requires user
to change the build configuration for a specific board during
menuconfig process. This uses the board's native device tree
to configure the hardware. For example, the device tree provides
PCI address range for the PCI host controller and U-Boot will
re-program all PCI devices' BAR to be within this range. In order
to make sure we don't mess up the hardware, we should guarantee
the range matches what coreboot programs the chipset.

But we really should make the coreboot payload support easier.
Just like EFI payload, we can create a generic coreboot payload
for all x86 boards as well. The payload is configured to include
as many generic drivers as possible. All stuff that touches low
level initialization are not allowed as such is the coreboot's
responsibility. Platform specific drivers (like gpio, spi, etc)
are not included.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

This adds the scsi command to coreboot and qemu, to be in consistent
with other x86 targets.

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

And use 'imply' liberally.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

At present we support multiple environment drivers but there is not way to
select between them at run time. Also settings related to the position and
size of the environment area are global (i.e. apply to all locations).

Until these limitations are removed we cannot really support more than one
environment location. Adjust the location to be a choice so that only one
can be selected. By default the environment is 'nowhere', meaning that the
environment exists only in memory and cannot be saved.

Also expand the help for the 'nowhere' option and move it to the top since
it is the default.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Move all of the imply logic to default X if Y so it works again]
Signed-off-by: Tom Rini <trini@konsulko.com>