The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.
Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.
Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.
Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
Commit 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.
So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rename these to VESA, itself an abbreviation, to avoid a conflict with
Verified Boot for Embedded.
Rename this to avoid referencing VBE.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to use VBE to mean Verfiied Boot for Embedded in U-Boot. Rename
the existing VBE (Vesa BIOS extensions) to allow this.
Verified Boot for Embedded is documented doc/develop/vbe.rst
Signed-off-by: Simon Glass <sjg@chromium.org>
With commit ce39ee28ec ("zynqmp: Do not place u-boot to reserved memory
location"), the function board_get_usable_ram_top() is allocating
MMU_SECTION_SIZE of about 2MB using lmb_alloc(). But we dont have this
much memory in case of mini U-Boot.
Keep these functions which use lmb under CONFIG_LMB so that they are
compiled and used only when LMB is enabled.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/75e52def75f573e554a6b177a78504c128cb0c4a.1657183534.git.michal.simek@amd.com
Rename the sections used to implement linker lists so they begin with
'__u_boot_list' rather than '.u_boot_list'. The double underscore at the
start is still distinct from the single underscore used by the symbol
names.
Having a '.' in the section names conflicts with clang's ASAN
instrumentation which tries to add redzones between the linker list
elements, causing expected accesses to fail. However, clang doesn't try
to add redzones to user sections, which are names with all alphanumeric
and underscore characters.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Instead of a special function, send an event after driver model is inited
and adjust the boards which use this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
MCFG tables are used on multiple arches. Move to common ACPI lib.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use sizeof(*mcfg) instead of sizeof(*header)
Signed-off-by: Simon Glass <sjg@chromium.org>
Commit d953137526 ("x86: Move SSDT table to a writer function")
introduced a bug where the actual MCFG entries are no longer generated.
Cc: Simon Glass <sjg@chromium.org>
Fixes: d953137526 ("x86: Move SSDT table to a writer function")
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Move this over to use a writer file, moving the code from the x86
implementation.
There is no need to store a separate variable since we can simply access
the ACPI context.
With this, the original monolithic x86 function for writing ACPI tables
is gone.
Note that QEMU has its own implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Each board has its own way of creating this table. Rather than calling the
acpi_create_fadt() function for each one from a common acpi_write_fadt()
function, just move the writer into the board-specific code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Move this table over to use a writer function, moving the code from the
x86 implementation.
Add a pointer to the DSDT in struct acpi_ctx so we can reference it later.
Disable this table for sandbox since we don't actually compile real ASL
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this table over to use a writer function, moving the code from the
x86 implementation.
Add a pointer to the DSDT in struct acpi_ctx so we can reference it later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new ACPI writer to write the base tables at the start of the area,
moving this code from the x86 implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new ACPI writer to write the ACPI tables. At present this is all
done in one monolithic function. Future work will split this out.
Unfortunately the QFW write_acpi_tables() function conflicts with the
'writer' version, so disable that for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present acpi_setup_base_tables() both sets up the ACPI context and
writes out the base tables.
We want to use an ACPI writer to write the base tables, so split this
function into two, with acpi_setup_ctx() doing the context set, and
acpi_setup_base_tables() just doing the base tables.
Disable the writer's write_acpi_tables() function for now, to avoid
build errors. It is enabled in a following patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than keying everything off ACPIGEN, use the main
GENERATE_ACPI_TABLE option to determine whether the core ACPI code
is included. Make sure these option are not enabled in SPL/TPL since we
never generate tables there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an empty CPU init function to avoid fiddling with low-level CPU
features in the app. Set up the C runtime correctly for 64-bit use
and avoid clearing BSS, since this is done by EFI when U-Boot is loaded.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the 'bootm' command is not enabled then this code is not available and
this causes a link error. Fix it.
Note that for the EFI app, there is no indication of missing code. It just
hangs!
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At present this is disabled, but it should work so long as the kernel does
not need EFI services. Enable it and add a note about remaining work.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to see some basic EFI info with the command as it forms part
of the information about a board.
Add a hook for this and show the table address as a start.
While here, fix an invalid cast in setup_efi_info(). Note that this
function is using a data structure defined by Linux so we cannot change
it. Also note that ulong is used since this is the standard in U-Boot
(>6k uses), despite there being quite a bit of the more verbose uintptr_t
(930 uses).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The setup routines are called from zimage but don't really belong in the
zimage header. Add a new EFI header to house these. Add comments so it is
clear what the functions do.
Note that these functions are x86-specific. The zimage business is not
used on other architectures.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Now that we have a 'positive' Kconfig option, use this instead of the
negative one, which is harder to understand.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
It is rather likely this architecture also needs to cover U-Boot with
LMB before booting Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
- Fixed broken ICH SPI driver in software sequencer mode
- Added "m25p,fast-read" to SPI flash node for x86 boards
- Drop ROM_NEEDS_BLOBS and BUILD_ROM for x86 ROM builds
- Define a default TSC timer frequency for all x86 boards
- x86 MTRR MSR programming codes bug fixes
- x86 "hob" command bug fixes
- Don't program MTRR for DRAM for FSP1
- Move INIT_PHASE_END_FIRMWARE to FSP2
- Use external graphics card by default on Intel Crown Bay
- tangier: Fix DMA controller IRQ polarity in CSRT
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.
Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
For FSP1, there is no such INIT_PHASE_END_FIRMWARE.
Move board_final_cleanup() to fsp2 directory.
Fixes: 7c73cea442 ("x86: Notify the FSP of the 'end firmware' event")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
There are several outstanding issues as to why this does not apply
to FSP1:
* For FSP1, the system memory and reserved memory used by FSP are
already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
same RES_MEM_RESERVED resource type. Its address is programmed
and reported by FSP to be near the top of 4 GiB space, which is
not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
to be exactly the power of 2. This causes reserved bits of the
IA32_MTRR_PHYSMASK register to be written which generates #GP.
For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
SMBIOS tables only support 32bit addresses. If we don't have memory here
handle the error gracefully:
* on x86_64 fail to start U-Boot
* during UEFI booting ignore the missing table
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is a revert of a recent logic change in setup_zimage(). We do
actually need to install this information always. Change it to install
from the Coreboot tables if available, else the normal source.
Fixes: e7bae8283f ("x86: Allow installing an e820 when booting from coreboot")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
A recent change to disable cache setup when booting from coreboot
assumed that this has been done by SPL. The result is that for the
coreboot board, the cache is disabled (in start.S) and never
re-enabled.
If the cache was turned off, as it is on boards without SPL, we should
turn it back on. Add this new condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With x86 we can execute an option ROM either natively or using the
x86 emulator (if enabled with CONFIG_BIOSEMU). Both of these share
the _X86EMU_env variable, with the native code using it to hold
register state during interrupt processing.
At present, in 32-bit U-Boot, the variable is declared twice, once
in common code and once in code only compiled with CONFIG_BIOSEMU.
With GCC 11 this causes a 'multiple definitions' error on boards
with CONFIG_BIOSEMU.
Drop the emulator definition when CONFIG_BIOSEMU is used.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
