This variable is already defined by the EFI code. Drop the duplicate
definition when building a 64-bit EFI app.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.
For now, avoid mentioning the documentation for the 64-bit app, since it
does not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Most EFI implementations use 64-bit but U-Boot only supports running as
a 32-bit app at present. While efi-x86_payload64 does boot from 64-bit
UEFI it immediately changes back to 32-bit before starting U-Boot.
In order to support a 64-bit U-Boot app, update the Kconfig to add an
option for 32/64 bit. Update the prompt for the existing option so it is
clear it relates to the stub. Move both up to just under the choice that
controls them, since this looks better and the menu.
Use CONFIG_EFI_APP in the Makefile instead of CONFIG_TARGET_EFI_APP,
since the latter is specific to a single target and we will have two.
Memory size is set to 32MB for now so that it can run on qemu without
increasing the default memory size. We may need to increase the default
later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Move error message to the caller of mrfld_pinconfig*() in order
to unify them in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move is_protected assignment closer to its user.
This increases readability and makes maintenance easier.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We would need to quirk out the Card Detect case and for that we allow
configuring the SD/SDIO family of pins.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Allow usage of the bootstage facilities in SPL.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-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>
Convert some of these occurences to C code, where it is easy to do. This
should help encourage this approach to be used in new code.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
The current API is outdated as it requires a devicetree pointer.
Move these functions to use the ofnode API and update this globally. Add
some tests while we are here.
Correct the call in exynos_dsim_config_parse_dt() which is obviously
wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
U_BOOT_DATE and U_BOOT_TIME are updated on every run of make command.
Therefore mrc.c file is recompiled every time when running make which means
that whole U-Boot binary is recompiled on every run of make command.
Simplify it and do not recompile U-Boot binary on every run of make command
by not depending on macros U_BOOT_DATE and U_BOOT_TIME.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
Initialize 'igd' and 'sdvo' to NULL so that we just need to test
them against NULL later, to be compatible with that case that IGD
and SDVO devices were already in disabled state.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The size parameter of mtrr_add_request() and mtrr_set_next_var()
shall be power of 2, otherwise the logic creates a mask that does
not meet the requirement of IA32_MTRR_PHYSMASK register.
Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP.
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>
At present mtrr_commit() programs the MTRR MSRs starting from
index 0, which may overwrite MSRs that were already programmed
by previous boot stage or FSP.
Switch to call mtrr_set_next_var() instead.
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>
Current mtrr_commit() logic assumes that MTRR MSRs are programmed
consecutively from index 0 to its maximum number, and whenever it
detects an unused one, it clears all other MTRRs starting from that
one. However this may not always be the case.
In fact, the clear is not much helpful because these MTRRs come out
of reset as disabled already. Drop the clear codes.
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>
Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.
This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These 2 options are no longer needed as now binman is used to build
u-boot.rom.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.
Note, in DSDT (see southcluster.asl) it's described correctly.
Fixes: 5e99fde34a ("x86: tangier: Populate CSRT for shared DMA controller")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use VENDOR_COREBOOT instead of TARGET_COREBOOT so we can have multiple
coreboot boards, sharing options. Only SYS_CONFIG_NAME needs to be
defined TARGET_COREBOOT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When starting U-Boot from a previous-stage bootloader we presumably don't
need to set up the variable MTRRs. In fact this could be harmful if the
existing settings are not what U-Boot uses.
Skip that step in this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When we do not have bootstage enabled, rather than include an empty
dummy function, we just don't reference it. This saves us space in some
tight builds. This also shows a few cases where show_boot_progress was
incorrectly guarded before.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
When switching to kernel.org x86_64 gcc 11.1.0 toolchain, u-boot.rom
built from qemu-x86_defconfig no longer boots anymore. Investigation
shows that U-Boot fails at a very early stage during the boot process,
in fdtdec_prepare_fdt() where fdt_check_header() complains that there
is not a valid device tree found at gd->fdt_blob which points to _end.
Now _end points to an allocated section .note.gnu.property which of
course is wrong.
This issue is however not seen when using the default Ubuntu 20.04 gnu
toolchain (gcc 9.3.0 with binutils 2.34). Further investigation shows
that it is caused by a behavior change of binutils v2.36 which is part
of the kernel.org gcc 11.1.0 toolchain, via the following commit:
939b95c77bf2 ("Linux/x86: Configure gas with --enable-x86-used-note by default")
In fact, there was already a regression bug report [1] for binutils two
months ago, but the binutils folks did not think it is a bug :(
To resolve this, there are several options:
* pass -Wa,-mx86-used-note=no to gas
* pass -R .note.gnu.property to objcopy
* discard the section in the linker script
Linux kernel uses the discard way [2], so let's do the same for U-Boot.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=27753
[2] commit 4caffe6a28d3 ("x86/vdso: Discard .note.gnu.property sections in vDSO")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This commit does the same thing as Linux commit 33def8498fdd.
Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.
Remove the quote operator # from compiler_attributes.h __section macro.
Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We move qfw into its own uclass and split the PIO functions into a
specific driver for that uclass. The PIO driver is selected in the
qemu-x86 board config (this covers x86 and x86_64).
include/qfw.h is cleaned up and documentation added.
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
At present the debug UART is only set up in SPL, on the assumption that
the boot flow will always pass through there. When booting from coreboot,
SPL is not used, so the debug UART is not available.
Move the code into a common place so that it can be used in U-Boot proper
also. Add the required init to start_from_spl.S as well.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this code into a generic location so that it can be used by other x86
boards which want to boot from coreboot. Also ensure that this is called
if booting from coreboot.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to parse coreboot tables on any x86 build which is
booted from coreboot. Add a new Kconfig option to enable this feature and
move the code so it can be used on any board, if enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
This all relates to the sysinfo structure provided by coreboot. Put the
timestamp definitions into the same file as the others. Tidy up a few
comments at the same time.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible to boot U-Boot for chromebook_coral either 'bare metal' or
from coreboot. In the latter case we want to provide access to the coreboot
sysinfo tables. Move the definitions into a file available to any x86
board.
Signed-off-by: Simon Glass <sjg@chromium.org>
With Apollo Lake, SPL is placed in read-only memory. Set this new option
so that OF_PLATDATA_INST can be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
With the standard of-platdata we must fix up driver_data manually. With
of-platadata-inst this is not necessary, since it is added to the device
by dtoc.
Update the code to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This enum is needed to generate build-time devices. Tell dtoc where to
find the header, to avoid compile errors in the generated code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
The dm.h header should come first. In fact it needs to, since otherwise
the driver model definitions are not available to dt-structs.h
Fix this, since it causes problems with OF_PLATDATA_INST.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Collect this together in one place, so driver model can access set it up
in a new place if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
At present most of the Intel-specific code is built on all devices, even
those which don't have software support for the features provided there.
This means that any board can enable CONFIG_INTEL_ACPIGEN even if it does
not have the required features.
Add a new INTEL_SOC option to control this access. This must be selected
by SoCs that can support the required features.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed a typo in arch/x86/Kconfig]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Building qemu-x86_64_defconfig with GCC 11.0 fails with:
arch/x86/cpu/intel_common/lpc.c:
In function ‘lpc_common_early_init’:
arch/x86/cpu/intel_common/lpc.c:56:40:
error: expression does not compute the number of elements in this array;
element type is ‘struct reg_info’, not ‘u32’ {aka ‘unsigned int’}
[-Werror=sizeof-array-div]
56 | sizeof(values) / sizeof(u32));
| ^
arch/x86/cpu/intel_common/lpc.c:56:40: note: add parentheses around the
second ‘sizeof’ to silence this warning
arch/x86/cpu/intel_common/lpc.c:50:11: note: array ‘values’ declared here
50 | } values[4], *ptr;
| ^~~~~~
Add parentheses to silence warning.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()
@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Unfortunately the multi-core boot for QEMU x86 has been broken since
commit 77a5e2d3bc ("x86: mp_init: Set up the CPU numbers at the start").
In order to support QEMU x86 multi-core boot, the /cpus node must be
bound before any actual fix up in qemu_cpu_fixup(). This adds the
uclass_get() call to ensure this, just like what was done before.
Fixes: 77a5e2d3bc ("x86: mp_init: Set up the CPU numbers at the start")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
At present BSS is always placed in SDRAM. If a separate BSS is not in use
this means that BSS doesn't work as expected. Make the setting conditional
on the SEPARATE_BSS option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The part of U-Boot that actually ends up in u-boot-nodtb.bin is not built
with any particular alignment. It ends at the start of the BSS section.
The BSS section selects its own alignment, which may larger.
This means that there can be a gap of a few bytes between the image
ending and BSS starting.
Since u-boot.bin is build by joining u-boot-nodtb.bin and u-boot.dtb (with
perhaps some padding for BSS), the expected result is not obtained. U-Boot
uses the end of BSS to find the devicetree, so this means that it cannot
be found.
Add 32-byte alignment of BSS so that the image size is correct and
appending the devicetree will place it at the end of BSS.
Example SPL output without this patch:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000142a1 fef40000 fef40000 00001000 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .u_boot_list 000014a4 fef542a8 fef542a8 000152a8 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .rodata 0000599c fef55760 fef55760 00016760 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
3 .data 00000970 fef5b100 fef5b100 0001c100 2**5
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .binman_sym_table 00000020 fef5ba70 fef5ba70 0001ca70 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .bss 00000060 fef5baa0 fef5baa0 00000000 2**5
ALLOC
You can see that .bss is aligned to 2**5 (32 bytes). This is because of
the mallinfo struct in dlmalloc.c:
17 .bss.current_mallinfo 00000028 00000000 00000000 000004c0 2**5
ALLOC
In this case the size of u-boot-spl-nodtb.bin is 0x1ba90. This matches up
with the _image_binary_end symbol:
fef5ba90 g .binman_sym_table 00000000 _image_binary_end
But BSS starts 16 bytes later, at 0xfef5baa0, due to the 32-byte
alignment. So we must align _image_binary_end to a 32-byte boundary. This
forces the binary size to be 0x1baa0, i.e. ending at the start of bss, as
expected.
Note that gcc reports __BIGGEST_ALIGNMENT__ of 16 on this build, even
though it generates an object file with a member that requests 32-byte
alignment.
The current_mallinfo struct is 40 bytes in size. Increasing the struct to
68 bytes (i.e. just above a 64-byte boundary) does not cause the alignment
to go above 32 bytes. So it seems that 32 bytes is the maximum alignment
at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: add more details in the commit message to help people understand]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Move to log_debug() and make use of the new SPL function to find the
text base.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
