| Age | Commit message (Collapse) | Author |
|---|
|
Remove the reference to the non-existent symbol. As ROMs typically
come as powers of two there seems no need for this value.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: 64542f4616c4 ("x86: Make ROM_SIZE configurable in Kconfig")
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Symbol CONFIG_INTEL_PMC does not exist.
Don't select it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: 1fc541931461 ("x86: apl: Add Kconfig and Makefile")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
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 <marek.vasut+usb@mailbox.org>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # Tegra
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Today we typically enable CMD_SATA in order to have the SATA
functionality itself enabled, despite there being a clean split between
the two symbols. This in turn leads to potential configuration problems.
Split things so that SATA continues to be separate and not CMD_SATA
instead depends, functionally, on AHCI being enabled.
To do all of this:
- Have X86 select AHCI directly rather than "default y" it later.
- Make CMD_SATA be a default y option, given the split of platforms that
enabled SATA and did, or did not, enable CMD_SATA.
- Change "imply CMD_SATA" to "imply SATA"
- Correct TARGET_VEXPRESS64_JUNO because you cannot select SATA_SIL
without PCI (and in turn, SATA is needed for SATA_SIL).
- Update a number of defconfigs to have no functional change.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The x86 code in bootm_announce_and_cleanup() is very similar to the new
bootm_final() function, so just use the latter.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
|
|
Prepare v2026.04-rc3
|
|
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 <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
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>
|
|
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 <patrick.rudolph@9elements.com>
|
|
The else if branch uses the is_zimage boolean which is initialized to 0
and never set before being tested here.
remove the test on is_zimage to make this code reachable.
Signed-off-by: Guillaume Ranquet <ranquet.guillaume@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Excessive default value causes crash on hardware: x86 baytrail E3845
It is unclear where the data is being populated being 'BLOBLISTT_TCPA_LOG'
is not found elsewhere in the u-boot tree. This leads to confusion about
how much space for TPM log is actually needed.
This was tested on hardware using TPMv1.
Signed-off-by: Eric Schikschneit <eric.schikschneit@novatechautomation.com>
|
|
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 <trini@konsulko.com>
|
|
A few x86 platforms use a SYS_MALLOC_F_LEN value of 0x1000 or higher.
With the impending move to having DEVRES enabled by default, we will
need a little more room here. Raise the default value.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The objcopy man-page teaches:
--target=bfdname
Use bfdname as the object format for
both the input and the output file
This implies for --target=efi-app-x86_64 that the input file would have
to be an EFI app.
Objcopy in binutils 2.45 checks this more strictly than previous versions
and refuses to accept an ELF file as input with --target=efi-app-x86_64.
Replace --target by --output-target for building sandbox and x86 EFI
binaries.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
The U-Boot project has been assigned the vendor ID 'UBOO' [1]. Use this
vendor ID and our release version in the ACPI table headers.
[1] ACPI ID Registry
https://uefi.org/ACPI_ID_List
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
There is nothing x86-centric in this include file, and moving it will
allow for some drivers to be compile-tested on sandbox.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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 <sjg@chromium.org>
|
|
This will allow arch(s) that use device tree blobs to pad the end of the
device tree so they can be modified by board files at run time. This will
help prevent errors such as FDT_ERR_NOSPACE from occurring.
Signed-off-by: Eric Schikschneit <eric.schikschneit@novatechautomation.com>
[trini: Change default order so that X86 && EFI_APP works correctly]
|
|
This function is currently a misnomer at times as we have cases where it
passes arguments to the image. In preparation for making that be a more
common case rename this function to jump_to_image(...). In order to do
this, rename jump_to_image in board_init_r(...) to jumper so that we do
not have a conflict.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Reword the commit message, adding missing cases of
jump_to_image_no_args()]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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 <sjg@chromium.org>
|
|
Tom Rini <trini@konsulko.com> says:
Hey all,
Related to my other series I've posted recently on cleaning up some
headers, this series here is the result of at least lightly auditing the
#includes used in include/[a-m]*.h. This ignores subdirectories, as at
least in part I think the top-level includes we've constructed are the
most likely places to have some extra transitive include paths. I'm sure
there's exceptions and I'll likely audit deeper once this first pass is
done. This only gets as far as "include/m*.h" because I didn't want this
to get too big. This also sets aside <miiphy.h> and <phy.h>. While
miiphy.h does not directly need <phy.h> there are *so* many users and I
think I had half of the tree just about not building when I first tried.
It might be worth further investigation, but it might just be OK as-is.
Link: https://lore.kernel.org/r/20250521230119.2084088-1-trini@konsulko.com
|
|
This file does not need <pc.h> but does directly need
<linux/types.h>. Furthermore, arch/x86/lib/bios.c was getting <pci.h>
via <bios_emul.h> so add it there.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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 <sjg@chromium.org>
|
|
The EFI-loader code has not been fully converted to use bloblist, so
relies on the SMBIOS-table address being set in global_data.
Set this up in write_tables() so that the SMBIOS tables are actually
available.
Enable the command for x86 QEMU so that the SMBIOS tests actually run.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 83ce35d6ebb ("emulation: Use bloblist to hold tables")
Reported-by: Niklas Sombert <niklas.sombert@uni-duesseldorf.de>
Tested-by: Niklas Sombert <niklas.sombert@uni-duesseldorf.de>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
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 <trini@konsulko.com>
|
|
This change adds `BOOT_DEVICE_NVME` to the `enum` list in
`arch/x86/include/asm/spl.h`,
enabling NVMe as a recognized boot device for SPL (Secondary Program
Loader).
Tested x86 hardware with coreboot + U-Boot payload.
Verified successful boot to NVMe drive.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This file was using IS_ENABLED() to test for CONFIG flags but omitted
the CONFIG_ prefix and so did not work as expected.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This file was using IS_ENABLED() to test for CONFIG flags but omitted
the CONFIG_ prefix and so did not work as expected.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The new two declarations board_final_init() and board_final_cleanup()
need a description. Add it here.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
|
|
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
Introduce a new function to update ACPI table headers.
This allows to simplify the existing code.
Link: https://lore.kernel.org/r/20250321232121.251800-1-heinrich.schuchardt@canonical.com
|
|
Use acpi_update_checksum() for updating ACPI table header checksum.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
|
|
in extlinux / PXE""
This reverts commit 8bc3542384e3a1219e5ffb62b79d16dddc1b1fb9, reversing
changes made to 698edd63eca090a2e299cd3facf90a0b97bed677.
There are still problems with this series to work out.
Link: https://lore.kernel.org/u-boot/CAFLszTjw_MJbK9tpzVYi3XKGazcv55auBAdgVzcAVUta7dRqcg@mail.gmail.com/
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Correct the preprocessor directive used to check for 64-bit kernel
support in the `zboot_go` function. The code previously checked for
`CONFIG_X86_RUN_64BIT`, which is not the correct configuration option
for determining if the kernel should run in 64-bit mode. The correct
option is `CONFIG_X86_64`.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
Add some missing pieces to bootparams so that a 64-bit ramdisk address
can be used. Tidy up the logging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The existing QEMU implementation mostly ignored BLOBLIST_TABLES and
allocates the bulk of the tables with malloc(). Update it to place all
tables in the bloblist. Since QEMU declares a size of 128KB regardless
of the size of its tables, this requires a larger bloblist.
Fix up the e820 table to handle this, keeping the old code as an option
for now, to assist with any future bug-fixing.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move over to use this API before making the code even more complicated.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The existing mechanism is pretty painful as it requires manual
calculations for anything but a trivial setup.
Add a new API for adding e820 entries.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
There is already code for this in zimage. Move it to the e820 file so
it can be used elsewhere.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
QEMU likes to have an MTRR set up, just like real machines. Add an MTRR
which covers the total RAM size.
This does nothing on machines without MTRRs.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present mtrr_add_request() requires that the size is a power of two.
This is too limiting for machines with 4GB (or more) of RAM, since they
often must take account of a memory hole at 3GB.
Update the function to automatically deal with an unaligned size, using
more MTRRs as required.
The algorithm is taken from coreboot commit 60bce10750
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The CONFIG option is no-longer correct since we can have SPL and PPL
with different bitness.
Fix this and sync up with Linux 6.13 in this area, since this is where
the code came from many years ago.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The existing functions work but the register clobbers are wrong, so
strange bugs results.
The original functions were taken from a very old version of Linux.
Update them from Linux 6.13
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than repeating the same code in several places, add some
functions which can do the conversion.
Use the cpu_phys_address_size() function to obtain the physical-address
size, since it is more reliable with kvm, where the host CPU may have a
different value from the emulation CPU.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present it is not possible to find out the physical-address size in
long mode, so a predefined value is used.
Update the macros to support this properly, since it is important when
programming MTRRs.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This value happens to be used by ctype.h so chose a different name.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With the 64-bit descriptor we can use a jump instruction, rather than
pushing things on the stack.
Since the processor is in 64-bit mode by this point, pop a 64-bit value
from the stack, containing the target address.
This simplifies the code slightly, in particular its use of the stack.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
