summaryrefslogtreecommitdiff
path: root/src/arch/x86
AgeCommit message (Collapse)Author
2022-06-07arch/x86: Add a common romstage entryArthur Heymans
It might be possible to have this used for more than x86, but that will be for a later commit. Change-Id: I4968364a95b5c69c21d3915d302d23e6f1ca182f Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55067 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-06-03arch/x86/acpi: Replace LGreater(a,b) with ASL 2.0 syntaxFelix Singer
Replace `LGreater(a, b)` with `a > b`. Change-Id: I0cabf4f69191fe345fd72619847db384db2e0e87 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60687 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-06-01driver/intel/fsp2_0: Disable NULL deref code when calling FSPArthur Heymans
FSP needs interrupts disable so also disable generating exceptions around debug registers. Change-Id: Ia49dde68d45b71e231aaf32a0e6fd847f0e06146 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64426 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com> Reviewed-by: Sean Rhodes <sean@starlabs.systems> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-05-31x86/include/arch/boot: Fix header guardElyes Haouas
While on it, reformat code and remove unused macro. Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I63e413820cb3f4dfa21d1692301348ecdb3190b9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64784 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
2022-05-31x86/null_breakpoint: Remove trailing space from log messagePaul Menzel
Currently, the log message contains an unwanted trailing space, so remove it. [ERROR] Null dereference at eip: 0x3ffad01a Change-Id: I64509ca4bad94c7db4279cc4c1e6fee2bba2e035 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64799 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-05-28Kconfig: Mark clang as ready to use on some archArthur Heymans
This adds 2 flags: * invisible opt-in flag for platforms on which clang seems to work * visible opt-in flag to allow experimenting Clang seems to work rather well on x86_32 so it makes sense to start adding that to Jenkins buildtesting, which this allows. This allows abuild to differentiate between targets that are known to build with clang. This makes buildtesting just those targets easier. Change-Id: I46f1bad59bda94f60f4a141237ede11f6eb93cc2 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63081 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@tutanota.com>
2022-05-28arch/x86/tables.c: Increase MAX_SMBIOS_SIZEArthur Heymans
Systems have a lot more cores now and 4KiB is not cutting it. E.g. for a system with 255 cores more than 16KiB is needed. We could also make this a Kconfig parameter but it's probably not worth having such micro optimizations to save a few KiB. Change-Id: Idd47e55d8d679cc70eae996ee1af3ad7eaa1d0cc Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63484 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-05-28arch/x86/smbios.c: Fix for CONFIG_MAX_CPUS > 255Arthur Heymans
Change-Id: I079c99006fea95ba3dc2fb02c95a3747af55e218 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63482 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-05-28arch/x86/car.ld: Remove AGESA linker warning workaroundArthur Heymans
Now that all AGESA codebases have been fixed to not use the .data section, the warning workaround can be disabled. Change-Id: I675d169a5d2f16e1e9ae05f95e045e9ef3d12208 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64401 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Martin L Roth <gaumless@tutanota.com>
2022-05-27Makefile.inc: Add bootblock to CBFS before othersYu-Ping Wu
With CBFS verification, cbfstool (CB:41121) needs bootblock to be present in coreboot.pre in order to locate the metadata hash stored in it. Therefore we have to ensure that bootblock is added to CBFS before other CBFS files are added. To solve the problem, create the 'add_bootblock' function, and call it in the coreboot.pre recipe. Because bootblock.bin is now a prerequisite of coreboot.pre, it will get built even if CONFIG_BOOTBLOCK_IN_CBFS=n. BUG=b:233263447 TEST=emerge-guybrush coreboot TEST=emerge-corsola coreboot chromeos-bootimage TEST=cbfstool image-kingler.bin print -v TEST=Kingler booted successfully BRANCH=none Change-Id: I385deb8231e44310ee139c3f69f449e75b92b2be Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-05-25arch/x86/acpi_bert_storage.c: Use a common implementationArthur Heymans
All targets now use cbmem for the BERT region, so the implementation can be common. This also drops the obsolete comment about the need to have bert in a reserved region (cbmem gets fixed to be in a reserved region). Change-Id: I6f33d9e05a02492a1c91fb7af94aadaa9acd2931 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64602 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-05-19arch/x86/car.ld: Add a Kconfig param to flag AGESA brokennessArthur Heymans
AGESA has a lot of code in the .data section (initialized data). However there is no such section in CAR stages as the code runs in XIP mode and CAR is too small to contain the data section. When the linker can not match code to a section it will just append it, which is why AGESA worked at all. Follow-up patches will attempt to fix AGESA and set Kconfig parameter to 'n'. After all AGESA sources have been fixed, this can be removed. Change-Id: I311ee17e3c0bd283692194fcee63af4449583d74 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64387 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2022-05-18arch/x86: Make sure bootblock gets buildtestedArthur Heymans
Now that the bootblock isn't added to cbfs anymore, on some targets it's only conditionally build. One example would be Intel APL where it only gets build when stitched into an IFWI. This is always done when compiling for real targets but not by the CI builder. This adds a dummy target to make sure the bootblock always gets buildtested. Change-Id: I60601e01a2c370b5c21493b71d51f495bb42f41d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2022-05-17arch/x86/ebda.c: Move setting up ebda to a BS hookArthur Heymans
device.c should not hold arch specific code. Change-Id: I9dfdb905a83916c0e9d298e1c38da89f6bc5e038 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64297 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2022-05-16acpi, arch/x86/smp/mpspec,soc/amd/common: Move MP_IRQ_ flags into acpi.hRaul E Rangel
The MP_IRQ flags can be used in the MP table and the ACPI MADT table. Move them into acpi.h to avoid pulling in the full mpspec.h which is only available on x86. BUG=b:218874489, b:160595155 TEST=Build Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I4f1091b7629a6446fa399720b0270556a926401a Reviewed-on: https://review.coreboot.org/c/coreboot/+/63845 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-05-16arch/x86/postcar_loader.c: Change prepare_and_run_postcar signatureArthur Heymans
The postcar frame can now be a local variable to that function. Change-Id: I873298970fff76b9ee1cae7da156613eb557ffbc Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61964 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-16arch/x86/postcar_loader.c: Reduce the scope of functionsArthur Heymans
Some functions are only called locally. Change-Id: I96a4e40a225536f62abb2a15c55d333b8604e8cc Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61963 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-16arch/x86/postcar: Set up postcar MTRR in C codeArthur Heymans
Setting up postcar MTRRs is done when invd is already called so there is no reason to do this in assembly anymore. This also drops the custom code for Quark to set up MTRRs. TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set in postcar & ramstage. Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-05-16arch/x86/null_breakpoint: Remove handler before jumping to payloadArthur Heymans
If a payload did any NULL dereferencing it would be broken and jump back to coreboot code. This fixes the SeaBIOS, FILO and possibly other payloads too. Fixes: 3f01cd14533f ("arch/x86: Add support for catching null dereferences through debug regs") TESTED on qemu/i440fx. Change-Id: I80f69b71f4d0fab3126e4b9f8c8dc7737b372174 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64345 Reviewed-by: Robert Zieba <robertzieba@google.com> Reviewed-by: Stefan Ott <coreboot@desire.ch> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-05-12arch/x86: Add support for catching null dereferences through debug regsRobert Zieba
This commit adds support for catching null dereferences and execution through x86's debug registers. This is particularly useful when running 32-bit coreboot as paging is not enabled to catch these through page faults. This commit adds three new configs to support this feature: DEBUG_HW_BREAKPOINTS, DEBUG_NULL_DEREF_BREAKPOINTS and DEBUG_NULL_DEREF_HALT. BUG=b:223902046 TEST=Ran on nipperkin device, verifying that HW breakpoints work as expected. Change-Id: I113590689046a13c2a552741bbfe7668a834354a Signed-off-by: Robert Zieba <robertzieba@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-12Kconfig: Add an option to skip adding a cbfs bootblock on x86Arthur Heymans
Some targets don't need this as the bootblock is loaded differently. Change-Id: Ia42448f7e9dd0635c72857fbc1fab54508932721 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63377 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-12Makefile.inc: Add x86 bootblock as a separate targetArthur Heymans
Some platforms don't need a top aligned bootblock in cbfs like Intel APL or modern AMD platforms as the bootblock is loaded differently. So they don't need the top aligned cbfs bootblock. To not clutter the main make file move out adding the bootblock. Change-Id: I4de9d7fedf1ae5a37a3310dd42eb07b44c030930 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56122 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-12Makefile.inc: Generate master header and pointer as C structsArthur Heymans
The makefiles don't like cbfs file names with spaces in them so update the file name with '_' instead of spaces. To keep the master header at the top of cbfs, add a placeholder. This removes the need to handle the cbfs master header in cbfstool. This functionality will be dropped in a later CL. On x86 reserve some space in the linker script to add the pointer. On non-x86 generate a pointer inside a C struct file. As a bonus this would actually fix the master header pointer mechanism on Intel/APL as only the bootblock inside IFWI gets memory mapped. TESTED on thinkpad X201: SeaBIOS correctly finds the cbfs master header. Change-Id: I3ba01be7da1f09a8cac287751497c18cda97d293 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59132 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-04arch/x86/acpi: Consolidate POST code handlingAngel Pons
Move ASL POST code declarations into a common file to avoid redundancy. Also, provide a dummy implementation when `POST_IO` is not enabled, as the value of `CONFIG_POST_IO_PORT` can't be used. Change-Id: I891bd8754f10f16d618e76e1ab88c26164776a50 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63988 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2022-05-04arch/x86/acpi/debug.asl: Drop POST code stuffAngel Pons
To pave the way for future refactoring commits, drop POST code elements from the debug.asl file. Only msi/ms7721 includes debug.asl and it does not use any of it anyway. Change-Id: Icd73e5c1f700fd7e735bed1668f02da8f9a3adf3 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63986 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-04-25arch/x86/acpi_bert_storage.c: Use BOOT_STATE over CBMEM hooksArthur Heymans
With the purpose of linking ramstage inside the bootblock we likely want to skip some ramstage CBMEM hooks and keep those only for recovering data from earlier stages. Change-Id: I317173d468073906d76228d1c8cc7bc28aae9e75 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63415 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-04-24{arch,cpu}: Remove redundant <arch/cpu.h>Elyes HAOUAS
<arch/cpu.h> is chain included through <cpu/cpu.h>. Change-Id: I54a837394f67ac2a759907c7212ab947d07338dc Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60931 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <martinroth@google.com>
2022-04-14x86/mtrr: Print address ranges inclusive to be more consistentWerner Zeh
The printed address ranges in the tree (resource allocator and even some MTRR code) usually shows the range inclusive (meaning from start address to the real end address of the range). Though there is still some code in the MTRR context which prints the ranges with an exclusive end. This patch aligns the printing of ranges in the MTRR code to be consistent among the tree so that the shown end addresses are now inclusive. Change-Id: I0ca292f9cf272564cb5ef1c4ea38f5c483605c94 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63541 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2022-04-01arch/x86/postcar: Use a separate stack for C executionArthur Heymans
Add a stack in .bss for C execution. This will make it easier to move the setup of MTRRs in C code. Change-Id: I67cbc988051036b1a0519cec9ed614acede31fd7 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54298 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-04-01arch/x86/Kconfig: Drop obsolete fixed ramstage symbolsArthur Heymans
On x86 ramstage is always relocated at runtime in cbmem so there is no need to have this configurable in Kconfig. Change-Id: I01b2335d0b82bea8f885ee5ca9814351bbf2aa3c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63215 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-03-09prog_loader: Change legacy_romstage_select_and_load() to return cb_errJulius Werner
This is passing through a cb_err from cbfs_prog_stage_load(), so it should be declared to return that as well. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I5510d05953fe8c0e2cb511f01f862b66ced154ae Reviewed-on: https://review.coreboot.org/c/coreboot/+/62656 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-03-08timestamps: Rename timestamps to make names more consistentJakub Czapiga
This patch aims to make timestamps more consistent in naming, to follow one pattern. Until now there were many naming patterns: - TS_START_*/TS_END_* - TS_BEFORE_*/TS_AFTER_* - TS_*_START/TS_*_END This change also aims to indicate, that these timestamps can be used to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-03-08device/mmio.h: Move readXp/writeXp helpers to device/mmio.hJianjun Wang
These helpers are not architecture dependent and it might be used for different platform. Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com> Change-Id: Ic13a94d91affb7cf65a2f22f08ea39ed671bc8e8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62561 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-02-25arch/x86: consolidate HPET base address definitionsFelix Held
Both the HPET_BASE_ADDRESS define from arch/x86/include/arch/hpet.h and the HPET_ADDRESS Kconfig option define the base address of the HPET MMIO region which is 0xfed00000 on all chipsets and SoCs in the coreboot tree. Since these two different constants are used in different places that however might end up used in the same coreboot build, drop the Kconfig option and use the definition from arch/x86 instead. Since it's no longer needed to check for a mismatch of those two constants, the corresponding checks are dropped too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia797bb8ac150ae75807cb3bd1f9db5b25dfca35e Reviewed-on: https://review.coreboot.org/c/coreboot/+/62307 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Lance Zhao Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-02-25arch/x86: factor out and commonize HPET_BASE_ADDRESS definitionFelix Held
All x86 chipsets and SoCs have the HPET MMIO base address at 0xfed00000, so define this once in arch/x86 and include this wherever needed. The old AMD AGESA code in vendorcode that has its own definition is left unchanged, but sb/amd/cimx/sb800/cfg.c is changed to use the new common definition. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifc624051cc6c0f125fa154e826cfbeaf41b4de83 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62304 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-02-25arch/x86/Kconfig: add HPET_MIN_TICKSFelix Held
Some Intel southbridges have HPET_MIN_TICKS in their Kconfig files, but the CONFIG_HPET_MIN_TICKS symbol is used in the common acpi code in acpi/acpi.c, so define this option in arch/x86/Kconfig to have it defined in all cases where the function that ends up using this information gets called. Since we now have the type information for this Kconfig option in a central place, it can be dropped from the Kconfig file of the Intel southbridges that change the default value. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibe012069dd4b51c15a8fbc6459186ad2ea405a03 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62298 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-02-24arch/x86/Kconfig: drop HPET_ADDRESS_OVERRIDEFelix Held
Commit b433d26ef11b78dda353723ff7c8797d06f76f21 (arch/x86: Define HPET_ADDRESS_OVERRIDE) added this Kconfig option and referenced the via/cx700 chipset which has been dropped before the 4.9 release. No SoC in the current tree selects HPET_ADDRESS_OVERRIDE and all SoCs have their HPET mapped at 0xfed00000, so drop this unused and no longer needed Kconfig option. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4021ed6f84473c7a9223323fc8aa5d3f935d8084 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62276 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-02-15arch/x86/id.S: Fix building with clangAngel Pons
Commit 0e688b113d7fd98dfdb69cd0a407c8efcd968456 (arch/x86/id.S: Fix building with clang) broke building with GCC 8.3 so this approach should work for both GCC 8.3 and clang. The clang error is: CC bootblock/arch/x86/id.o /tmp/id-35b17a.s:35:7: error: expected relocatable expression .long - ver ^ /tmp/id-35b17a.s:36:7: error: expected relocatable expression .long - vendor ^ /tmp/id-35b17a.s:37:7: error: expected relocatable expression .long - part ^ Change-Id: Ide3d313800641d4d9b5f79127f84d9fdb4ec2b96 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61927 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2022-02-15Revert "arch/x86/id.S: Fix building with clang"Angel Pons
This reverts commit 0e688b113d7fd98dfdb69cd0a407c8efcd968456. Reason for revert: Breaks building with GCC 8.3 which is currently needed to build bootable coreboot images for Ironlake boards: src/arch/x86/id.S: Assembler messages: src/arch/x86/id.S:14: Error: value of 4294967344 too large for field of 4 bytes at 48 src/arch/x86/id.S:15: Error: value of 4294967327 too large for field of 4 bytes at 52 src/arch/x86/id.S:16: Error: value of 4294967318 too large for field of 4 bytes at 56 Change-Id: I9e13b15c062bc6598717382b1fedfa120c6d7209 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61926 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2022-02-12arch/x86/id.S: Fix building with clangArthur Heymans
The following error message is now gone: CC bootblock/arch/x86/id.o /tmp/id-35b17a.s:35:7: error: expected relocatable expression .long - ver ^ /tmp/id-35b17a.s:36:7: error: expected relocatable expression .long - vendor ^ /tmp/id-35b17a.s:37:7: error: expected relocatable expression .long - part ^ Tested with BUILD_TIMELESS=1 on x86_32 with gcc. The binary stays the same. Change-Id: I930e7b96c4428bcb95ff1903e6a3e7679171ffee Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51500 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2022-02-12arch/x86/acpi: Replace LEqual(a,b) with ASL 2.0 syntaxFelix Singer
Replace `LEqual(a, b)` with `a == b`. Change-Id: Iabfaaee22011a75cc981607d366d61660838ab21 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60656 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-02-07treewide: Remove "ERROR: "/"WARN: " prefixes from log messagesJulius Werner
Now that the console system itself will clearly differentiate loglevels, it is no longer necessary to explicitly add "ERROR: " in front of every BIOS_ERR message to help it stand out more (and allow automated tooling to grep for it). Removing all these extra .rodata characters should save us a nice little amount of binary size. This patch was created by running find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';' and doing some cursory review/cleanup on the result. Then doing the same thing for BIOS_WARN with 's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi' Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Lance Zhao Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2022-01-15arch/x86/spinlock.h: Support systems with >128 coresArthur Heymans
Each time the spinlock is acquired a byte is decreased and then the sign of the byte is checked. If there are more than 128 cores the sign check will overflow. An easy fix is to increase the word size of the spinlock acquiring and releasing. TEST: See that serialized SMM relocation is still serialized on systems with >128 cores. Change-Id: I76afaa60669335090743d99381280e74aa9fb5b1 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60539 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-01-01src: Drop duplicated includesElyes HAOUAS
<types.h> already provides <commonlib/bsd/cb_err.h>, <limits.h>, <stdbool.h>, <stdint.h> and <stddef.h> headers. Change-Id: I700b3f0e864ecce3f8b3b66f3bf6c8f1040acee1 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60437 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-01-01arch/x86/acpi: Replace Increment() with ASL 2.0 syntaxFelix Singer
Replace `Increment(a)` with `a++`. Change-Id: I45ce13509f3e93d7d8cd69689604f24b926bcfbc Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60579 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2022-01-01arch/x86/acpi: Replace Index() with ASL 2.0 syntaxFelix Singer
Replace `Index (FOO, 0)` with `FOO[0]`. Change-Id: Ief0f855a449d67542d6b1b56a2b76919c4cb8e2c Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60562 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-12-31arch/x86/acpi: Replace Add(a,b,c) with ASL 2.0 syntaxFelix Singer
Replace `Add (a, b, c)` with `c = a + b`. Change-Id: I10a94406aa7e66eed4fec22f56b7a8802252e781 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2021-12-21arch/x86: Init firmware pointer for EC SMSC KBC1098/KBC1126 at build timeBill XIE
According to util/kbc1126/README.md, for these ECs to work, the address and size of their two firmware should be written to $s-0x100` (`$s` means the image size, done with kbc1126_ec_insert), which means that every existing section (especially those used to store code) should not overlap this address, otherwise the bootblock will get damaged when inserting firmwares of the EC. In this commit, ecfw_ptr is a structure initialized at build time according to CONFIG_KBC1126_FW1_OFFSET and CONFIG_KBC1126_FW2_OFFSET (to do so, they should be redefined as hex), and linked to CONFIG_ECFW_PTR_ADDR within bootblock, so kbc1126_ec_insert is not needed at build time any more. Test passed on Elitebook Folio 9470m. Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Change-Id: I4f0de0c4d7283e630242fbe84a46e0547783c49e Reviewed-on: https://review.coreboot.org/c/coreboot/+/51671 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2021-12-13arch/x86/c_start.S: Remove duplicated "the" in commentsElyes HAOUAS
Change-Id: Ib1be1db6f475ad0e1f34703bfe1257d02b86742c Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60067 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-12-13src/arch/x86/exit_car: Fix regression on x86_64Patrick Rudolph
The commit d023909b "treewide: Disable R_AMD64_32S relocation support" clflush the address stored in _cbmem_top_ptr, which is the same address cbmem_top() returns, instead of clflush _cbmem_top_ptr itself. Fix that by providing the correct address to clflush. Change-Id: If74591e7753cd9c3c097516430a212d416f53e4d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59871 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-11-13Add ENV_STAGE_SUPPORTS_SMP to clean up spinlock stubsKyösti Mälkki
CONFIG(SMP) was an invalid condition to use in cases where one stage requires spinlocks and another one does not. The stage not requiring spinlock still required <smp/spinlock.h> to be implemented with no-op stubs. This reverts commit 037ee4b556 soc/amd/picasso: Add dummy spinlock for psp_verstage Change-Id: Iba52febdeee78294f916775ee9ce8a82d6203570 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59094 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-11-11arch/x86: Refactor the SMBIOS type 17 write functionSubrata Banik
List of changes: 1. Create Module Type macros as per Memory Type (i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation issue due to renaming of existing macros due to scoping the Memory Type. 2. Use dedicated Memory Type and Module type for `Form Factor` and `TypeDetail` conversion using `get_spd_info()` function. 3. Create a new API (convert_form_factor_to_module_type()) for `Form Factor` to 'Module type' conversion as per `Memory Type`. 4. Add new argument as `Memory Type` to smbios_form_factor_to_spd_mod_type() so that it can internally call convert_form_factor_to_module_type() for `Module Type` conversion. 5. Update `test_smbios_form_factor_to_spd_mod_type()` to accommodate different memory types. 6. Skip fixed module type to form factor conversion using DDR2 SPD4 specification (inside dimm_info_fill()). Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx. BUG=b:194659789 TEST=Refer to dmidecode -t 17 output as below: Without this code change: Handle 0x0012, DMI type 17, 40 bytes Memory Device Array Handle: 0x000A Error Information Handle: Not Provided Total Width: 16 bits Data Width: 16 bits Size: 2048 MB Form Factor: Unknown .... With this code change: Handle 0x0012, DMI type 17, 40 bytes Memory Device Array Handle: 0x000A Error Information Handle: Not Provided Total Width: 16 bits Data Width: 16 bits Size: 2048 MB Form Factor: Row Of Chips .... Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-11-10Rename ECAM-specific MMCONF KconfigsShelley Chen
Currently, the MMCONF Kconfigs only support the Enhanced Configuration Access mechanism (ECAM) method for accessing the PCI config address space. Some platforms have a different way of mapping the PCI config space to memory. This patch renames the following configs to make it clear that these configs are ECAM-specific: - NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT - MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT - MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS - MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER - MMCONF_LENGTH --> ECAM_MMCONF_LENGTH Please refer to CB:57861 "Proposed coreboot Changes" for more details. BUG=b:181098581 BRANCH=None TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max Make sure Jenkins verifies that builds on other boards Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-11-09pci_mmio_cfg: Move guard around pci_s_* functions to x86Nico Huber
There is no platform in our tree that requires the PCI MMIO ops but doesn't want the pci_s_* definitions. The only case where we include the `pci_mmio_cfg.h` header but don't want the pci_s_* functions to use MMIO is on older x86 platforms, so move the guard there. Change-Id: Iaeed6ab43ad61b7c0e14572b12bf4ec06b6a26af Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58331 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shelley Chen <shchen@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2021-11-04arch/x86/Makefile: Align VGA_BIOS to 64 bytes when using AMD LPC SPI DMARaul E Rangel
AMD platforms require the SPI contents to be 64 byte aligned in order to use the SPI DMA controller. BUG=b:179699789 TEST=Build guybrush and verify cbfs was invoked with -a 64 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I842c85288acd8f7ac99b127c94b1cf235e264ea2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56579 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-11-04SMBIOS/SCONFIG: Allow devtree-defined Type 41 entriesAngel Pons
Introduce the `smbios_dev_info` devicetree keyword to specify the instance ID and RefDes (Reference Designation) of onboard devices. Example syntax: device pci 1c.0 on # PCIe Port #1 device pci 00.0 on smbios_dev_info 6 end end device pci 1c.1 on # PCIe Port #2 device pci 00.0 on smbios_dev_info 42 "PCIe-PCI Time Machine" end end The `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` Kconfig option enables using this syntax to control the generated Type 41 entries. When this option is enabled, Type 41 entries are only autogenerated for devices with a defined instance ID. This avoids having to keep track of which instance IDs have been used for every device class. Using `smbios_dev_info` when `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` is not enabled will result in a build-time error, as the syntax is meaningless in this case. This is done with preprocessor guards around the Type 41 members in `struct device` and the code which uses the guarded members. Although the preprocessor usage isn't particularly elegant, adjusting the devicetree syntax and/or grammar depending on a Kconfig option is probably even worse. Change-Id: Iecca9ada6ee1000674cb5dd7afd5c309d8e1a64b Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57370 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2021-10-23arch/x86: fix a wrong variable in ioapic_set_max_vectors()Iru Cai
The commit 04a40379b has a wrongly written variable, which sets an IOAPIC register to a wrong value and makes the Linux kernel unable to boot. Tested on HP EliteBook 2760p, the kernel boots after this patch. Change-Id: Ifda7bb61a431dbf9c2df2f738aa806dd6d8097b8 Signed-off-by: Iru Cai <mytbk920423@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58558 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-10-22arch/x86/ioapic: Allow IOAPIC with only one vectorKyösti Mälkki
Remove the test for count=0 that leaked from drivers/generic/ioapic implementation. See commit ea2fb8d80 and commit 8cc25d229. Change-Id: I26944b930851fbea160c844ea46e2faa61c9af8e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2021-10-22sb,soc/intel: Set IOAPIC redirection entry countKyösti Mälkki
The number of redirection table entries (aka interrupt vectors) inside an I/O APIC may depend of the SKU, with the related register being of type read/write-once. Provide support utilities to either lock or set this registers value. Change-Id: I8da869ba390dd821b43032e4ccbc9291c39e6bab Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-10-21arch/x86/smbios: Add support for wake-up type in smbios type 1Tim Chu
Add system wake-up type in smbios type 1 - system information. TESTED=On S9S, can override original value and show expected result using "dmidecode -t 1". Signed-off-by: Tim Chu <Tim.Chu@quantatw.com> Change-Id: If79ba65426f1f18ebb55a0f3ef022bee83c1a93b Reviewed-on: https://review.coreboot.org/c/coreboot/+/58436 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
2021-10-21arch/x86,cpu/x86: Fix 64-bit CPU_INFO_V2 build errorsRaul E Rangel
There are two possible code sections where the cpu_info macros can be included: .code32 and .code64 Doing a `push %eax` while in a .code64 section will result in a compiler error. This macro manually pushes the 32-bit register onto the stack so we can share the code between 32 and 64 bit builds. We also can't implicitly dereference per_cpu_segment_selector because it's a 32-bit address. Trying to do this results in the following: E: Invalid reloc type: 11 E: Illegal use of 32bit sign extended addressing at offset 0x1b2 If we load the address first, then dereference it, we can work around the limitation. With these fixes, 64-bit builds can now use CPU_INFO_V2. BUG=b:179699789 TEST=Boot qemu 64 bit build with CPU_INFO_V2 and 4 CPUs. See AP init work as expected. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I4e72a808c9583bb2d0f697cbbd9cb9c0aa0ea2dc Reviewed-on: https://review.coreboot.org/c/coreboot/+/58232 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-10-19arch/x86: Increase MAX_SMBIOS_SIZETim Wawrzynczak
With the recent addition of SMBIOS table 20, the cbmem area on google/brya0 overflows and ERROR: Increase SMBIOS size SMBIOS tables: 2128 bytes. is seen in the logs. Therefore, double the size of the SMBIOS area from 2 KiB to 4 KiB to accomodate more tables as needed. This happens during ramstage so 2k is not a big deal at this point. Change-Id: I43aa6a88d176e783cc9a4441b35b8d608c4101cd Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58432 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-10-18arch/x86/assembly_entry: Remove cpu_infoRaul E Rangel
Since cpu_info() is no longer required to use threads, we no longer need to initialize it in romstage or earlier. This code was also incomplete since it didn't initialize the %gs segment. BUG=b:179699789 TEST=Boot guybrush to OS Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I615b718e9f035ca68ecca9f57d7f4121db0c83b0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58203 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-10-18arch/x86,cpu/x86,lib/thread: Remove usage of cpu_info from lib/threadRaul E Rangel
We only ever start and execute threads on the BSP. By explicitly checking to see if the CPU is the BSP we can remove the dependency on cpu_info. With this change we can in theory enable threads in all stages. BUG=b:194391185, b:179699789 TEST=Boot guybrush to OS and verify coop multithreading still works Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iea4622d52c36d529e100b7ea55f32c334acfdf3e Reviewed-on: https://review.coreboot.org/c/coreboot/+/58199 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-10-17sb/amd/cimx/sb800: Clear IOAPIC vectors only onceKyösti Mälkki
Change-Id: I640d17cdee2bdaa4fe7049ce66a327b58924bc6f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55288 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2021-10-17drivers/generic/ioapic: Drop enable_virtual_wireKyösti Mälkki
All boards with DRIVERS_GENERIC_IOAPIC select it. Presumably the related configuration of routing IRQ0 when IOAPIC is enabled should be always done to provide i8259 legacy compatibility for payloads. Change-Id: Ie87816271fa63bba892c8615aa5e72ee68f6ba93 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55287 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2021-10-15arch/x86/smbios: Add generation of type 20 tableMatt DeVillier
If available, use data from MEMINFO CBMEM table and saved handles from type 17/19 tables to generate type 20 (Memory Device Mapped Address) SMBIOS table. Windows 10/11 and some other OSes use this table to report the total memory available on a given device. Change-Id: I2574d6209d973a8e7f112eb3ef61f5d26986e47b Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58271 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-10-05arch/x86,cpu/x86: Introduce new method for accessing cpu_infoRaul E Rangel
There is currently a fundamental flaw in the current cpu_info() implementation. It assumes that current stack is CONFIG_STACK_SIZE aligned. This assumption breaks down when performing SMM relocation. The first step in performing SMM relocation is changing the SMBASE. This is accomplished by installing the smmstub at 0x00038000, which is the default SMM entry point. The stub is configured to set up a new stack with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point of smm_do_relocation located in RAMSTAGE RAM. This means that when smm_do_relocation is executed, it is running in SMM with a different sized stack. When cpu_info() gets called it will be using CONFIG_STACK_SIZE to calculate the location of the cpu_info struct. This results in reading random memory. Since cpu_info() has to run in multiple environments, we can't use a compile time constant to locate the cpu_info struct. This CL introduces a new way of locating cpu_info. It uses a per-cpu segment descriptor that points to a per-cpu segment that is allocated on the stack. By using a segment descriptor to point to the per-cpu data, we no longer need to calculate the location of the cpu_info struct. This has the following advantages: * Stacks no longer need to be CONFIG_STACK_SIZE aligned. * Accessing an unconfigured segment will result in an exception. This ensures no one can call cpu_info() from an unsupported environment. * Segment selectors are cleared when entering SMM and restored when leaving SMM. * There is a 1:1 mapping between cpu and cpu_info. When using COOP_MULTITASKING, a new cpu_info is currently allocated at the top of each thread's stack. This no longer needs to happen. This CL guards most of the code with CONFIG(CPU_INFO_V2). I did this so reviewers can feel more comfortable knowing most of the CL is a no-op. I would eventually like to remove most of the guards though. This CL does not touch the LEGACY_SMP_INIT code path. I don't have any way of testing it. The %gs segment was chosen over the %fs segment because it's what the linux kernel uses for per-cpu data in x86_64 mode. BUG=b:194391185, b:179699789 TEST=Boot guybrush with CPU_INFO_V2 and verify BSP and APs have correct %gs segment. Verify cpu_info looks sane. Verify booting to the OS works correctly with COOP_MULTITASKING enabled. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I79dce9597cb784acb39a96897fb3c2f2973bfd98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57627 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Peers <epeers@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-10-05src/acpi to src/lib: Fix spelling errorsMartin Roth
These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-29arch/x86,cpu/x86: Disable the %gs and %fs segmentsRaul E Rangel
The %fs and %gs segment are typically used to implement thread local storage or cpu local storage. We don't currently use these in coreboot, so there is no reason to map them. By setting the segment index to 0, it disables the segment. If an instruction tries to read from one of these segments an exception will be raised. The end goal is to make cpu_info() use the %gs segment. This will remove the stack alignment requirements and fix smm_do_relocation. BUG=b:194391185, b:179699789 TEST=Boot guybrush to OS Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iaa376e562acc6bd1dfffb7a23bdec82aa474c1d5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57860 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Peers <epeers@google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-09-28arch/x86: Make sure compiler knows we're stopping in hlt()Martin Roth
Currently, static analyzers don't recognize that hlt() doesn't return, so they show errors like uninitialized variables assuming that it does return. This takes care of that problem. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ia2325700b10fe1f89d749edfe5aee72b47d02f2e Reviewed-on: https://review.coreboot.org/c/coreboot/+/56978 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-09-27arch/x86,cpu/x86: Move cpu_info initialization instructions into macroRaul E Rangel
This will help reduce duplication and make it easier to add new members to the cpu_info struct. BUG=b:194391185, b:179699789 TEST=Compare assembly of romstage and ramstage before and after Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I31f264f4bb8b605fa3cb3bfff0d9bf79224072aa Reviewed-on: https://review.coreboot.org/c/coreboot/+/57859 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-09-13arch/x86/boot: Add missing includeRaul E Rangel
This file uses the asmlinkage macro. BUG=b:179699789 TEST=build guybrush Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Id5b73c174aa946b8205b4172609729b0548cbd8c Reviewed-on: https://review.coreboot.org/c/coreboot/+/57567 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-09-13SMBIOS: Skip `get_smbios_data` for disabled devicesAngel Pons
If a device is disabled, do not call the `get_smbios_data` code. Change-Id: I8960f869e0864f7c82d5fe507f96b62cbd045569 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57458 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-09-13SMBIOS: Allow skipping default SMBIOS generationAngel Pons
The call to the `get_smbios_data` device operation is followed by calls to unconditional default functions, which lacks flexibility. Instead, have devices that implement `get_smbios_data` call these default functions as needed. Most `get_smbios_data` implementations are in mainboard code, and are bound to the root device. The default functions only operate with PCI devices because of the `dev->path.type != DEVICE_PATH_PCI` checks, so calling these functions for non-PCI devices is unnecessary. QEMU also implements `get_smbios_data` but binds it to the domain device, which isn't PCI either. Change-Id: Iefbf072b1203d04a98c9d26a30f22cfebe769eb4 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57366 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-09-05smbios.c: Rename two local functionsAngel Pons
Rename two functions that have `walk` in their name but do not perform any walk. The new names are derived from the comments just above these functions' definitions. Also, remove these now-redundant comments. Change-Id: I380a5b60b3f4e820e8f6d6f960826de97c0446be Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57361 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-03arch/x86: Update debug message to callout the reason for failureSubrata Banik
This patch updates debug message to specifically the case when SMBIOS table 7 write would abort due to either `unknown` CPU or CPU `doesn't have support for deterministic cache cpuid leaf`. Change-Id: I288593b3f78ab858bf66c689e7cfb6ba2ff746d0 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57337 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-09-03arch/x86: Check unsupported CPU type while writing to SMBIOS table 7Subrata Banik
Don't attempt to fill the SMBIOS table if the CPU doesn't support deterministic cache CPUID. TEST=Able to fix the hang issue seen on ASRock E350M1 with commit hash e2b5fee. Change-Id: Id65dc963e235f7080370a32cf69bcc4bee94d28f Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57306 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-03arch/x86: Skip returning default leaf value as `0`Subrata Banik
`cpu_get_cache_info_leaf()` function is responsible to report leaf value for CPU that have support for deterministic cache cpuid. As per available datasheets from AMD and Intel the supported CPUID leafs are 0x8000_001d for AMD and 0x04 for Intel. Hence, this CL skips returning default leaf value as `0`. TEST=Verified fixes: e2b5fee3b006 (arch/x86: smbios write 7 table using deterministic cache functions) hang issue on ASRock E350M1. Change-Id: Iee33b39298e7821ac5280d998172b58a70c8715b Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57305 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-08-31arch/x86: Implement cpu_info in C codeArthur Heymans
Change-Id: Ic7396b8429e29739e18a189dacea3a76e571cd58 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57049 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-08-31smbios.c: Move function definition near call-siteAngel Pons
The `smbios_get_device_type_from_dev()` function is only called once from the `smbios_walk_device_tree_type41()` function. Put the former function's definition above the latter function's, instead of having them a thousand lines apart. Change-Id: Idc6175324ca8a14841eaf7d6904712efb75f2d26 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57205 Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-08-11arch/x86: smbios write 7 table using deterministic cache functionsSubrata Banik
This patch makes use of deterministic cache helper functions, for example: cpu_get_cache_type(), cpu_get_cache_level() etc. helper functions from arch/x86/cpu_common.c file. Also, changed argument for get_number_of_caches() function that receives cpu_get_max_cache_share() data directly. Drop unused variables partitions, cache_line_size and number_of_sets as struct cpu_cache_info.size would provide the cache size directly. TEST=Able to dump SMBIOS Table 7 with this CL, no changes seen in output. Getting SMBIOS data from sysfs. SMBIOS 3.0 present. Handle 0x0005, DMI type 7, 27 bytes Cache Information Socket Designation: CACHE1 Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Unknown Location: Internal Installed Size: 288 kB Maximum Size: 288 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Data Associativity: 12-way Set-associative Handle 0x0006, DMI type 7, 27 bytes Cache Information Socket Designation: CACHE1 Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Unknown Location: Internal Installed Size: 192 kB Maximum Size: 192 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Instruction Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 27 bytes Cache Information Socket Designation: CACHE2 Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Unknown Location: Internal Installed Size: 1280 kB Maximum Size: 1280 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Unified Associativity: Unknown Handle 0x0008, DMI type 7, 27 bytes Cache Information Socket Designation: CACHE3 Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Unknown Location: Internal Installed Size: 12288 kB Maximum Size: 12288 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Unknown System Type: Unified Associativity: 12-way Set-associative Change-Id: Iedbd3b745629dea57c3ad6b0d187eab2bcc3f7d3 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56121 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-08-11arch/x86: Helper functions to get deterministic cache parametersSubrata Banik
This patch creates helper function that internally detects the CPU type (AMD or Intel) and pick the leaf to send CPUID instruction with different cache level to retrieve deterministic cache parameters. Lists of helper functions generated as part of this CL : 1. cpu_check_deterministic_cache_cpuid_supported => if CPU has support for deterministic cache using CPUID instruction. 2. cpu_get_cache_ways_assoc_info => Get cache ways for associativity. 3. cpu_get_cache_type => Get cache type. 4. cpu_get_cache_level => Get cache level. 5. cpu_get_cache_phy_partition_info => Get cache physical partitions. 6. cpu_get_cache_line_size => Get cache line size. 7. cpu_get_cache_sets => Get cache number of sets. 8. cpu_is_cache_full_assoc => Check if cache is fully associative. 9. cpu_get_max_cache_share => Cores are sharing this cache. 10. get_cache_size => Calculate the cache size. 11. fill_cpu_cache_info => Fill cpu_cache_info structure. Change-Id: I0dd701fb47460092448b64c7fa2162f762bf3095 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55965 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-07-29arch/x86/thread: Add #error when compiling for x86_64Raul E Rangel
The x86 thread code is all x86_32 specific. It needs to be updated to work with 64 bit. For now just throw an error when compiling. BUG=b:179699789 TEST=none Suggested-by: Furquan Shaikh <furquan@google.com> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I96187ad84bdec40c6883748afa41e217bc389b79 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56571 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-07-26arch/x86,lib/thread: Enable thread support in romstageRaul E Rangel
This change does the following: * Pushes the cpu_info struct into the top of the stack (just like c_start.S). This is required so the cpu_info function works correctly. * Adds the thread.c to the romstage build. I only enabled this for romstage since I haven't done any tests in other stages, but in theory it should work for other stages. BUG=b:179699789 TEST=Boot guybrush with threads enabled in romstage Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I8e32e1c54dea0d0c85dd6d6753147099aa54b9b5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56494 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-07-26arch/x86,cpu/x86/mp_init: Switch cpu_info index type to size_tRaul E Rangel
The alignment for `struct cpu_info` is wrong on x86_64. c_start.S uses the `push` instruction when setting up the cpu_info struct. This instruction will push 8 bytes but `unsigned int` is 4 bytes. By making it a `size_t` we get the correct size for both x86_32 and x86_64. BUG=b:179699789 TEST=Boot guybrush to the OS Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I8ef311aaa8333ccf8a5b3f1f0e852bb26777671c Reviewed-on: https://review.coreboot.org/c/coreboot/+/56573 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-07-26lib/thread,arch/x86: Move thread stacks into C bssRaul E Rangel
There is no reason this needs to be done in asm. It also allows different stages to use threads. If threads are no used in a specific stage, the compiler will garbage collect the space. BUG=b:179699789 TEST=Boot guybrush to the OS Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ib5a84a62fdc75db8ef0358ae16ff69c20cbafd5f Reviewed-on: https://review.coreboot.org/c/coreboot/+/56531 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-18x86/smp/spinlock: Disable thread coop when taking spinlockRaul E Rangel
Switching threads while holding a spinlock can lead to a deadlock. This happens if you have two thread trying to print to the serial console because the uart code uses udelay. BUG=b:179699789 TEST=Boot guybrush and no longer see a deadlock when printing to console from a second thread. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I1b929070b7f175965d4f37be693462fef26be052 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56320 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-07-07arch/x86: Save resume vector to stack in x86_64 modeIru Cai
In x86_64, the first function parameter is passed in rdi register, and the 32-bit code after exiting long mode reads the resume vector in 4(%esp), so it's needed to save the resume vector from rdi to 4(%rsp). Also note that the function attribute "regparm" only works on x86-32 targets according to the GCC manual, so "asmlinkage" doesn't change the ABI of an x86_64 function. Tested on HP EliteBook 2560p. The laptop can resume from S3 in x86_64 mode after this change. Change-Id: I45f2678071b2511c0af5dce9d9b73ac70dfd7252 Signed-off-by: Iru Cai <mytbk920423@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55947 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-06arch/x86: Use ENV_X86_64 instead of _x86_64_Patrick Rudolph
Tested on Intel Sandybridge x86_64 and x86_32. Change-Id: I152483d24af0512c0ee4fbbe8931b7312e487ac6 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44867 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-07-02arch/x86: Add X86_CUSTOM_BOOTMEDIARaul E Rangel
In order to disable X86_TOP4G_BOOTMEDIA_MAP it requires the definition to be overridden. This makes it a little less ergonomic to use. Instead introduce the inverse option that can be selected. I chose to leave X86_TOP4G_BOOTMEDIA_MAP since it keeps the Makefiles simple. BUG=b:179699789 TEST=none Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I65bbc118bde88687a7d7749c87acf1cbdc56a269 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55853 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2021-07-02src: Consolidate x86_64 support KconfigAngel Pons
Introduce `USE_EXP_X86_64_SUPPORT` in `src/arch/x86/Kconfig` and guard it with `HAVE_EXP_X86_64_SUPPORT`. Replace the per-CPU implementations of the same functionality with the newly-added Kconfig options. Update documentation and the config file for QEMU accordingly. Change-Id: I550216fd2a8323342d6b605306b0b95ffd5dcd1c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55760 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2021-07-02src: Introduce `ARCH_ALL_STAGES_X86`Angel Pons
Introduce the `ARCH_ALL_STAGES_X86` Kconfig symbol to automatically select the per-stage arch options. Subsequent commits will leverage this to allow choosing between 32-bit and 64-bit coreboot where all stages are x86. AMD Picasso and AMD Cezanne are the only exceptions to this rule: they disable `ARCH_ALL_STAGES_X86` and explicitly set the per-stage arch options accordingly. Change-Id: Ia2ddbae8c0dfb5301352d725032f6ebd370428c9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55759 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2021-07-01SMBIOS: Introduce `smbios_full_table_len` functionAngel Pons
Introduce the `smbios_full_table_len` function to consolidate table length calculation. The case where the length of a table equals the length of the structure happens when a table has no strings. Change-Id: Ibc60075e82eb66b5d0b7132b16da000b153413f9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55909 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2021-07-01arch/x86/smbios.c Move calculation next to usageAngel Pons
Change-Id: I949da86605e76b186ef2fdbfbc112b71544b694a Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55908 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-07-01SMBIOS: Introduce `smbios_carve_table` functionAngel Pons
Factor out some boilerplate code into a helper `smbios_carve_table` function, which zeroes out the table memory and fills in the header fields common to all tables. Change-Id: Iece2f64f9151d3c79813f6264dfb3a92d98c2035 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55907 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2021-07-01SMBIOS: Avoid `sizeof` on struct typeAngel Pons
Where applicable, use the size of the associated variable. Change-Id: Ibbac2a82893232a6f87182a6a965b84a599d633e Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55904 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2021-07-01arch/x86/smbios.c: Trim some `len` variablesAngel Pons
Reduce the scope or remove some `len` variables. This is done to ease replacing `sizeof` on struct types in a follow-up commit, by ensuring that all to-be-replaced appearances follow the variable declarations. Change-Id: Ied38fcaf87ef5b1e4f93076b4ba2898ad1f98a72 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55903 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-06-30src: Move `select ARCH_X86` to platformsAngel Pons
To generalise the choice of 32-bit or 64-bit coreboot on x86 hardware, have platforms select `ARCH_X86` directly instead of through per-stage Kconfig options, effectively reversing the dependency order. Change-Id: If15436817ba664398055e9efc6c7c656de3bf3e4 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55758 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2021-06-24arch/x86/bootblock.ld: Align the bottom of the bootblock to 64 bytesArthur Heymans
Align the bootblock size to 64 bytes because: - cachelines are often 64 bytes large - Bootguard/CBnT requires a 64 byte alignment Change-Id: I69cdacdd15bfca1b91b6f271f2ff76889969fd91 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55046 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>