u-boot.git/arch/x86/cpu, branch master

global: Correct duplicate U_BOOT_DRIVER entry names

2026-04-07T17:32:56+00:00

The U_BOOT_DRIVER macro creates a list of drivers used at link time, and
all entries here must be unique. This in turn means that all entries in
the code should also be unique in order to not lead to build failures
later with unexpected build combinations. Typically, the problem we have
here is when a driver is obviously based on another driver and didn't
update this particular field and so while the name field reflects
something unique the linker entry itself is not. In a few places this
provides a more suitable string name as well, however.

Reviewed-by: Marek Vasut 
Reviewed-by: Svyatoslav Ryhel  # Tegra
Reviewed-by: Peter Robinson 
Reviewed-by: Heiko Schocher 
Reviewed-by: Simon Glass 
Signed-off-by: Tom Rini

Merge tag 'v2026.04-rc3' into next

2026-02-23T19:45:55+00:00

Prepare v2026.04-rc3

treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage

2026-02-17T19:50:22+00:00

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard  #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal  #TI boards
Acked-by: Yao Zi  #TH1520
Signed-off-by: Peng Fan

x86/coreboot: Exclude memory regions starting above 4GB

2026-02-16T18:00:42+00:00

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

x86: cpu: Fix crash on FTRACE enabled builds

2026-02-03T18:51:43+00:00

When compiled with FTRACE=1 U-boot will crash as %rdi is clobbered
in board_init_f_alloc_reserve() and board_init_f_init_reserve() will
memset the .text segment instead of the global_data struct.

According to the System V AMD64 ABI %rdi is not preserved and the
existing code only worked as board_init_f_alloc_reserve() was small
enough to not use %rdi.

Fix that by always passing the correct argument to
board_init_f_init_reserve().

TEST=Can boot on qemu-q35 with FTRACE=1 enabled during build.

Signed-off-by: Patrick Rudolph

x86: Update linker scripts to ensure appended device tree is aligned

2026-01-20T18:07:24+00:00

With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Rewrite the '.rel.dyn' (u-boot.lds) to follow modern practices, and
  include the 8-byte alignment at the end of the section.
- Expands the '.dynamic' section (u-boot-64.lds) to be more readable
  when adding a second statement to the section.
- Aligns the final section before _end (for U-Boot) or _image_binary_end
  or __bss_end (for xPL phases) by 8-bytes by adding '. = ALIGN(8);' to
  the final section before the symbol or changing an existing ALIGN(4)
  statement.
- Ensure that we do have alignment by adding an ASSERT so that when not
  aligned we fail to link (and explain why).

Signed-off-by: Tom Rini

efi: Rename CONFIG_EFI to CONFIG_EFI_CLIENT

2025-07-26T05:34:28+00:00

The generic name 'EFI' would be more useful for common EFI features. At
present it just refers to the EFI app and stub, which is confusing.

Rename it to EFI_CLIENT

Signed-off-by: Simon Glass

x86: Move Intel GNVS file into the common include directory

2025-06-13T19:10:33+00:00

Move this so we can include it from sandbox, needed since it is in a
bloblist and must have a check.

Signed-off-by: Simon Glass

binman: x86: Write skip-at-start when end-at-4gb is used

2025-05-27T09:07:39+00:00

The end-at-4gb property implies a value for skip-at-start so add it into
the output FDT so that U-Boot can read it.

Now that skip-at-start is implemented, we can drop the workarounds used
in the x86 code to obtain the correct image-pos value.

Signed-off-by: Simon Glass

x86: Correct usage of FSP_VERSION2

2025-05-09T18:57:32+00:00

As the code is today, we get a warning about "select" statements on
"choice" options not doing anything. In this case, we move to having a
"default FSP_VERSION2 if INTEL_APOLLOLAKE" in order to get the desired
outcome.

Signed-off-by: Tom Rini