summaryrefslogtreecommitdiff
path: root/arch/x86/cpu
AgeCommit message (Collapse)AuthorFilesLines
2021-08-02x86: queensbay: Return directly if IGD / SDVO were already disabledBin Meng1-11/+9
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>
2021-08-02x86: mtrr: Abort if requested size is not power of 2Bin Meng1-0/+7
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>
2021-08-02x86: mtrr: Skip MSRs that were already programmed in mtrr_commit()Bin Meng1-1/+1
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>
2021-08-02x86: mtrr: Do not clear the unused ones in mtrr_commit()Bin Meng1-4/+0
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>
2021-08-02x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQBin Meng1-2/+2
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>
2021-08-02x86: kconfig: Drop ROM_NEEDS_BLOBS and BUILD_ROMBin Meng1-1/+0
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>
2021-08-02x86: tangier: Fix DMA controller IRQ polarity in CSRTAndy Shevchenko1-2/+2
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: 5e99fde34a77 ("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>
2021-07-15x86: coreboot: Use vendor in the KconfigSimon Glass1-1/+1
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>
2021-07-15x86: Don't set up MTRRs if previously doneSimon Glass1-1/+1
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>
2021-07-07bootstage: Eliminate when not enabledTom Rini1-0/+2
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>
2021-06-23x86: Discard .note.gnu.property sectionsBin Meng3-0/+3
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>
2021-05-24treewide: Convert macro and uses of __section(foo) to __section("foo")Marek Behún1-1/+1
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>
2021-04-13x86: qemu: move QFW to its own uclassAsherah Connor3-48/+21
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>
2021-03-27x86: coral: Allow init of debug UART in U-Boot properSimon Glass3-58/+64
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>
2021-03-27x86: coral: Avoid build error with !CONFIG_ACPIGENSimon Glass1-5/+9
When CONFIG_ACPIGEN is not enabled the CPU code does not build. Fix this by moving things around. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-27x86: Allow installing an e820 when booting from corebootSimon Glass1-26/+1
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>
2021-03-27x86: Move coreboot sysinfo parsing into generic x86 codeSimon Glass2-256/+0
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>
2021-03-27x86: Move coreboot timestamp info into coreboot_tables.hSimon Glass1-12/+0
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>
2021-03-27x86: Make coreboot sysinfo available to any x86 boardSimon Glass4-4/+4
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>
2021-03-26x86: apl: Use read-only SPL and new of-platdataSimon Glass1-0/+2
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>
2021-03-26x86: itss: Tidy up bind() for of-platdata-instSimon Glass1-2/+3
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>
2021-03-26x86: apl: Tell of-platdata about a required header fileSimon Glass1-0/+1
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>
2021-03-26x86: apl: Fix the header order in pmcSimon Glass1-1/+1
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>
2021-03-26x86: Define a region for device priv/plat dataSimon Glass1-0/+8
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>
2021-03-15Merge tag 'v2021.04-rc4' into nextTom Rini2-1/+2
Prepare v2021.04-rc4
2021-03-09x86: Select advanced Intel code only if allowedSimon Glass1-0/+1
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>
2021-03-09x86: sizeof-array-div error in lpc_common_early_initHeinrich Schuchardt1-1/+1
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>
2021-03-02reset: Remove addr parameter from reset_cpu()Harald Seiler1-1/+1
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>
2021-02-15Merge branch '2021-02-02-drop-asm_global_data-when-unused'Tom Rini54-5/+49
- Merge the patch to take <asm/global_data.h> out of <common.h>
2021-02-03x86: qemu: Fix broken multi-core bootBin Meng1-0/+6
Unfortunately the multi-core boot for QEMU x86 has been broken since commit 77a5e2d3bc61 ("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: 77a5e2d3bc61 ("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>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass54-5/+49
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>
2021-02-01x86: spl: Make moving BSS conditionalSimon Glass1-0/+2
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>
2021-02-01x86: Make sure the SPL image ends on a suitable boundarySimon Glass1-0/+10
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>
2021-02-01x86: apl: Enhance debugging in the SPL loaderSimon Glass1-5/+7
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>
2021-02-01x86: acpi_gpe: Update driver name to match devicetreeSimon Glass1-2/+4
Use a driver name in line with the compatible string so that of-platdata can use this driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-01-31x86: typo segementHeinrich Schuchardt2-2/+2
%s/segement/segment/ Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-01-06Merge tag 'dm-pull-5jan21' of git://git.denx.de/u-boot-dm into nextTom Rini14-123/+78
Driver model: make some udevice fields private Driver model: Rename U_BOOT_DEVICE et al. dtoc: Tidy up and add more tests ns16550 code clean-up x86 and sandbox minor fixes for of-platdata dtoc prepration for adding build-time instantiation
2021-01-06Merge tag 'v2021.01-rc5' into nextTom Rini2-5/+46
Prepare v2021.01-rc5 Signed-off-by: Tom Rini <trini@konsulko.com>
2021-01-05x86: apl: Adjust how the UART gets its platform dataSimon Glass1-19/+24
At present this driver calls malloc() to start a new platform data structure, fills it in and tells driver model to use it. We want to avoid malloc, particularly with the new version of of-platdata. Create a new struct which encompasses both the dtd struct and the ns16550 one, to avoid this. Unfortunately we must copy the data into the right place for the ns16550 driver. Add some comments about this. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: apl: Use struct spi_nor instead of struct spi_flashSimon Glass1-1/+1
This construct effectively uses struct spi_nor due to a #define in spi-nor.h so we may as well use that struct here. This allows dtoc to parse it correctly. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: Move priv/plat structs for intel_common to headersSimon Glass2-27/+1
With the new of-platdata, these need to be available to dt_platdata.c so must be in header files. Move them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: apl: Move priv/plat structs to headersSimon Glass2-26/+2
With the new of-platdata, these need to be available to dt_platdata.c so must be in header files. Move them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: apl: Reduce size for TPLSimon Glass8-11/+29
Update various drivers to use of_match_ptr() and to avoid including debug strings in TPL. Omit the WiFi driver entirely, since it is not used in TPL. This reduces the TPL binary size by about 608 bytes. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: apl: Update hostbridge to remove unwanted TPL codeSimon Glass1-5/+9
At present several strings from this file appear in the TPL binary. Add preprocessor checks to drop them. This reduces the TPL binary size by about 128 bytes. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: coral: Move fsp-m settings to a subnodeSimon Glass1-1/+4
At present these settings are in the node for host-bridge and so are visible in TPL as well as SPL. But they are only used for SPL. Move them to a subnode so that TPL does not included them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: Move call64 into its own sectionSimon Glass1-0/+1
When this code is not used (e.g. by TPL) we want it to be excluded from the image. Put it in its own section so that this happens. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05x86: apl: Use const for driver operationsSimon Glass2-2/+2
Update these declarations to const to ensure that the data ends up in the rodata section. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05dm: Use access methods for dev/uclass private dataSimon Glass2-2/+3
Most drivers use these access methods but a few do not. Update them. In some cases the access is not permitted, so mark those with a FIXME tag for the maintainer to check. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Pratyush Yadav <p.yadav@ti.com>
2021-01-05x86: apl: Drop support for !OF_PLATDATA_PARENTSimon Glass2-28/+1
This code was kept around after of-platdata started supporting parent devices. That feature seems stable now, so let's drop it. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05serial: Update NS16550_t and struct NS16550Simon Glass2-2/+2
Typedefs should not be used in U-Boot and structs should be lower case. Update the code to use struct ns16550 consistently. Put a header guard on the file while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>