Now that bootm_final() does most of what we want, drop this separate
function.
Series-to: concept
Cover-letter:
bootm: Clean up arch-specific, pre-OS clean-up
Each arch does something slightly different before booting the OS. Some
archs even do different things depending on the CPU type.
EFT_LOADER has its own special code, regardless of which arch is being
booted.
It is quite hard to know what actually happens in the final milliseconds
before the OS boot.
This series attempts to clean up U-Boot in this area.
The basic approach is to create a new bootm_final() function which is
called by all archs. It provides some flags for a couple of necessary
variations but otherwise it is generic.
RISC-V, x86 and ARM are converted over to use this new function. For
consistency, EFI loader is converted as well.
A noteable change is that EFI_LOADER now does bootstage processing
before boot, if enabled, thus producing a report.
Future work could take this a little further:
- Drop board_quiesce_devices() and rely on driver model for that
- Similarly with udc_disconnect()
- cleanup_before_linux() could use more details as to what it is
supposed to do, to reduce the number of arch-specific variations
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the declaration of this function to a common header. Make sure it
is included by files which define it.
Fix up a few whitespace problems while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is not present on x86, but there is an x86-specific
version which is never called. Add the former, making it call the
latter.
Signed-off-by: Simon Glass <sjg@chromium.org>
The x86 code in bootm_announce_and_cleanup() is very similar to the new
bootm_final() function, so just use the latter. Move over a useful
comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than searching for this table, use the existing search function.
Update that to check the header and checksums.
This allows the code to work correctly with boards that have the tables
in a bloblist, such as QEMU.
Signed-off-by: Simon Glass <sjg@chromium.org>
The bdinfo command makes use of quite a few functions which show a label
followed by a value, on a single line.
This sort of thing is generally useful outside of bdinfo, so move it to
a generic place. Use 'l' (for label) as the prefix.
The margin is still hard-coded to 12, which seems a reasonable limit for
a label.
Signed-off-by: Simon Glass <sjg@chromium.org>
Set up a single place in Kconfig where board/emulation/Kconfig is
included, removing the two sites in arch/arm and arch/x86
Move the ARM-specific Kconfig into this file.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name matches the ARM name and 'emulation' is not really a vendor.
Use ARCH_QEMU_X86 instead, moving that option from its existing location.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible to benchmark U-Boot using QEMU as described here:
https://github.com/stefano-garzarella/qemu-boot-time
On x86 devices, that script can read post codes from a perf trace. Add
a code which is emitted just before handing off to the Linux kernel.
Existing post codes can be used to determine when U-Boot starts.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present two separate SPL binaries are included in the ROM. This
affects QEMU which is quite tight with only a 2MB ROM. Adjust the
image description so that space is not wasted when microcode is not
needed.
Series-to: u-boot
Signed-off-by: Simon Glass <sjg@chromium.org>
Each arch has its own set of functions related to booting. Rather than
including them for each enabled command, have a single rule to include
them, using the new CONFIG_BOOT
Signed-off-by: Simon Glass <sjg@chromium.org>
Add --gc-sections to help reduce the size of the EFI app. Add a check
for undefined symbols too, since using these can hang or crash the app.
Signed-off-by: Simon Glass <sjg@chromium.org>
These two files are not used in the EFI app and it does not make sense
to compile them in. Omit relocate.c and physmem.c
Signed-off-by: Simon Glass <sjg@chromium.org>
Mark important sections with KEEP so that the linker will not remove
them when garbage-collection is (later) enabled.
Provide a _end symbol so that this can be accessed in setup_mon_len()
Signed-off-by: Simon Glass <sjg@chromium.org>
The 32- and 64-bit scripts are more different than they need to be.
Make some changes to both so that it is easier to see the necessary
differences.
For the 32-bit script this is mostly just whitespace. For the 64-bit
script the eh_frame section is discarded and the .data section is
reordered.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is about to become a misnomer since with standard passage we need to
pass arguments to U-Boot. Rename the function.
Also rename the local variable to 'jumper' to avoid a conflict.
Series-changes: 2
- Split the jump_to_image_no_args() change into its own patch
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: Ieb1fd7a5478ba1dfe3a58666ed586e83b0641590
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: 83ce35d6eb ("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>
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>
Separate setjmp.h into an architecture independent part and an architecture
specific part. This simplifies moving from using struct jmp_buf_data
directly to using type jmp_buf in our code which is the C compliant way.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.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>
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>
It isn't worth the hassle of omitting this field for the app, since code
is shared between the payload and the app. Adjust the condition to avoid
a build error in the 'efi' command with the app on 64-bit ARM.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present only x86 supports the EFI app and (apart from Qualcomm) the
payload. In preparation for supporting 64-bit ARM more generally, rename
the existing ARCH_EFI option to ARCH_EFI_X86, using that to define a
generic ARCH_EFI which will be enabled for all architectures.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'vendor' concept comes from arch/x86. Rather than letting this
spread around the tree, rename it to ARCH_EFI.
While EFI is not quite an architecture in the strict sense, it is
similar to sandbox in that it sits somewhat above the CPU architecture.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code is not actually x86-specific, so move it into the lib/efi dir
where other archs can use it.
Drop inclusion of the unnecessary x86-specific header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
So far only x86 supports the EFI app. ARM is going the same way, so
allow these options to be enabled for 64-bit ARM too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
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>
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>
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>
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>