Sughosh Ganu <sughosh.ganu@linaro.org> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
All of the current definitions of arch_lmb_reserve() are doing the
same thing -- reserve the region of memory occupied by U-Boot,
starting from the current stack address to the ram_top. Introduce a
function lmb_reserve_uboot_region() which does this, and do away with
the arch_lmb_reserve() function.
Instead of using the current value of stack pointer for starting the
reserved region, have a fixed value, considering the stack size config
value.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
Provide a function to locate this information, rather than doing it
automatically on startup, to save space in global_data.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should have a single place where we write the default value to the
creator revision field. If we ever will have any table created by another
tool, we can overwrite the value afterwards.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
On qemu-x86_64_defconfig the following was observed:
=> efidebug tables
00000000000f0074 eb9d2d31-2d88-11d3-9a16-0090273fc14d SMBIOS table
The SMBIOS configuration table does not point to a paragraph-aligned
(16 byte aligned) address. The reason is that in write_tables() rom_addr is
not aligned and copied to gd->arch.smbios_start.
The Simple Firmware Interface requires that the SFI table is paragraph-
aligned but our code does not guarantee this.
As all tables written in write_tables() must be paragraph-aligned, we
should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().
Add paragraph-alignment in write_tables().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
It also updates fastboot to do a similar thing.
Allow these functions to be compiled in when CONFIG_BOOTM is enabled,
even if CONFIG_CMD_BOOTM is not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
Simon Glass <sjg@chromium.org> says:
This series refactors the zboot code to allow it to be used with
CONFIG_COMMAND disabled.
A new zboot_run() function is used to boot a zimage.
Now that we have a function to start the process of booting a zimage,
use it in zboot_run() to avoid duplicated logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move zboot_start() and zboot_info() in with the other logic functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The term 'start' is used withint bootm and zboot to indicate the first
phase of booting an image.
Since zboot_start() does the whole boot, rename it to zboot_run() to
align with bootm_run() etc.
Fix a log message while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The only difference between the command and the underlying logic is the
setting of envrionment variables. Move this out of the command
processing since it needs to be done in any case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most of the functionality of zboot is contained in the logic which
handles a zimage. Create a separate Kconfig for the logic so that it can
(later) be used without the command itself being enabled.
Enable ZBOOT by default on x86, with the command depending on that. The
existing 'imply' can therefore be removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Much of the code in zimage.c deals with the zboot command. Move it into
a sepatate zboot.c file within the cmd/ directory. This will eventually
allow use of the zimage logic without the command being enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
In preparation for splitting the zboot-command code into a separate
file, move the definitions into the header file.
While we are here, mention when load_address and base_ptr are set up
and explain bzimage_addr better. Make cmdline const since it cannot be
changed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The fields Creator ID and Creator Revision contain information about the
tool that created an ACPI table. This may be the ASL compiler for some
tables but it is not for others. Naming these fields aslc_id and
aslc_revision is misleading.
It is usual to see diverse values of Creator ID. On a laptop I saw these:
'AMD ', 'INTL, 'MSFT', 'PTEC'. Obviously not all relate to the Intel
ASL compiler.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
QEMU provides SMBIOS tables with detailed information. We should not try to
replicate them in U-Boot.
If we want to inform about U-Boot, we can add a Firmware Inventory
Information (type 45) table in future.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fields X_FIRMWAE_CTRL and X_DSDT must be 64bit wide. Convert pointers to
to uintptr_t to fill these.
If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If
field X_DSDT is filled, field DSDT must be ignored. We should not fill
unused fields.
See the field definitions in chapter "5.2.9 Fixed ACPI Description Table
(FADT)" of the ACPI Specification 6.5.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sandbox uses an API to map between addresses and pointers. This allows
it to have (emulated) memory at zero and avoid arch-specific addressing
details. It also allows memory-mapped peripherals to work.
As an example, on many machines sandbox maps address 100 to pointer
value 10000000.
However this is not correct for ACPI, if sandbox starts another program
(e.g EFI app) and passes it the tables. That app has no knowledge of
sandbox's address mapping. So to make this work we want to store
10000000 as the value in the table.
Add two new 'nomap' functions which clearly make this exeption to how
sandbox works.
This should allow EFI apps to access ACPI tables with sandbox, e.g. for
testing purposes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The updated bloblist structure stores the alignment as a power-of-two
value in its structures. Adjust the API to use this, to avoid needing to
calling ilog2().
Update the bloblist alignment from 16 bytes to 8 bytes.
Drop a stale comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Co-developed-by: Raymond Mao <raymond.mao@linaro.org>
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Adjust boot_os_fn to use struct bootm_info instead of the separate
argc, argv and image parameters. Update the handlers accordingly. Few
of the functions make use of the arguments, so this improves code size
slightly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Make a note of where coreboot installed the SMBIOS tables so that we can
pass this on to EFI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Remember where these end up so that we can pass this information on to
the EFI layer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When turning off CAR, set the flag to make sure that nothing tries to use
driver model in SPL before jumping to U-Bot proper, since its tables are
in CAR.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The current condition does not handle the samus_tpl case where it sets
up the RAM in SPL but needs to commit the MTRRs in U-Boot proper.
Add another case to handle this and update the comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Make this depend on whether the address matches the offset, rather than
a particular board build. For samus_tpl we don't need to copy, for
example.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Convert this to use events instead of calling a function directly in the
init sequence.
Rename it to arch_fsp_init_f() to distinguish it from the one that happens
after relocation.
For FSPv2 nothing needs to be done here, so drop the empty function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Very few of the existing event-spy records use the arguments they are
passed. Update them to use a simple spy instead, to simplify the code.
Where an adaptor function is currently used, remove it where possible.
Signed-off-by: Simon Glass <sjg@chromium.org>
board_get_usable_ram_top() returns a physical address that is stored in
gd->ram_top. The return type of the function should be phys_addr_t like the
current type of gd->ram_top.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Provide an option to dump this information if available.
Move the funciion prototype to the common x86 header. Allow the command
line to be left out since 'bootflow info' show this itself and it is
not in the correct place in memory until the kernel is actually booted.
Fix a badly aligned heading while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is only used in one file and the value is the same for both boards
which define it. Use the fixed value of 32KB and drop the CFG. This will
allow removal of the config.h files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is copying beyond the end of the destination buffer. Correct the code
by using the size of the vesa_mode_info struct. We don't need to copy the
rest of the bytes in the buffer.
This long-standing bug prevents virtio bootdevs working correctly on
qemu-x86 at present.
Fixes: 0ca2426bea ("x86: Add support for running option ROMs natively")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> # qemu-x86_64
Call the hardware-init function from QEMU from SPL. This allows the
video BIOS to operate correctly.
Create an x86-wide qemu.h header to avoid having to #ifdef the header
in spl.c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> # qemu-x86_64
Now all linker symbols are declared as type char[]. Though we can
reference the address via both the array name 'var' and its address
'&var'. It's better to unify them to avoid confusing developers.
This patch converts all '&var' linker symbol refrences to the most
commonly used format 'var'.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Show the number of records in the table and the total table size in
bytes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
