| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Make use the existing GDT which now includes entries for 64-bit code.
Leave the interrupt descriptors alone. They can be tidied up once U-Boot
starts up.
With this, kvm mode works with QEMU.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/31
|
|
This is required as part of the procedure. The existing code works
because it changes the GDT at the same time, but this makes kvm
unhappy.
Update the algorithm to disable and then re-enable paging.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use a symbol to select the size of the GDT, rather than hard-coding a
value. This matches how it is done in start64
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This makes use of a 'bool' type, so include the required header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This functions normally and has done for a while, so drop this scary
message.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
x86_cpu_init_f() is called by arch_cpu_init() a few lines below this
code. Drop the duplicate call.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use some named flags when setting up the cache, so it is easier to see
what is going on.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present it is not possible to execution 64-bit code without
installing an entire new Global Descriptor Table. This is inconvenient
since kvm does not seem to like switching into long mode with a new
table.
It isn't actually necessary, since we can just extend the existing
table. Add some new entries to this effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
U-Boot clears the display when it starts up, so there is no need to ask
the VESA driver to do this. Fix this and add a comment explaining the
flags.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This option is not actually defined in Kconfig anymore. Use a normal
debug print instead, which has a similar effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add categories for i8259 and bios files, so that log statements have the
right category.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is not needed in SPL, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
BSS is placed in DRAM which is actually available early with QEMU. But
it is cleared by the init sequence, so values stored there are lost.
Move the system-type flag into a function, instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Sam Edwards <cfsworks@gmail.com> says:
This is v2 of my "misc. fixes" series, sent to prepare the codebase for more
direct LLVM support in the near future. This series contains several fixes that
I found in the process of preparing that support and which address issues
independent of any future feature or enhancement. I am sending these now, both
so that their inclusion is not delayed by discussion on my upcoming series and
to make the latter more manageable.
Link: https://lore.kernel.org/r/20250315221813.1265193-1-CFSworks@gmail.com
|
|
When a section is not flagged with SHF_ALLOC, LLD's --gc-sections
algorithm fails to visit the sections that it references. As a result of
this, LLD was dropping the call64.o(.data) section, which is itself only
referenced by .text_call64.
This appears to be a bug in LLD, but the .section directive for
.text_call64 should really have the correct flags either way.
Add `"ax"` to mark the section as ALLOC ("supposed to be loaded") and
CODE ("supposed to be executed").
Fixes: 7dc82591d68e2a ("x86: Move call64 into its own section")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
|
|
extlinux / PXE"
Simon Glass <sjg@chromium.org> says:
This series includes some patches related to allowing read_all() to be
used with the extlinux / PXE bootmeths.
These patches were split out from the stb4 series, since it will need to
have additional patches for LWIP, to avoid breaking PXE booting when
LWIP is used.
Link: https://lore.kernel.org/r/20250306002533.2380866-1-sjg@chromium.org
|
