summaryrefslogtreecommitdiff
path: root/arch/x86
AgeCommit message (Collapse)AuthorFilesLines
2021-09-22x86: tangier: acpi: Add GPIO card detection to SDHCI #2Andy Shevchenko1-0/+32
On Intel Tangier the SDHCI #2 provides SD card connection. Add GPIO card detection for it. Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier") BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135 Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2021-09-22x86: edison: Mark eMMC non-removableAndy Shevchenko1-0/+1
eMMC is non-removable on Intel Edison board. Fix the DTS accordingly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-08-17efi_loader rename enum efi_mem_type to efi_memory_typeHeinrich Schuchardt1-1/+1
Use the same name as in the UEFI specification to avoid confusion. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-08-03Merge https://source.denx.de/u-boot/custodians/u-boot-x86Tom Rini30-89/+101
- 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
2021-08-02global: Convert simple_strtoul() with hex to hextoul()Simon Glass1-7/+7
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>
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: fsp: Only FSP2 has INIT_PHASE_END_FIRMWAREBin Meng2-16/+17
For FSP1, there is no such INIT_PHASE_END_FIRMWARE. Move board_final_cleanup() to fsp2 directory. Fixes: 7c73cea44290 ("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>
2021-08-02x86: fsp: Don't program MTRR for DRAM for FSP1Bin Meng1-4/+23
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>
2021-08-02x86: mtrr: Abort if requested size is not power of 2Bin Meng2-3/+11
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: dts: Define a default TSC timer frequencyBin Meng20-43/+25
If for some reason, TSC timer frequency cannot be determined from hardware, nor is it specified in the device tree, U-Boot will panic resulting in endless reset during boot. Let's define a default TSC timer frequency using the Kconfig value CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of /include/ otherwise the macro is not pre-processed). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-08-02x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQBin Meng2-3/+3
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 Meng2-3/+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-08-02x86: dts: Add "m25p,fast-read" to SPI flash nodeBin Meng11-0/+11
Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should have "m25p,fast-read" property present in their DT nodes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-07-24smbios: error handling for invalid addressesHeinrich Schuchardt1-2/+11
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>
2021-07-15x86: Ensure the e820 map is installed in all casesSimon Glass1-4/+4
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: e7bae8283fe ("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>
2021-07-15x86: cros: Check ROM exists before building vbootSimon Glass2-2/+2
All the x86 devicetree files are built at once, whichever board is actually being built. If coreboot is the target build, CONFIG_ROM_SIZE is not defined and samus cannot build Chromium OS verified boot. Add this condition to avoid errors about CONFIG_ROM_SIZE being missing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
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: Add function comments to cb_sysinfo.hSimon Glass1-0/+16
Add a function comment for get_coreboot_info() and a declaration for cb_get_sysinfo(), since this may be called from elsewhere. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15x86: Do cache set-up by default when booting from corebootSimon Glass1-4/+14
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>
2021-07-15x86: Update the MP constants to avoid conflictsSimon Glass1-4/+8
These constants conflict with error codes returned by the MP implementation when something is wrong. In particular, mp_first_cpu() returns MP_SELECT_BSP when running without multiprocessing enabled. Since this is -2, it is interpreted as an error by callers, which expect a positive CPU number for the first CPU. Correct this by using a different range for the pre-defined CPU numbers, above zero and out of the range of possible CPU values. For now it is safe to assume there are no more than 64K CPUs. This fixes the 'mtrr' command when CONFIG_SMP is not enabled. 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-07x86: Drop _X86EMU_env definition when CONFIG_BIOSEMU is usedBin Meng1-0/+2
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>
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ún3-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>
2021-04-22lmb: move CONFIG_LMB in KconfigPatrick Delaunay1-1/+0
Migrate CONFIG_LMB in Kconfig. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-20Add support for stack-protectorJoel Peshkin1-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>
2021-04-20x86: correct usage of CFLAGS_NON_EFIHeinrich Schuchardt1-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>
2021-04-15x86: mtrr: Fix function descriptionsWolfgang Wallner1-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>
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: Show memory config and SKU ID on startupSimon Glass1-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>
2021-03-27cpu: Rename SPL_CPU_SUPPORT to SPL_CPUSimon Glass1-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>
2021-03-27x86: coreboot: Don't setup MTRR when booting from corebootSimon Glass1-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>
2021-03-27x86: fsp: Don't notify if booted from corebootSimon Glass1-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>
2021-03-27x86: coral: Fall back to coreboot video when FSP missingSimon Glass1-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>
2021-03-27x86: coral: Allow init of debug UART in U-Boot properSimon Glass4-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>
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: fsp: Don't enable FSP graphics if booted from corebootSimon Glass1-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>
2021-03-27x86: Allow installing an e820 when booting from corebootSimon Glass5-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>
2021-03-27x86: coreboot: Update parsing of the latest sysinfoSimon Glass3-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>
2021-03-27x86: Move coreboot sysinfo parsing into generic x86 codeSimon Glass5-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>
2021-03-27x86: coreboot: Sync up timestamp codesSimon Glass2-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>
2021-03-27x86: Move coreboot timestamp info into coreboot_tables.hSimon Glass3-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>
2021-03-27x86: Make coreboot sysinfo available to any x86 boardSimon Glass5-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-27cbfs: Allow access to CBFS without a headerSimon Glass1-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>
2021-03-27x86: coral: Update the SD card-detect GPIOSimon Glass1-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>
2021-03-27x86: coral: Put the eMMC firstSimon Glass1-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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-09 15:31:51 +0300