This commit updates the RAM region filtering logic in
board_get_usable_ram_top() to skip any memory regions whose start address
is above 4GB. Previously, only the end address was capped at 4GB, but
regions entirely above this threshold were still considered.

Typically, the following memory map entries would cause
board_get_usable_ram_top() to return 0x100000000, which is incorrect.

    start=00000000, end=00001000, type=16
    start=00001000, end=000a0000, type=1
    start=000a0000, end=000f6000, type=2
    start=000f6000, end=000f7000, type=16
    start=000f7000, end=00100000, type=2
    start=00100000, end=6f170000, type=1
    start=6f170000, end=70000000, type=16
    start=70000000, end=80800000, type=2
    start=e0000000, end=f8000000, type=2
    start=fa000000, end=fc000000, type=2
    start=fc800000, end=fc880000, type=2
    start=fd800000, end=fe800000, type=2
    start=feb00000, end=feb80000, type=2
    start=fec00000, end=fed00000, type=2
    start=fed20000, end=fed80000, type=2
    start=feda1000, end=feda2000, type=2
    start=fedc0000, end=fede0000, type=2
    start=100000000, end=102400000, type=2
    start=102400000, end=47f800000, type=1
    start=4000000000, end=4020000000, type=2

By adding a check to continue the loop if the region's start address
exceeds 0xffffffffULL, the function now properly ignores regions that are
not usable in 32-bit address space.

Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>

As both CONFIG_X86_RUN_64BIT and X86_RUN_64BIT_NO_SPL cases run U-Boot
in 64-bit mode with the CPU fully initialized already.

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

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>

Most of the copies of the print_cpuinfo() call the default method.
Remove all of those in order to have only the default one when
no `cpu` command is compiled.

This also helps avoiding compiler warning, e.g.:

  arch/x86/cpu/tangier/tangier.c:23:5: warning: no previous prototype for ‘print_cpuinfo’ [-Wmissing-prototypes]

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Receiving timestamps from coreboot was unceremoniously dropped some time
ago. Add it back.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 8ad01ce36f7 ("x86: Remove x86 specific GD flags as they are...")

Rather than using a special variable, get the timestamp info from the
coreboot sysinfo struct. Return a proper error as well.

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

While a few SoCs have a unique print_cpuinfo function, a number of them
just use default_print_cpuinfo. Make default_print_cpuinfo have a weak
alias to provie print_cpuinfo.

Signed-off-by: Tom Rini <trini@konsulko.com>

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

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

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>