summaryrefslogtreecommitdiff
path: root/src/arch/x86
AgeCommit message (Collapse)Author
2024-07-10cbmem_top: Change the return value to uintptr_tElyes Haouas
Change-Id: Ib757c0548f6f643747ba8d70228b3d6dfa5182cd Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82752 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Jakub Czapiga <czapiga@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-06-27arch/x86/mpspec: Use uintptr_t for mpc_apicaddrElyes Haouas
Change-Id: I6cc2b3947a2c79e8962985e035e7cc74c2deb307 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83215 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-06-10arch/x86: Clarify help text for 64-bit supportSubrata Banik
The word "experimental" has been removed from the help text for HAVE_X86_64_SUPPORT Kconfig. This is because the x86_64 architecture has now been officially tested and enabled for several x86 SoC platforms. This work will provide us with the foundation we need to begin working with Intel's next-generation SoC platform (which requires to support 64-bit mode of booting by default). Therefore, we can now remove the word "experimental" from the "HAVE_X86_64_SUPPORT" Kconfig help text. TEST=Able to build and boot google/rex64 in 64-bit mode to ChromeOS. Change-Id: Ibd629f4e2722f3cbabbe297d4481790c9fa9226a Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83009 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-06-01tree: Add some SMBIOS_PROCESSOR_FAMILY macrosElyes Haouas
Change-Id: Ibe551a4c83f416ba30326077aa165818cf79c1fd Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82648 Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-29tree: Remove unused <string.h>Elyes Haouas
Change-Id: I9ed1a82fcd3fc29124ddc406592bd45dc84d4628 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82666 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Yidi Lin <yidilin@google.com>
2024-05-29tree: Use <stdio.h> for snprintfElyes Haouas
<stdio.h> header is used for input/output operations (such as printf, scanf, fopen, etc.). Although some input/output functions can manipulate strings, they do not need to directly include <string.h> because they are declared independently. Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665 Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-28tree: Add smbios_processor_typeElyes Haouas
Change-Id: I46f799ad255993ac42dab11b5c1d2608daa52b42 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82645 Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-27acpi/acpi_apic;arch/x86/acpi: better document ACPI_NO_PCAT_8259 caseFelix Held
Both acpi_create_madt_sci_override and acpi_sci_int have special handling for the ACPI_NO_PCAT_8259 case, but those cases weren't exactly obvious, so add a comment with the reason for that. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia6dcf59d5ab9226c61e9c4af95a73a07771b71d1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82643 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-14arch/x86: Remove unused `protected_mode_jump` APISubrata Banik
This patch removes all instances of the `protected_mode_jump` API and its associated header file. The API is no longer used by any code within the tree. BUG=b:332759882 TEST=Built and booted 64-bit coreboot with 32-bit payload successfully. Change-Id: I3eb31b09c92512338ccc540f60289960bd6bf439 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82372 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-14x86: Switch to protected_mode_call_1arg for correct argument passingSubrata Banik
The payload execution process has been updated to utilize protected_mode_call_1arg in order to guarantee proper handling of function parameters. The previous use of protected_mode_jump with a "jmp" instruction did not allow for proper stack setup for argument passing, as the calling convention was not aligned with the System V ABI calling convention. This patch ensures that calling into the libpayload entry point using protected mode is now aligned with the System V ABI calling convention. This resolves an issue where retrieving the "pointer to coreboot tables" from within the libpayload entry point was failing due to incorrect argument passing. BUG=b:332759882 TEST=Built and booted 64-bit coreboot with 32-bit payload successfully. Change-Id: Ibd522544ad1e9deed6a11015b0c0e95265bda8eb Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82294 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
2024-04-17arch/x86: Prevent .text/.init overlap with older linkersSubrata Banik
Add Kconfig option `X86_BOOTBLOCK_EXTRA_PROGRAM_SZ` to reserve extra space, avoiding overlap between .text and .init sections when using older linkers (binutils 2.3x). Default is 1024 bytes (1 KiB) for ChromeOS, 0 otherwise. BUG=b:332445618 TEST=Built and booted google/rex (32-bit/64-bit). Change-Id: I019bf6896d84b2a84dff6f22323f0f446c0740b5 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81886 Reviewed-by: Dinesh Gehlot <digehlot@google.com> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2024-04-12tree: Drop duplicated <device/{path,resource}.h>Elyes Haouas
<device/device.h> is supposed to provide <device/{path,resource}.h> Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-09tree: Drop unused <console/console.h>Elyes Haouas
Change-Id: Ib1a8fc50217c84e835080c70269ff50fc001392c Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81811 Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm> Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-08lib/program.ld: Account for large code model sectionsArthur Heymans
Starting with version 18 LLVM puts code and data generated with -ffunction-section -mcmodel=large inside sections with an 'l' prefix. Change-Id: Ib755673dfa9e71172bbef0a5aec075154c89a97b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81675 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-04arch/x86/bootblock.ld: Account for the .data sectionArthur Heymans
commit b7832de026 (x86: Add .data section support for pre-memory stages) added a data section to the bootblock. This needs to be accounted for in the linker script. Change-Id: I39abe499e5e9edbdacb1697c0a0fc347af3ef9c4 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81434 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-01Kconfig: Make GBD_STUB and long mode mutually exclusiveArthur Heymans
GDB debugging is not implemented with x86 long mode. Change-Id: Icaf7d0763829d5badf73d38bb8fc3d36cfe18964 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81379 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Eric Lai <ericllai@google.com>
2024-03-30arch/x86: Remove blank lines before '}' and after '{'Elyes Haouas
Change-Id: I1bb4a052a4e74850660944b687c21e817eb437b2 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81453 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-03-28cpu/x86/Kconfig: Mark 64bit support as stableArthur Heymans
With SMM holding page tables itself, we can consider SMM support stable and safe enough for general use. Also update the respective documentation. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ifcf0a1a5097a2d7c064bb709ec0b09ebee13a47d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80338 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-03-28cpu/x86: Link page tables in stage if possibleArthur Heymans
When switching back and forth between 32 to 64 bit mode, for example to call a 32-bits FSP or to call the payload, new page tables in the respective stage will be linked. The advantages of this approach are: - No need to determine a good place for page tables in CBFS that does not overlap. - Works with non memory mapped flash (however all coreboot targets currently do support this) - If later stages can use their own page tables which fits better with the vboot RO/RW flow A disadvantage is that it increases the stage size. This could be improved upon by using 1G pages and generating the pages at runtime. Note: qemu cannot have the page tables in the RO boot medium and needs to relocate them at runtime. This is why keeping the existing code with page tables in CBFS is done for now. TEST: Booted to payload on google/vilbox and qemu/q35 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ied54b66b930187cba5fbc578a81ed5859a616562 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80337 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-26arch/x86/bootblock.ld: Align the base of bootblock downwardsArthur Heymans
Instead of using some aritmetics that sometimes works, use the largest alignment necessary (page tables) and align downwards in the linker script. This fixes linking failing when linking in page tables inside the bootblock. This can result in a slight increase in bootblock size of at most 4096 - 512 bytes. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I78c6ba6e250ded3f04b12cd0c20b18cb653a1506 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80346 Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-21arch/x86: Fix typo for macro CPUID_FEATURE_HTTJincheng Li
Change-Id: I9b29233e75483cda6bf7723cf79632f6b04233b0 Signed-off-by: Jincheng Li <jincheng.li@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81260 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
2024-03-19arch/x86: Directly return result of `IS_POWER_OF_2()`Paul Menzel
Change-Id: I314d726deaed30e69121126ba6834e4c7cafd090 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81299 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-03-17arch/x86: Add API to check if cache sets are power-of-twoSubrata Banik
Introduce a function to determine whether the number of cache sets is a power of two. This aligns with common cache design practices that favor power-of-two counts for efficient indexing and addressing. BUG=b:306677879 BRANCH=firmware-rex-15709.B TEST=Verified functionality on google/ovis and google/rex (including a non-power-of-two Ovis configuration). Change-Id: I819e0d1aeb4c1dbe1cdf3115b2e172588a6e8da5 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81268 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-15treewide: Move stdlib.h to commonlibMaximilian Brune
This patch moves commonlib/stdlib.h -> commonlib/bsd/stdlib.h, since all code is BSD licensed anyway. It also moves some code from libpayloads stdlib.h to commonlib/bsd/stdlib.h so that it can be shared with coreboot. This is useful for a subsequent commit that adds devicetree.c into commonlib. Also we don't support DMA on arm platforms in coreboot (only libpayload) therefore `dma_malloc()` has been removed and `dma_coherent()` has been moved to architecture specific functions. Any architecture that tries to use `dma_coherent()` now will get a compile time error. In order to not break current platforms like mb/google/herobrine which make use of the commonlib/storage/sdhci.c controller which in turn uses `dma_coherent` a stub has been added to arch/arm64/dma.c. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I3a7ab0d1ddcc7ce9af121a61b4d4eafc9e563a8a Reviewed-on: https://review.coreboot.org/c/coreboot/+/77969 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-03-05drivers/intel/fsp: Work around multi-socket Xeon-SP pipe init bugArthur Heymans
Starting with Intel CPX there is a bug in the reference code during the Pipe init. This code synchronises the CAR between sockets in FSP-M. This code implicitly assumes that the FSP heap is right above the RC heap, where both of them are located at the bottom part of CAR. Work around this issue by making that implicit assumption done in FSP explicit in the coreboot linker script and allocation. TEST=intel/archercity CRB Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Shuo Liu <shuo.liu@intel.com> Change-Id: I38a4f4b7470556e528a1672044c31f8bd92887d4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80579 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Shuo Liu <shuo.liu@intel.com>
2024-03-04arch/x86/Kconfig: Deduplicate ARCH_SUPPORTS_CLANG selectionElyes Haouas
Change-Id: Iced69e0bce345748a43eb1c14bf17a683e26ba60 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81020 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2024-02-27Kconfig: Make the SEPARATE_ROMSTAGE default configurable in other filesArthur Heymans
This also sets a good default in arch and vboot to have a separate romstage when it makes sense. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I09ab5f8c79917bf93c9d5c9dfd157c652478b186 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80580 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-23arch/x86/ioapic: use uintptr_t for IOAPIC base addressFelix Held
Use uintptr_t for the IOAPIC base parameter of the various IOAPIC- related functions to avoid needing type casts in the callers. This also allows dropping the VIO_APIC_VADDR define and consistently use the IO_APIC_ADDR define instead. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I912943e923ff092708e90138caa5e1daf269a69f Reviewed-on: https://review.coreboot.org/c/coreboot/+/80358 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-02-07arch/x86/mpspec: reduce scope of smp_write_ioapicFelix Held
smp_write_ioapic is only called from smp_write_ioapic_from_hw within the same compilation unit, so reduce its scope by making it a static function. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6a1bbfd50ae9d6c8ab18f478ae9bae3f8bf5e10d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80357 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-06arch/x86/ioapic: always write IOAPIC ID in set_ioapic_idFelix Held
Back in the days of the APIC bus, the IOAPIC IDs mustn't overlap with the LAPIC IDs (0 to CONFIG_MAX_CPUS - 1), but since the IOAPIC and LAPIC nowadays talk to each other via the system bus, an IOAPIC ID of 0 is valid. When set_ioapic_id gets called with an IOAPIC ID of 0, it skipped writing the IOAPIC ID to the corresponding IOAPIC register, so the code was relying of the register having the expected default value of the IOAPIC IO 0 for things to work as expected. The case of the IOAPIC ID being 0 is the most common case in coreboot, since that's what register_new_ioapic_gsi0 will end up doing. Fix this issue by not making the io_apic_write call conditional on ioapic_id being non-zero. The only southbridge that doesn't call register_new_ioapic_gsi0, calls set_ioapic_id with the IOAPIC ID 2 for which this won't cause any changes in behavior. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic8538f82a6b10f16eeb228669db197dc8e326ffd Reviewed-on: https://review.coreboot.org/c/coreboot/+/80330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-02lib: Move IP checksum to commonlibJulius Werner
This patch moves the IP checksum algorithm into commonlib to prepare for it being shared with libpayload. The current implementation is ancient and pretty hard to read (and does some unnecessary questionable things like the type-punning stuff which leads to suboptimal code generation), so this reimplements it from scratch (that also helps with the licensing). This algorithm is prepared to take in a pre-calculated "wide" checksum in a machine-register-sized data type which is then narrowed down to 16 bits (see RFC 1071 for why that's valid). This isn't used yet (and the code will get optimized out), but will be used later in this patch series for architecture-specific optimization. Change-Id: Ic04c714c00439a17fc04a8a6e730cc2aa19b8e68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80251 Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <czapiga@google.com>
2024-01-31device/device.h: Rename busses for clarityArthur Heymans
This renames bus to upstream and link_list to downstream. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-01-29device/device.h: Drop multiple linksArthur Heymans
Multiple links are unused throughout the tree and make the code more confusing as an iteration over all busses is needed to get downstream devices. This also not done consistently e.g. the allocator does not care about multiple links on busses. A better way of dealing multiple links below a device is to feature dummy devices with each their respective bus. This drops the sconfig capability to declare the same device multiple times which was previously used to declare multiple links. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jincheng Li <jincheng.li@intel.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2024-01-24acpi,arch,commonlib: Rename Makefiles from .inc to .mkMartin Roth
The .inc suffix is confusing to various tools as it's not specific to Makefiles. This means that editors don't recognize the files, and don't open them with highlighting and any other specific editor functionality. This issue is also seen in the release notes generation script where Makefiles get renamed before running cloc. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ice5dadd3eaadfa9962225520a3a75b05b44518ca Reviewed-on: https://review.coreboot.org/c/coreboot/+/80066 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2024-01-17arch/x86/mpspec: turn compile-time check into Kconfig dependencyFelix Held
Instead of checking if there is more than one PCI segment group and erroring out in that case during the build, add this requirement as a dependency to the GENERATE_MP_TABLE Kconfig option. The mpspec.c source file only gets included in the build if GENERATE_MP_TABLE is selected. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Martin Roth <gaumless@gmail.com> Change-Id: Ie532a401ad0161890d0fb4ca2889af022d5f6b47 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79994 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-01-16device: Add support for multiple PCI segment groupsFelix Held
Add initial support for multiple PCI segment groups. Instead of modifying secondary in the bus struct introduce a new segment_group struct element and keep existing common code. Since all platforms currently only use 1 segment this is not a functional change. On platforms that support more than 1 segment the segment has to be set when creating the PCI domain. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ied3313c41896362dd989ee2ab1b1bcdced840aa8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79927 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-01-11arch/x86/include/smm_call: improve documentation of call_smmFelix Held
Since the inline assembly code in call_smm doesn't make it exactly obvious how this function to call the APMC SMI handler works in detail, add a more detailed explanation as comment. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3566af191492ce00a3033335ff80e01c33e98e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79834 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-11arch/x86/include/smm_call: use pm_acpi_smi_cmd_portFelix Held
Use pm_acpi_smi_cmd_port() to get the APMC trigger IO port instead of using the hard-coded APM_CNT define. This makes sure that the correct APMC IO port will be used even when a system doesn't use the default APM IO port. TEST=SMMSTORE V2 still works with the EDK2 payload on Careena Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icb79c91cfcd75db760bd80cff7f3d0400d1f16cd Reviewed-on: https://review.coreboot.org/c/coreboot/+/79568 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-11arch/x86/c_start.S: Add proper x86_64 codePatrick Rudolph
Don't truncate upper bits in assembly code and thus allow loading of ramstage above 4GiB. Tested on qemu with cbmem_top set to TOUUD. Change-Id: Ifc9b45f69d0b7534b2faacaad0d099cef2667478 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Co-authored-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59874 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-10arch/x86/include: rename smm.h to smm_call.hFelix Held
Rename smm.h to smm_call.h to make including this file look less ambiguous. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia907ad92459e835feeddf7eb4743a38f99549179 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79833 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-10arch/x86/include/smm: use inline asm from drivers/smmstore/ramstageFelix Held
The call_smm function is currently unused and the inline assembly code for more or less the same functionality in drivers/smmstore/ramstage is both a bit easier to understand since it uses the register names in the 'outb' instruction instead of positional arguments, and also tells the compiler that this piece of code might change global memory. Having too much in the clobber list might only have some performance impact, which should however be negligible compared to the SMI handler being called, while missing something in the clobber list might cause hard to debug problems. This is a preparation to make drivers/smmstore/ramstage use call_smm instead of having its own inline assembly implementation for this. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I73837cab75429014897486b38a5c56f93a850f96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79827 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-08src/arch/x86/exit_car: Add proper x86_64 codePatrick Rudolph
Don't truncate upper bits in assembly code and thus allow loading of postcar stage above 4GiB. Tested on qemu with cbmem_top set to TOUUD. Change-Id: I42d1086f1220e44076ccf613244fc3c6d804805b Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-08arch/x86/acpi: call pm_acpi_smi_cmd_port to get APMC SMI IO portFelix Held
Instead of hard-coding the APMC SMI command IO port in the FADT, call pm_acpi_smi_cmd_port() to get the APMC SMI command IO port. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I731c780bc6db7e7fd59688340bab1da86fc93c11 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79565 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-08arch/x86: introduce HAVE_CONFIGURABLE_APMC_SMI_PORTFelix Held
Introduce the HAVE_CONFIGURABLE_APMC_SMI_PORT Kconfig option that when not selected will result in a default implementation of pm_acpi_smi_cmd_port to be included in the build that returns APM_CNT. SoCs that provide their own pm_acpi_smi_cmd_port implementation, need to select this Kconfig option. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iaceb61b0f2a630d7afe2e0780b6a2a9806ea62f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79566 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
2024-01-05arch/x86/include/mode_switch: Add more wrapper functionsPatrick Rudolph
Add a protected mode wrapper function that takes three arguments. This is already supported by the called assembly code. Change-Id: Ia8c91eebae17e4ca27e391454c2d130a71c4c9f3 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79756 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-03cpu/x86/64bit/mode_switch: Simplify assembly codePatrick Rudolph
Drop the first argument specifying the number of arguments pushed to the stack. Instead always push the 3 arguments to stack and use the first one as function pointer to call while in protected mode. While on it add more comments and simplify register restore code. Tested: - On qemu can call x86_32 function and pass argument and return value. - Booted Lenovo X220 in x86_64 mode using x86_32 MRC. Change-Id: I30809453a1800ba3c0df60acd7eca778841c520f Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79752 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-12-27arch/x86/car.ld: Use VB2_FIRMWARE_WORKBUF_RECOMMENDED_SIZE constantJeremy Compostella
Use the `VB2_FIRMWARE_WORKBUF_RECOMMENDED_SIZE' constant defined by the vboot project instead of hard-coding the buffer size. Change-Id: I6039fc7cf2439535ca88663806bdcf99ad5089b0 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79288 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2023-12-22x86: Separate CPU and SoC physical address sizeJeremy Compostella
The physical address size of the System-on-Chip (SoC) can be different from the CPU physical address size. These two different physical address sizes should be used for settings of their respective field. For instance, the physical address size related to the CPU should be used for MTRR programming while the physical address size of the SoC should be used for MMIO resource allocation. Typically, on Meteor Lake, the CPUs physical address size is 46 if TME is disabled and 42 if TME is enabled but Meteor Lake SoC physical address size is always 42. As a result, MTRRs should reflect the TME status while coreboot MMIO resource allocator should always use 42 bits. This commit introduces `SOC_PHYSICAL_ADDRESS_WIDTH' Kconfig to set the physical address size of the SoC for those SoCs. BUG=b:314886709 TEST=MTRR are aligned between coreboot and FSP Change-Id: Icb76242718581357e5c62c2465690cf489cb1375 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79665 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-29arch/x86/Makefile.inc: Do not pass CPPFLAGS to linkerSrinivas Hegde
We seem to be passing CPPFLAGS to linker in x86 arch ramstage. This is superflous as these are only meant to be compiler flags and should not be passed to the linker. Change-Id: Ia3cd51be6be252aa796191cf0d2cd91d393c8878 Signed-off-by: Srinivas Hegde <srinivashegde@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79218 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2023-11-09Allow to build romstage sources inside the bootblockArthur Heymans
Having a separate romstage is only desirable: - with advanced setups like vboot or normal/fallback - boot medium is slow at startup (some ARM SOCs) - bootblock is limited in size (Intel APL 32K) When this is not the case there is no need for the extra complexity that romstage brings. Including the romstage sources inside the bootblock substantially reduces the total code footprint. Often the resulting code is 10-20k smaller. This is controlled via a Kconfig option. TESTED: works on qemu x86, arm and aarch64 with and without VBOOT. Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-11-01arch/x86/memcpy.c: Optimize code for 64bitArthur Heymans
In 64bit movsq is available which moves memory in chunks of 8 bytes rather than 4 bytes. Linux uses the same code. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I65f178d2ed3aae54b0c1ce739c2b4af8738b9fcc Reviewed-on: https://review.coreboot.org/c/coreboot/+/78646 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Eric Lai <ericllai@google.com>
2023-10-20x86: Add ramstage CBFS cache scratchpad supportJeremy Compostella
Having a CBFS cache scratchpad offers a generic way to decompress CBFS files through the cbfs_map() function without having to reserve a per-file specific memory region. This commit introduces the x86 `RAMSTAGE_CBFS_CACHE_SIZE' Kconfig to set a ramstage CBFS cache size. A cache size of zero disables the CBFS cache feature. The default size is 16 KB which seems a reasonable minimal value large enough to satisfy basic needs such as the decompression of a small configuration file. This setting can be adjusted depending on the platform needs and capabilities. To support S3 suspend/resume use-case, the CBFS cache memory cannot be released to the operating system. There are two options to meet this requirement: 1. Define a static CBFS cache buffer (located in the .bss section) 2. Create a new CBMEM entry Option #2 seems more powerful but considering that: 1. The CBFS cache is actually not a cache but just a scratch pad designed to be isolated between stages 2. postcar is a very short stage not really needing CBFS cache 3. The static initialization of the `cbfs_cache' global variable (cf. src/lib/cbfs.c) offers a simple and robust design => It is simpler to use a static buffer and limit the support to ramstage. Since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR' Kconfig) define a `_cbfs_cache' region, an extra `POSTRAM_CBFS_CACHE_IN_BSS' Kconfig must be set to enable the use of a static buffer as the CBFS cache scratchpad. TEST=Decompression of vbt.bin in ramstage on rex using cbfs_map() Change-Id: I7fbb1b51cda9f84842992e365b16c5ced1010b89 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77885 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-20x86: Add pre-memory stages CBFS cache scratchpad supportJeremy Compostella
Having a CBFS cache scratchpad offers a generic way to decompress CBFS files through the cbfs_map() function without having to reserve a per-file specific memory region. This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set the pre-memory stages CBFS cache size. A cache size of zero disables the CBFS cache feature. The default value is 16 KB which seems a reasonable minimal value enough to satisfy basic needs such as the decompression of a small configuration file. This setting can be adjusted depending on the platform needs and capabilities. We have set this size to zero for all the platforms without enough space in Cache-As-RAM to accommodate the default size. TEST=Decompression of vbt.bin in romstage on rex using cbfs_map() Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-10-06arch/x86/cpu_common: Add cpu_get_c_substate_supportPatrick Rudolph
Add a function to get the number of substates supported by an Intel CPU C-state. Test: Can read out the supported C-state substates. Change-Id: Ie57e87609ea5d6ec6f37154e8b84f1e9574aa4a9 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78224 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-10-02x86/include/arch/cpuid.h: Fix inline assemblyPatrick Rudolph
In the cpuid helper functions eax is always written to by the cpuid instruction, so add it to the output clobbered list. This prevents GCC from generating code with undefined behaviour when the function is inlined. Test: Verified that the generated assembly is sane and runtime tests showed no "strange" behaviour when calling cpuid functions. Change-Id: I5dc0bb620184a355716b9c8d4206d55554b41ab9 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78192 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-09-29arch/x86/Kconfig: introduce RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORTFelix Held
Since also some AMD CPUs have reserved physical address bits that can't be used as normal address bits, introduce the RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets selected by CPU_INTEL_COMMON, and use the new common option to configure if the specific SoC/CPU code implements get_reserved_phys_addr_bits or if the default of this returning 0 is used instead. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-29*/include/cpu: use unsigned int for number of address bitsFelix Held
The number of physical address bits and reserved address bits shouldn't ever be negative, so change the return type of cpu_phys_address_size, get_reserved_phys_addr_bits, and get_tme_keyid_bits from int to unsigned int. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9e67db6bf0c38f743b50e7273449cc028de13a8c Reviewed-on: https://review.coreboot.org/c/coreboot/+/78072 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-09-26arch/x86/cpu_common: use cpuid_get_max_funcFelix Held
Use cpuid_get_max_func instead of open-coding the same functionality in cpu_check_deterministic_cache_cpuid_supported. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I590f0c840bc62bbd0b5038c5827367d811e30d10 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78108 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-26arch/x86/smbios: fix extended CPUID level check logicFelix Held
Before the cpuid(0x80000001) read in smbios_write_type4, it was previously checked in a slightly convoluted way if the result from cpu_cpuid_extended_level was larger than 0x80000001, but the check should be if it is larger or equal to 0x80000001. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iabcfdb2b8b90d80baf8f4c4d2fd79f1f44866dc7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78107 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-26arch/x86/smbios: use cpu_cpuid_extended_levelFelix Held
Use cpu_cpuid_extended_level instead of open-coding the same functionality in smbios_write_type4. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib8e20726ea17e8ed94d5ff8f6568758fcfa162ae Reviewed-on: https://review.coreboot.org/c/coreboot/+/78106 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-23arch/x86/cpu_common: use cpuid_e[a,c]xFelix Held
Use cpuid_eax and cpuid_ecx instead of sort-of open-coding the same functionality in cpu_check_deterministic_cache_cpuid_supported. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib0dc2be4f602bf63183b9096e38403ae2f45d959 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78058 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-23arch/x86/cpu_common: use cpu_cpuid_extended_levelFelix Held
Use cpu_cpuid_extended_level instead of open-coding the same functionality in cpu_check_deterministic_cache_cpuid_supported. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4ea22c3997769179311f3c8822e6d8cc15a8834c Reviewed-on: https://review.coreboot.org/c/coreboot/+/78057 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-18acpi/Makefile.inc: Move code inclusionArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I63bbac225662377693ad5f29cc8911494c49b422 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76009 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-09-18arch/arm64: Hook up ACPI table generationArthur Heymans
Linux v6.3.5 is able to detect and use ACPI tables on an out of tree target using hacked version of u-boot to pass ACPI through UEFI. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4f60c546ec262ffb4d447fe6476844cf5a1b756d Reviewed-on: https://review.coreboot.org/c/coreboot/+/76071 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-09-18arch/x86: Remove libhwbase and libgfxinit .data symbols from _bssJeremy Compostella
With commit b7832de0260b042c25bf8f53abcb32e20a29ae9c ("x86: Add .data section support for pre-memory stages"), the libhwbase and libgfxinit .data symbols can be moved to the .data section. Change-Id: I302391e7bc8cb4739e5801d360c57776b0e3eff6 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77897 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2023-09-14x86: Add .data section support for pre-memory stagesJeremy Compostella
x86 pre-memory stages do not support the `.data` section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of `.data` section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage for Raptor Lake has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some `.data` symbols in the `_bss` region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Other platforms do not have that limitation. Hence, resolving it would help to align code and reduce compilation based restriction (cf. the use of `ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot code). We identified three cases to consider: 1. eXecute-In-Place pre-memory stages - code is in SPINOR - data is also stored in SPINOR but must be linked in Cache-As-RAM and copied there at runtime 2. `bootblock` stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different 3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`). eXecute-In-Place pre-memory stages (#1) require the creation of a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) but to be stored right after the code (LMA). Here is the output `readelf --segments` on a `romstage.debug` ELF binary. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20 LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4 Section to Segment mapping: Segment Sections... 00 .text 01 .data Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they are totally different for the Segment 1 holding the `.data` section. Since we need the data section `VirtAddr` to be in the Cache-As-Ram and its `PhysAddr` right after the `.text` section, the use of a new segment is mandatory. `bootblock` (#2) also uses this new segment to store the data right after the code and load it to Cache-As-RAM at runtime. However, the code involved is different. Not eXecute-In-Place pre-memory stages (#3) do not really need any special work other than enabling a data section as the code and data VMA / LMA translation vector is the same. TEST=#1 and #2 verified on rex and qemu 32 and 64 bits: - The `bootblock.debug`, `romstage.debug` and `verstage.debug` all have data stored at the end of the `.text` section and code to copy the data content to the Cache-As-RAM. - The CBFS stages included in the final image has not improperly relocated any of the `.data` section symbol. - Test purposes global data symbols we added in bootblock, romstage and verstage are properly accessible at runtime #3: for "Intel Apollolake DDR3 RVP1" board, we verified that the generated romstage ELF includes a .data section similarly to a regular memory enabled stage. Change-Id: I030407fcc72776e59def476daa5b86ad0495debe Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-09-12x86/tables: Upgrade error to criticalPatrick Rudolph
When more ACPI tables are written than space is available in CBMEM, the buffer overflow corrupts other CBMEM tables and a successful boot is unlikely. Upgrade the error message to critical and be more precise what to do. Change-Id: I152842945f552905729265f7d623cd581dd0a8d0 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77714 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
2023-09-12soc/intel/common: Fix invalid MADT entries creationJeremy Compostella
commit f8ac3dda02f22ebf857efb5b845db97f00598f7d ("soc/intel/common: Order the CPUs based on their APIC IDs") sort algorithnm walks all the `cpu_info' entries without discarding empty ones. Since `cpu_info' is not initialized, the data that is used is undefined and it generally results in the creation of invalid `Local x2APIC' entries in the MADT ("APIC") ACPI table. Depending on the X2APIC ID value the Linux kernel behavior changes (cf. arch/x86/kernel/acpi/boot.c::acpi_register_lapic()): 1. If (int)ID >= MAX_LOCAL_APIC (32768), the Linux kernel discards the entry with the "skipped apicid that is too big" INFO level message. 2. If (int)ID < MAX_LOCAL_APIC (32768) (including negative) this data is taken into account and it can lead to undesirable behavior such as core being disabled as (cf. "native_cpu_up: bad cpu" ERROR kernel message). TEST=Verified the MADT does not contain any invalid entries on rex. Change-Id: I19c7aa51f232bf48201bd6d28f108e9120a21f7e Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77615 Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
2023-09-12arch/x86: Reduce max phys address size for Intel TME capable SoCsJeremy Compostella
On Intel SoCs, if TME is supported, TME key ID bits are reserved and should be subtracted from the maximum physical addresses available. BUG=288978352 TEST=Verified that DMAR ACPI table `Host Address Width` field on rex went from 45 to 41. Signed-off-by: Cliff Huang <cliff.huang@intel.com> Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Change-Id: I9504a489782ab6ef8950a8631c269ed39c63f34d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77613 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-09-12cpu/intel: Move is_tme_supported() from soc/intel to cpu/intelJeremy Compostella
It makes the detection of this feature accessible without the CONFIG_SOC_INTEL_COMMON_BLOCK_CPU dependency. BUG=288978352 TEST=compilation Change-Id: I005c4953648ac9a90af23818b251efbfd2c04043 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77697 Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-08arch to drivers/intel: Fix misspellings & capitalization issuesMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-28arch/x86/cpu: Remove unnecessary parenthesesElyes Haouas
Change-Id: I157a3a700ed998b1012c85857c5fad78f60d62dc Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77525 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-02acpi/acpi.c: Move setting FADT SCI INT to arch specific codeArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ic1533cb520a057b29fc8f926db38338cd3401b18 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76295 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
2023-07-21acpi/acpi.c: Split of ACPI table generation into separate filesArthur Heymans
acpi.c contains architectural specific things like IOAPIC, legacy IRQ, DMAR, HPET, ... all which require the presence of architectural headers. Instead of littering the code with #if ENV_X86 move the functions to different compilation units. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I5083b26c0d4cc6764b4e3cb0ff586797cae7e3af Reviewed-on: https://review.coreboot.org/c/coreboot/+/76008 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-07-10vboot: Fix S3 resume with stage_cacheKyösti Mälkki
In VBOOT_STARTS_IN_ROMSTAGE=y case, vboot_run_logic() did not get called when postcar was loaded from TSEG stage cache on ACPI S3 resume path. Resume failed as MP init attempts to access microcode update from unverified FW_MAIN_A/B section. In a similar fashion, for POSTCAR=n, loading ramstage from TSEG stage cache would bypass the call to vboot_run_logic(). TEST=samsung/lumpy with VBOOT_STARTS_IN_ROMSTAGE=y is able to complete S3 resume. Change-Id: I77fe86d5fd89d22b5ef6f43e65a85a4ccd3259d9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76209 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org>
2023-07-05arch/x86: Ensure LAPIC mode for exception handlerKyösti Mälkki
Attempting to use X2APIC MSRs before the call to enable_lapic() is made raises exception and double-faults. Change-Id: Ib97889466af0fbe639bec2be730784acc015b525 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76194 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-06-27arch/x86/Kconfig: remove period from DUMP_SMBIOS_TYPE17 titleEric Lai
Option name strings should not end with a period, remove it. Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Change-Id: Id61d8961cad2cd311db7d9da3bdb86f0f28b57b4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76087 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-06-23commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-06-22arch/x86,lib: Migrate SMBIOS implementation to common codeBenjamin Doron
SMBIOS is not specific to architecture, and this is mostly a generic implementation. Therefore, move it to common code, having architecture-specific code define some functions to fill this data. Change-Id: I030c853f83f8427da4a4c661b82a6487938b24e6 Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75886 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-06-20arch/x86: Introduce DUMP_SMBIOS_TYPE17 configEric Lai
DDR5 spd is not supported read by coreboot. But FSP can read it, so print the memory information from smbios type17 dimm information. TEST=check the coreboot log. memory Channel-0-DIMM-0 type is DDR5 memory part number is MTC8C1084S1SC56BG1 memory max speed is 5600 MT/s memory speed is 5200 MT/s memory size is 16384 MiB Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Change-Id: I2b5ca1f4a59598531a6cba500672c2717f2a7b00 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75756 Reviewed-by: Kapil Porwal <kapilporwal@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-06arch/x86/include/arch/vga: add defines for VGA MMIO addressesFelix Held
To avoid magic constants in the code, add defines for the VGA MMIO address range from 0xa0000-0xbffff. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie4a4f39a4e876bbba59620d689cd56c3c286daae Reviewed-on: https://review.coreboot.org/c/coreboot/+/75618 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-27libpayload;arch,cpu/x86: drop USE_MARCH_586 Kconfig optionFelix Held
Only the Intel Quark SoC selected this option and that SoC was dropped in commit 531023285ea4 ("soc/intel/quark: Drop support"), so drop this Kconfig option too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic4f1c7530cd8ac7a1945b1493a2d53a7904daa06 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75473 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-26treewide: Remove 'extern' from functions declarationElyes Haouas
"extern" is automatically implied with function declaration. Change-Id: Ic40218acab5a009621b6882faacfcac800aaf0b9 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71890 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2023-05-25arch/x86/include/arch/pci_io_cfg: add IO port count & last port definesFelix Held
The PCI config space access via IO ports uses two 32 bit IO ports. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie99b4f5fc01fb0405243ff108d813ee1a3d35e5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/75408 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-25arch/x86: Don't allow hw floating point operationsArthur Heymans
Even though coreboot does not allow floating point operations some compilers like clang generate code using hw floating point registers, e.g. SSE %XMMx registers on 64bit code by default. Floating point operations need to be enabled in hardware for this to work (CR4). Also in SMM we explicitly need to save and restore floating point registers for this reason. If we instruct the compiler to not generate code with FPU ops, this simplifies our code as we can skip that step. With clang this reduces the binary size a bit. For instance ramstage for qemu/Q35 drops from 216600 bytes decompressed to 212768. TEST: See that with x86_64 bit and clang coreboot reaches the payload without setting the CR4_OSFXSR bit in CR4. Without this change it would bootloop very early in the bootblock on Qemu Q35. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ib8590c55e7aed1ece2aa23b8ea99463396435e11 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75316 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-16x86: pci_io_cfg: Make constant unsigned to fix out of bounds shiftPaul Menzel
Fix the error below when running a coreboot image built with `CONFIG_UBSAN=y`. PCI: pci_scan_bus for bus 00 shift out of bounds src/arch/x86/include/arch/pci_io_cfg.h:13:20 ubsan: unrecoverable error. GCC with `-fsanitize=shift` also flags this: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' So, make the constant unsigned. TEST=emulation/qemu-i440fx with `CONFIG_UBSAN=y` stops later with [ERROR] unaligned access src/lib/rmodule.c:152:27 [EMERG] ubsan: unrecoverable error. Change-Id: Ib05d225ab9f22078d765009b4ee6ef0c63231eed Found-by: UBSAN Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51292 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2023-05-14arch/x86/ioapic.c: Increase the number of bits for ioapic IDArthur Heymans
In practice hardware can use larger numbers. Change-Id: I6e9ddd1ebd396c37e25eb3019f981d45d9c5e062 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70499 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Naresh Solanki <naresh.solanki.2011@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-09arch/x86/car.ld: Fix undefined macroArthur Heymans
Processing LD flags is done without most warnings enabled, which is why this never caused problems. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ic9d82c1426a1c1d2f21c8e7560685cf9d7106a88 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75033 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-05Convert literal uses of CONFIG_MAINBOARD_{VENDOR,PART_NUMBER}Kyösti Mälkki
Only expand these strings in lib/identity.o. Change-Id: I8732bbeff8cf8a757bf32fdb615b1d0f97584585 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74907 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-29ACPI: Make FADT entries for RTC/CMOS architecturalKyösti Mälkki
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY that points to same offset. Since the century field inside RTC falls within the NVRAM space, and could interfere with OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY. There were no reference for the use of offset 0x48 for century. Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-27arch/x86: Disable walkcbfs_asm code when CONFIG_CBFS_VERIFICATION is setJulius Werner
walkcbfs_asm is a simple CBFS implementation in assembly to find a file on a system with memory-mapped SPI flash. It seems to be mostly unused nowadays and is only still called for early microcode loading on some old systems (e.g. FSP 1.1 and older). Using this implementation with CONFIG_CBFS_VERIFICATION is unsafe because it does not verify the hashes the way the normal CBFS code does. Therefore, to avoid potential security vulnerabilities from creeping in, this patch makes sure the code cannot be compiled in when CBFS_VERIFICATION is active. That means it won't be supported on the old boards using this for microcode loading. Ideally CONFIG_CBFS_VERIFICATION should have a `depends on` to make this dependency more obvious in menuconfig, but the configs actually using this code are not easy to untangle (e.g. CONFIG_MICROCODE_UPDATE_PRE_RAM is just set everywhere by default although only very few boards are really using it, and a lot of different old Intel CPU models are linking in src/cpu/intel/car/non-evict/cache_as_ram.S without being united under a single Kconfig so that's not easy to change). To keep things simple, this patch will just prevent the code from being built and result in a linker error if a bad combination of Kconfigs is used together. Later patches can clean up the Kconfigs to better wrap that dependency if the affected boards are still of enough interest to be worth that effort. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I614a1b05881aa7c1539a7f7f296855ff708db56c Reviewed-on: https://review.coreboot.org/c/coreboot/+/74243 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-04-27arch/x86/include/pci_io_cfg: introduce PCI_IO_CONFIG_[INDEX,DATA] defineFelix Held
Instead of having multiple instances of the same magic numbers in the code, introduce and use the PCI_IO_CONFIG_INDEX and PCI_IO_CONFIG_DATA definitions. TEST=Timeless build for Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If6f6f058180cf36cae7921ce3c7aaf1a0c75c7b9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-04-27ACPI: Make FADT entries for SMI architecturalKyösti Mälkki
Change-Id: I80aa71b813ab8e50801a66556d45ff66804ad349 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74600 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-26soc/intel: Introduce ioapic_get_sci_pin()Kyösti Mälkki
According to ACPI Release 6.5 systems supporting PIC (i8259) interrupt mechanism need to report IRQ vector for the SCI_INT field. In PIC mode only IRQ0..15 are allowed hardware vectors. This change should cover section 5.2.9 to not pass SCI_INT larger than IRQ15. Section 5.2.15.5 needs follow-up work. Care should be taken that ioapic_get_sci_pin() is called after platform code has potentially changed the routing from the default. It appears touched all platforms except siemens/mc_aplX currently program SCI as IRQ9. Change-Id: I723c207f1dcbba5e6fc0452fe1dbd087fad290ee Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74326 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-14soc/amd: Clarify ACPI _PRT entry generationKyösti Mälkki
The reference to a constant FCH IOAPIC interrupt count used with GNB IOAPIC was a bit obscure. Change-Id: I2d862e37424f9fea7f269cd09e9e90056531b643 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74314 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-06cpu/x86/mp_init.c: Keep track of initial lapic ID inside device_pathArthur Heymans
It's quite confusing to keep track of lapic ID inside the device struct and initial lapic ID inside an array. Change-Id: I4d9f8d23c0b0e5c142f6907593428d8509e4e7bb Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64342 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-04arch/x86/smbios: Check str for NULL in smbios_add_string()Maximilian Brune
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Ic228b869aea362c1f07e0808c2735ff3b285a6bd Reviewed-on: https://review.coreboot.org/c/coreboot/+/73980 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-03-29arch/x86/smbios: Add socket type for Meteor LakeJay Patel
Add socket type for Meteor Lake as PROCESSOR_UPGRADE_OTHER. BUG=None TEST=processor upgrade is equal to "Other" for "dmidecode -t 4" Signed-off-by: Jay Patel <jay2.patel@intel.com> Change-Id: If891990436a0679697e292b460eaec63c09e7bf8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73708 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-22x86/include/registers.h: macros should not use a trailing semicolonYuchen He
Macros should not use a trailing semicolons. Remove those from 'LONG_DOWNTO8' aswell as 'LONG_DOWNTO16' and add them at places where the macros are used. Signed-off-by: Yuchen He <yuchenhe126@gmail.com> Change-Id: I5ba01bc09f9a2d9ecd54014e27ec0a24c7297412 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73864 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2023-03-16arch/x86/ioapic: Print IOAPIC ID for GSI #0Jay Patel
Print IOAPIC ID for GSI #0 in logs, as part of IOAPIC initialization. BUG=None TEST=Confirmed "IOAPIC: ID = 0x00" printed in logs. Signed-off-by: Jay Patel <jay2.patel@intel.com> Change-Id: I8d8e94fe623795d059ec2abbb3319b60fd80f5ca Reviewed-on: https://review.coreboot.org/c/coreboot/+/73707 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 15:58:46 +0000