summaryrefslogtreecommitdiffstats
path: root/arch/x86
Commit message (Collapse)AuthorAgeFilesLines
* treewide: Convert macro and uses of __section(foo) to __section("foo")Marek Behún2021-05-243-6/+7
| | | | | | | | | | | | | | | | | 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>
* lmb: move CONFIG_LMB in KconfigPatrick Delaunay2021-04-221-1/+0
| | | | | | Migrate CONFIG_LMB in Kconfig. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* Add support for stack-protectorJoel Peshkin2021-04-201-1/+1
| | | | | | | | | | Add support for stack protector for UBOOT, SPL, and TPL as well as new pytest for stackprotector Signed-off-by: Joel Peshkin <joel.peshkin@broadcom.com> Adjust UEFI build flags. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* x86: correct usage of CFLAGS_NON_EFIHeinrich Schuchardt2021-04-201-4/+6
| | | | | | | | | | The current usage of the variable CFLAGS_NON_EFI on the x86 architecture deviates from other architectures. Variable CFLAGS_NON_EFI is the list of compiler flags to be removed when building UEFI applications. It is not a list of flags to be added anywhere. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* x86: mtrr: Fix function descriptionsWolfgang Wallner2021-04-151-2/+2
| | | | | | | | Fix copy/paste errors in the descriptions of mtrr_close () and mtrr_set(). Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: move QFW to its own uclassAsherah Connor2021-04-123-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>
* x86: coral: Show memory config and SKU ID on startupSimon Glass2021-03-271-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide the model information through sysinfo so that it shows up on boot. For memconfig 4 pins are provided, for 16 combinations. For SKU ID there are two options: - two pins provided in a ternary arrangement, for 9 combinations. - reading from the EC Add a binding doc and drop the unused #defines as well. Example: U-Boot 2021.01-rc5 CPU: Intel(R) Celeron(R) CPU N3450 @ 1.10GHz DRAM: 3.9 GiB MMC: sdmmc@1b,0: 1, emmc@1c,0: 2 Video: 1024x768x32 @ b0000000 Model: Google Coral (memconfig 5, SKU 3) This depends on the GPIO series: http://patchwork.ozlabs.org/project/uboot/list/?series=228126 Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
* cpu: Rename SPL_CPU_SUPPORT to SPL_CPUSimon Glass2021-03-271-1/+1
| | | | | | | | | The _SUPPORT suffix is from an earlier time and interferes with use of the CONFIG_IS_ENABLED() macro. Rename the option to drop the suffix. Tidy up the TODO that prompted this. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Don't setup MTRR when booting from corebootSimon Glass2021-03-271-3/+3
| | | | | | | This currently hangs and it is not necessary in any case. Drop the code when booting from coreboot. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: fsp: Don't notify if booted from corebootSimon Glass2021-03-271-0/+4
| | | | | | | | | | When booting from coreboot there is no need to notify the FSP of anything, since coreboot has already done it. Nor it is possible, since the FSP details are not provided by coreboot. Skip it in this case. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coral: Fall back to coreboot video when FSP missingSimon Glass2021-03-271-0/+5
| | | | | | | | When booting from coreboot the FSP video information is no-longer available. Enable the coreboot driver so that we can get some sort of display in this case. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coral: Allow init of debug UART in U-Boot properSimon Glass2021-03-274-58/+65
| | | | | | | | | | | 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>
* x86: coral: Avoid build error with !CONFIG_ACPIGENSimon Glass2021-03-271-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>
* x86: fsp: Don't enable FSP graphics if booted from corebootSimon Glass2021-03-271-1/+1
| | | | | | | | This driver cannot work when booted from coreboot, since the FSP information is not available. Disable it in that case, so that the coreboot video driver can be used instead. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Allow installing an e820 when booting from corebootSimon Glass2021-03-275-29/+69
| | | | | | | | 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>
* x86: coreboot: Update parsing of the latest sysinfoSimon Glass2021-03-273-57/+525
| | | | | | | | | | Quite a few new tag types have been added over the years. Bring these into U-Boot so that all required tags can be parsed. Add a proper comment to struct sysinfo_t while we are here, since many of the meanings are not obvious. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Move coreboot sysinfo parsing into generic x86 codeSimon Glass2021-03-275-1/+28
| | | | | | | | 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>
* x86: coreboot: Sync up timestamp codesSimon Glass2021-03-272-2/+64
| | | | | | | | | | | Add new timestamp codes that are present in coreboot, so that we can decode these in U-Boot. At present TS_U_BOOT_START_KERNEL is used twice. It should only be used just before jumping to Linux, so update the other call site to use TS_START_KERNEL. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Move coreboot timestamp info into coreboot_tables.hSimon Glass2021-03-273-36/+39
| | | | | | | | 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>
* x86: Make coreboot sysinfo available to any x86 boardSimon Glass2021-03-275-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>
* cbfs: Allow access to CBFS without a headerSimon Glass2021-03-271-1/+2
| | | | | | | | | | In some cases CBFS does not start with a header but is just a collection of files. It is possible to support this so long as the size of the CBFS is provided. Update the cbfs_init_mem() function to support this. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coral: Update the SD card-detect GPIOSimon Glass2021-03-271-1/+1
| | | | | | | | | Since the recent bug fix, it doesn't matter which GPIO phandle is used so long as the GPIO number is right. Still, we may as well use the correct one to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
* x86: coral: Put the eMMC firstSimon Glass2021-03-271-0/+1
| | | | | | | | | | | At present the eMMC device does not have an alias so it appears after the SD card which is device 1. There is no device 0 which is odd. Make the eMMC device be the first one. Update the boot script to use the new device. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
* x86: dts: Drop unused CONFIG_SPLSimon Glass2021-03-261-5/+1
| | | | | | | This cannot be used since the previous #elif has already dealt with SPL. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Make use of binman expanded entriesSimon Glass2021-03-261-10/+1
| | | | | | | | We don't need to spell out the separate pieces of U-Boot phase binaries anymore. Revert to using the simple entry and let binman do the expansion itself as needed. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: apl: Use read-only SPL and new of-platdataSimon Glass2021-03-261-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>
* x86: coral: Drop TPM and ACPI interrupts from TPLSimon Glass2021-03-261-5/+5
| | | | | | | | | | | These devices are not actually built in TPL but are currently active in the TPL devicetree. For of-platdata-inst this means that we will try to generate devices for them, which fails. Update them to be active only in U-Boot proper. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Don't include reset driver in SPLSimon Glass2021-03-261-1/+1
| | | | | | | | We don't normally need this driver in TPL/SPL, so drop it for now. It can be enabled by individual boards if needed. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Support a fake PCI device with of-platdata-instSimon Glass2021-03-261-0/+1
| | | | | | | | | | | | | | | | With TPL we don't need full PCI support and it adds to code size. Instead, a simple_bus driver is good enough to be able to read and write the PCI config and do a little basic setup. So at present there are two drivers in U-Boot called pci_x86. One is in UCLASS_PCI, used in SPL and U-Boot proper. The other is in UCLASS_SIMPLE_BUS and used only in TPL. Add a tag to tell dtoc about this, so it knows which one to use when generating the devices and uclasses. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: itss: Tidy up bind() for of-platdata-instSimon Glass2021-03-261-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>
* x86: apl: Tell of-platdata about a required header fileSimon Glass2021-03-261-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>
* x86: apl: Fix the header order in pmcSimon Glass2021-03-261-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>
* x86: Define a region for device priv/plat dataSimon Glass2021-03-261-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>
* Merge tag 'v2021.04-rc4' into nextTom Rini2021-03-154-1/+30
|\ | | | | | | Prepare v2021.04-rc4
| * x86: Select advanced Intel code only if allowedSimon Glass2021-03-092-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * x86: Move INTEL_ACPIGEN to arch/x86Simon Glass2021-03-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | This option is better placed in the x86 code since it is not generic enough to be in the core code. Move it. 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>
| * x86: Fix member check in intel_gnvsSimon Glass2021-03-091-0/+4
| | | | | | | | | | | | | | | | When CONFIG_CHROMEOS is not enabled this currently does not build. Fix it. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: sizeof-array-div error in lpc_common_early_initHeinrich Schuchardt2021-03-091-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>
* | gpio: x86: Drop the deprecated methods in intel_gpioSimon Glass2021-03-031-0/+5
| | | | | | | | | | | | | | We don't need to implement direction_input() and direction_output() anymore. Drop them and use update_flags() instead. Signed-off-by: Simon Glass <sjg@chromium.org>
* | reset: Remove addr parameter from reset_cpu()Harald Seiler2021-03-021-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>
* Merge branch '2021-02-02-drop-asm_global_data-when-unused'Tom Rini2021-02-1588-7/+90
|\ | | | | | | - Merge the patch to take <asm/global_data.h> out of <common.h>
| * common: Drop asm/global_data.h from common headerSimon Glass2021-02-0288-7/+90
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | x86: qemu: Fix broken multi-core bootBin Meng2021-02-031-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>
* x86: tpl: Show next stage being bootedSimon Glass2021-02-011-1/+6
| | | | | | | | Enhance the debugging to show the next stage being booted as well as a dump of the start of the image. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: spl: Clear BSS unconditionallySimon Glass2021-02-011-1/+1
| | | | | | | | This should be done even if not using TPL, since BSS may be in use or boards that only use SPL. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: zimage: Improve command-line debug handlingSimon Glass2021-02-011-3/+7
| | | | | | | | | | At present if the command line is very long it is truncated by the printf() statement, which works within a limited buffer. Use puts() instead. Also show better debugging with the command-line setup fails. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: zimage: Allow dumping the image from outside the moduleSimon Glass2021-02-012-8/+25
| | | | | | | | | | | At present it is possible to dump an image within the zimage command, but it is also useful to be able to dump it from elsewhere, for example in a loader that has special handling for the different zimage stages. Export this feature as a new function. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Update Chromium OS GNVS namesSimon Glass2021-02-011-6/+28
| | | | | | | | | | | The Global Non-Volatile Storage struct has some fields with particular meanings. Rename these to make things easier to follow. Also add a few more boot flags. GNVS should not be confused with GNVQ (Going Nowhere Very Quickly). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: spl: Make moving BSS conditionalSimon Glass2021-02-011-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>
* x86: Make sure the SPL image ends on a suitable boundarySimon Glass2021-02-011-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>
generated by cgit (git 2.34.1) at 2025-09-02 18:20:15 +0000