summaryrefslogtreecommitdiff
path: root/src/arch
AgeCommit message (Collapse)Author
2024-06-21arch/arm64: Add Kconfig option ARM64_BL31_OPTEE_WITH_SMCYu-Ping Wu
Add a new Kconfig option ARM64_BL31_OPTEE_WITH_SMC to control whether to build the OP-TEE dispatcher for BL31. This config also enables the BL31 build option OPTEE_ALLOW_SMC_LOAD, which allows loading the OP-TEE image after boot via a Secure Monitor Call (SMC). For ChromeOS devices, CROS_WIDEVINE_SMC is also enabled to allow passing secrets from firmware to OP-TEE. BUG=b:347851571 TEST=emerge-geralt coreboot BRANCH=geralt Change-Id: I4dcf82d47b537146d71ce3cd2050ec597ed0734f Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83111 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
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-06arch/io.h: Add port I/O functions to other architecturesAlper Nebi Yasak
The QEMU Bochs display driver and the QEMU Firmware Configuration interface code (in the qemu-i440fx mainboard dir) were written for x86. These devices are available in QEMU VMs of other architectures as well, so we want to port them to be independent from x86. The main problem is that the drivers use x86 port I/O functions to communicate with devices over PCI I/O space. These are currently not available for ARM* and RISC-V, although it is often still possible to access PCI I/O ports over MMIO through a translator. Add implementations of port I/O functions that work with PCI I/O space on these architectures as well, assuming there is such a translator at a known address configured at build-time. Change-Id: If7d9177283e8c692088ba8e30d6dfe52623c8cb9 Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80372 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-06-05arch/arm64: Support FEAT_CCIDXYidi Lin
ARM SoC supports FEAT_CCIDX after ARMv8.3. The register field description of CCSIDR_EL1 is different when FEAT_CCIDX is implemented. If numsets and associativity from CCSIDR_EL1 are not correct, the system would hang during mmu_disable(). Rather than assuming that FEAT_CCIDX is not implemented, this patch adds a check to dcache_apply_all to use the right register format. Reference: - https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/12770 BUG=b:317015456 TEST=mmu_disable works on the FEAT_CCIDX supported SoC. TEST=manually add mmu_disable to emulation/qemu-aarch64/bootblock.c and verify with the command qemu-system-aarch64 -bios \ ./coreboot-builds/EMULATION_QEMU_AARCH64/coreboot.rom -M \ virt,secure=on,virtualization=on -cpu max -cpu cortex-a710 \ -nographic -m 8192M Change-Id: Ieadd0d9dfb8911039b3d36c9419af4ae04ed814c Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82635 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
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-25arch/arm64: Implement initial set of SMBIOS tablesBenjamin Doron
Implement the two architectural tables: processor and cache. Note that SoC/board code should override core-thread count and, for spec-compliance, create CBMEM_ID_MEMINFO. Change-Id: Iedae0f26f168bd6d3af866e35d9d39ddb01abc15 Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78285 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-05-25arch/arm64: Support calling a trusted monitorBenjamin Doron
Implement support for generating an SMC to call a trusted monitor. Some functions are provided to read the SoC ID from the monitor, if supported. Change-Id: I158db0b971aba722b3995d52162146aa406d1644 Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78284 Reviewed-by: Julius Werner <jwerner@chromium.org> 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-05-09arch/arm64/Makefile.mk: Switch linker to GNU GCCYidi Lin
TF-A migrates the default choice of linker to GCC in order to enable LTO. Change BL31_LDFLAGS from `--emit-relocs` to '-Wl,--emit-relocs', so that GCC is able to pass `--emit-relocs` to the linker. [1]: https://review.trustedfirmware.org/c/26703 BUG=b:338420310 TEST=emerge-geralt coreboot TEST=./util/abuild/abuild -t google/geralt -b geralt -a TEST=./util/abuild/abuild -t google/oak -b elm -a Change-Id: I65b96aaa052138592a0f57230e1140a1bb2f07ac Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82189 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-09arch/arm64/Makefile.mk: Unset toolchain vars for BL31Yidi Lin
This change is for upcoming arm-trusted uprev commit. TF-A refactors the toolchain detection in [1][2]. After that `AR`, `CC`, `LD` and other toolchain variables have precedence over `CROSS_COMPILE`. Since ChromeOS build system also sets those toolchain variables when building coreboot, it results that TF-A uses CrOS GCC instead of coreboot SDK. It needs to unset those variables in order to make `CROSS_COMPILE` effective. TF-A upstream changes the default linker from BFD to GCC in [3]. Therefore, temporarily overriding LD as $(LD_arm64} to fix the below build error. aarch64-elf-gcc: error: unrecognized command-line option '--emit-relocs' In addition, TF-A wrapped LD with single quotes to solve Windows path issue[4]. On MT8173 platform, `--fix-cortex-a53-843419` is appended to $(LD_arm64} for ERRATA_A53_843419. It results in the below build error. /bin/sh: 1: --fix-cortex-a53-843419: not found Since `--fix-cortex-a53-843419` is never passed to TF-A, simply extract the LD command from $(LD_arm64) by $(word 1, $(LD_arm64)). [1]: https://review.trustedfirmware.org/c/24921 [2]: https://review.trustedfirmware.org/c/25333 [3]: https://review.trustedfirmware.org/c/26703 [4]: https://review.trustedfirmware.org/c/26737 BUG=b:338420310 TEST=emerge-geralt coreboot TEST=./util/abuild/abuild -t google/geralt -b geralt -a -x TEST=./util/abuild/abuild -t google/oak -b elm -a -x TEST=./util/abuild/abuild -t google/cherry -x -a Change-Id: Ieac9f96e81e574b87e20cd2df335c36abcb8bb5c Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82187 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-26arch/arm/armv7/exception.c: fix warnings of macros and functionsIntegral
Use better alignment attribute macro and add missing identifier names for function definition arguments. Change-Id: I1c5c33fc9210f068ff88c8d981f1a1c739890c9c Signed-off-by: Integral <integral@member.fsf.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82050 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-24arch/arm64: Extend cache helper functionsDavid Milosevic
This patch extends the cpu_get_cache_info function, so that additional information like size of cache lines can be retrieved. Patch was tested against the qemu-sbsa mainboard. Change-Id: If6fe731dc67ffeaff9344d2bd2627f45185c27de Signed-off-by: David Milosevic <David.Milosevic@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79106 Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2024-04-22arch/arm64: Add EL1/EL2/EL3 support for arm64David Milosevic
Currently, arch/arm64 requires coreboot to run on EL3 due to EL3 register access. This might be an issue when, for example, one boots into TF-A first and drops into EL2 for coreboot afterwards. This patch aims at making arch/arm64 more versatile by removing the current EL3 constraint and allowing arm64 coreboot to run on EL1, EL2 and EL3. The strategy here, is to add a Kconfig option (ARM64_CURRENT_EL) which lets us specify coreboot's EL upon entry. Based on that, we access the appropriate ELx registers. So, for example, when running coreboot on EL1, we would not access vbar_el3 or vbar_el2 but instead vbar_el1. This way, we don't generate faults when accessing higher-EL registers. Currently only tested on the qemu-aarch64 target. Exceptions were tested by enabling FATAL_ASSERTS. Signed-off-by: David Milosevic <David.Milosevic@9elements.com> Change-Id: Iae1c57f0846c8d0585384f7e54102a837e701e7e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74798 Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: ron minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
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-12tree: Drop unused <cbmem.h>Elyes Haouas
Change-Id: If8be8dc26f2729f55dc6716e6d01e2b801d79e44 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81829 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-04-01arch/ppc64: Add arch as supported by the clang compilerArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I1aacff869663e1db74cd485787d7103b9ec5602e Reviewed-on: https://review.coreboot.org/c/coreboot/+/78448 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-04-01arch/ppc64: Fix inline assembly for clangArthur Heymans
Use macros from the Linux kernel 6.5 to make the inline assembly also compile on clang. TEST: See that the generated code is identical on GCC and compiles on clang. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I516033c69e62dfdb38f83285c156d5527917ad55 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78446 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Martin L Roth <gaumless@gmail.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-27arch/riscv: remove misaligned load/store/fetch handlingRonald G Minnich
Testing on the unmatched shows the code no longer works completely correctly; Linux has taken over the handling of misalignment anyway, because handling it in firmware, with the growing complexity of the ISA and the awkward way in which it has to be handled, is more trouble than its worth. Plus, we don't WANT misalignment handled, magically, in firmware: the cost of getting it wrong is high (as I've spent a month learning); the performance is terrible (350x slowdown; and most toolchains now know to avoid unaligned load/store on RISC-V anyway. But, mostly, if alignment problems exist, *we need to know*, and if they're handled invisibly in firmware, we don't. The problem with invisible handling was shown a while back in the Go toolchain: runtime had a small error, such that many misaligned load/store were happening, and it was not discovered for some time. Had a trap been directed to kernel or user on misalignment, the problem would have been known immediately, not after many months. (The error, btw, was masking the address with 3, not 7, to detect misalignment; an easy mistake!). But, the coreboot code does not work any more any way, and it's not worth fixing. Remove it. Tested by booting Linux to runlevel 1; before, it would hang on an alignment fault, as the alignment code was failing (somewhere). This takes the coreboot SBI code much closer to revival. Change-Id: I84a8d433ed2f50745686a8c109d101e8718f2a46 Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81416 Reviewed-by: Maximilian Brune <maximilian.brune@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-26util/xcompile: Add target architecture to CPPFLAGSArthur Heymans
In order to preprocess linker scripts the target architecture needs to be specified. With clang this needs to be set via a cli argument. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4340681e30059d6f18a49a49937668cd3dd39ce1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75031 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-03-25arch/riscv: add new SBI callsRonald G Minnich
This is just a start. We are playing catch up. 7 down, 70+ to go. Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Change-Id: I5dac8613020e26ec74ac1c74158fc9791553693f Reviewed-on: https://review.coreboot.org/c/coreboot/+/81294 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-03-22arch/riscv: add Kconfig variable RISCV_SOC_HAS_MENVCFGRonald G Minnich
Older parts do not have the menvcfg csr. Provide a Kconfig variable, default y, to enable it. Check the variable in the payload code, when coreboot SBI is used, and print out if it is enabled. The SiFive FU540 and FU740 do not support this register; set the variable to n for those parts. Add constants for this new CSR. Change-Id: I6ea302a5acd98f6941bf314da89dd003ab20b596 Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81425 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
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-19arch/riscv: add constants for Base ExtensionRonald G Minnich
Get used to this rate of change, SBI adds one new function a month, on average, for the last 7 years. Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Change-Id: Iaad763464678d1921dfefdbee1e39fba2fe5585a Reviewed-on: https://review.coreboot.org/c/coreboot/+/81286 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-14arch/riscv: support physical memory protection (PMP) registersRonald G Minnich
PMP (Physical Memory Protection) is a feature of the RISC-V Privileged Architecture spec, that allows defining region(s) of the address space to be protected in a variety of ways: ranges for M mode can be protected against access from lower privilege levels, and M mode can be locked out of accessig to memory reserved for lower privilege levels. Limits on Read, Write, and Execute are allowed. In coreboot, we protect against Write and Execute of PMP code from lower levels, but allow Reading, so as to ease data structure access. PMP is not a security boundary, it is an accident prevention device. PMP is used here to protect persistent ramstage code that is used to support SBI, e.g. printk and some data structures. It also protects the SBI stacks. Note that there is one stack per hart. There are 512- and 1024-hart SoC's being built today, so the stack should be kept small. PMP is not a general purpose protection mechanism and it is easy to get around it. For example, S mode can stage a DMA that overwrites all the M mode code. PMP is, rather, a way to avoid simple accidents. It is understood that PMP depends on proper OS behavior to implement true SBI security (personal conversation with a RISC-V architect). Think of PMP as "Protection Minus Protection". PMP is also a very limited resource, as defined in the architecture. This language is instructive: "PMP entries are described by an 8-bit configuration register and one XLEN-bit address register. Some PMP settings additionally use the address register associated with the preceding PMP entry. Up to 16 PMP entries are supported. If any PMP entries are implemented, then all PMP CSRs must be implemented, but all PMP CSR fields are WARL and may be hardwired to zero. PMP CSRs are only accessible to M-mode." In other words if you implement PMP even a little, you have to impelement it all; but you can implement it in part by simply returning 0 for a pmpcfg. Also, PMP address registers (pmpaddr) don't have to implement all the bits. On a SiFive FU740, for example, PMP only implements bits 33:0, i.e. a 34 bit address. PMPs are just packed with all kinds of special cases. There are no requirements that you read back what you wrote to the pmpaddr registers. The earlier PMP code would die if the read did not match the write, but, since pmpaddr are WARL, that was not correct. An SoC can just decide it only does 4096-byte granularity, on TOR PMP types, and that is your problem if you wanted finer granulatiry. SoC's don't have to implement all the high order bits either. And, to reiterate, there is no requirement about which of the pmpcfg are implemented. Implementing just pmpcfg15 is allowed. The coreboot SBI code was written before PMP existed. In order for coreboot SBI code to work, this patch is necessary. With this change, a simple S-mode payload that calls SBI putchar works: 1: li a7, 1 li a0, 48 ecall j 1b Without this change, it will not work. Getting this to build on RV32 required changes to the API, as it was incorrect. In RV32, PMP entries are 34 bits. Hence, the setup_pmp needed to accept u64. So, uinptr_t can not be used, as on 32 bits they are only 32 bit numbers. The internal API uses uintptr_t, but the exported API uses u64, so external code does not have to think about right shifts on base and size. Errors are detected: an error in base and size will result in a BIOS_EMERG print, but not a panic. Boots not bricks if possible. There are small changes to the internal API to reduce stack pressure: there's no need to have two pmpcfg_t on the stack when one will do. TEST: Linux now boots partly on the SiFive unmatched. There are changes in flight on the coreboot SBI that will allow Linux to boot further, but they are out of scope for this patch. Currently, clk_ignore_unused is required, this requires a separate patch. Change-Id: I6edce139d340783148cbb446cde004ba96e67944 Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81153 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Hug <philipp@hug.cx>
2024-03-09arch/riscv: Remove typedefsMaximilian Brune
typedefs violate our coding-style Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Id51eda53b6b53ed2cc66c0339c03c855c12c1bd8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/81124 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Hug <philipp@hug.cx>
2024-03-09arch/riscv: Add SMP support for exception handlerXiang Wang
Change-Id: Ia1f97b82e329f6358061072f98278cf56b503618 Signed-off-by: Xiang Wang <merle@hardenedlinux.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68841 Reviewed-by: Philipp Hug <philipp@hug.cx> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: ron minnich <rminnich@gmail.com>
2024-03-06arch/riscv: Makefile.mk: Fix incorrect config variableRonald G Minnich
ARCH_RISCV_PMP should be CONFIG_ARCH_RISCV_PMP. Rename it. Change-Id: I2a22acae5cd9f30e01c491653bf7fc7b7765d815 Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81086 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.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-04riscv/mb/qemu: fix DRAM probingPhilipp Hug
Current version of qemu raise an exception when accessing invalid memory. Modify the probing code to temporary redirect the exception handler like on ARM platform. Also move saving of the stack frame out to trap_util.S to have all at the same place for a future rewrite. TEST=boots to ramstage Change-Id: I25860f688c7546714f6fdbce8c8f96da6400813c Signed-off-by: Philipp Hug <philipp@hug.cx> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36486 Reviewed-by: ron minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-18arch/riscv/Makefile.mk: Fix OpenSBI compilationMaximilian Brune
1. romstage.S should only be included if we have a separate romstage 2. FW_JUMP and FW_DYNAMIC are opposing options and we only support FW_DYNAMIC Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Ic14fa77d2f223664b9faba048b759e03efffcde8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79952 Reviewed-by: Philipp Hug <philipp@hug.cx> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-18arch to cpu: Add SPDX license headers to Kconfig filesMartin Roth
Change-Id: I7dd7b0b7c5fdb63fe32915b88e69313e3440b64a Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80587 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-10arch/riscv/boot.c: Comment OpenSBI Supervisor mode switchMaximilian Brune
It simply adds a comment to indicate to the reader that the RISCV_PAYLOAD_MODE_S parameter causes OpenSBI to switch to Supervisor mode. Otherwise it could be interpreted that coreboot switches to Supervisor mode before starting OpenSBI (which is not the case) Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Ib62be0c2ff59361200df4c65f9aca5f7456a0ada Reviewed-on: https://review.coreboot.org/c/coreboot/+/79949 Reviewed-by: ron minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Hug <philipp@hug.cx>
2024-02-08commonlib: Change GCD function to always use 64 bitsJulius Werner
It seems that we have some applications where we need to calculate a GCD in 64 bits. Now, we could instantiate the algorithm multiple times for different bit width combinations to be able to use the most efficient one for each problem... but considering that the function usually only gets called once per callsite per stage, and that software emulation of 64-bit division on 32-bit systems doesn't take *that* long either, we would probably usually be paying more time loading the second instance of the function than we save with faster divisions. So let's just make things easy and always do it in 64-bit and then nobody has to spend time thinking on which version to call. Change-Id: I028361444c4048a0d76ba4f80c7334a9d9983c87 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80319 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yidi Lin <yidilin@google.com>
2024-02-07arch/arm64/armv8: Add exception output without printkMaximilian Brune
In case printk does not work the current exception handler will print a simple "!" to notify the developer that coreboot is actually there but something went wrong. The "!" can be quite confusing when it actually happens that printk does not work. Since "!" doesn't really say much (if you don't know the exception arm64 code) the developer (like me) can easily assume that something went wrong while configuring clocks or baud rate of UART, since the output seemingly does not seem to make sense. This adds a little bit more output to assure the developer that what was printed was actually intended to be printed. Therefore it prints "EXCEPT" which assures the developer that this was intended output. It also adds a comment above so that developer can more easily grep for this message. It has intentionally not been written as: ``` const char *msg = "\r\n!EXCPT!"; while (*msg) __uart_tx_byte(*msg++); ``` because in this case the compiler will generate code that will place `msg` somewhere in bootblock and the code will try to access this using a memory address. In rare cases (if you link bootblock at the wrong address) this memory address can be wrong and coreboot will not print the message. Using individual calls to `__uart_tx_byte` ensures that the compiler will generate code which directly puts the character bytes into the argument register without referencing a variable in bootblock. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I2f858730469fff3cae120fd7c32fec53b3d309ca Reviewed-on: https://review.coreboot.org/c/coreboot/+/80184 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-07arch/riscv: Add OPENSBI_FW_DYNAMIC_BOOT_HART optionMaximilian Brune
This adds another option to tell OpenSBI which hart to use for booting. Test: Start hifive-unmatched board and see that Hart 1 (instead of 0) is used for running OpenSBI. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Id58bd6ae3b55a5ef3f1a5c97dfa07c79aa4c78d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79948 Reviewed-by: Philipp Hug <philipp@hug.cx> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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-26src, util: Update toolchain.inc references to .mkMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ieaf7894f49a90f562b164924cc025e3eab5a3f7f Reviewed-on: https://review.coreboot.org/c/coreboot/+/80129 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
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-18include/memlayout.h: Add OPENSBI linker macroMaximilian Brune
This adds an opensbi linker macro for easier integration into memlayout.ld linker scripts. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I4f138de685c6bfb3cdbf79d63787eb0c5aab8590 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77974 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-12-20arch/riscv: Use same indent levels for switch/caseFelix Singer
Use same indent levels for switch/case in order to comply with the linter. Change-Id: Icf41e823c42ffea7b73bdd9112081af4d1f94bc9 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79417 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Alexander Couzens <lynxis@fe80.eu> Reviewed-by: Eric Lai <ericllai@google.com>
2023-12-12arch/arm64/armv8/Makefile.inc: Add clang -target for .ld CPPArthur Heymans
When preprocessing the linker script the target arch needs to be specified. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Id18af3da93d2d06a2ebb83eddd03377c9026c8fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/78443 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2023-12-09arch/riscv/payload: Remove old RISC-V CSR namesLennart Eichhorn
LLVM/clang 17 removed support for CSR names that are no longer included in the RISC-V ISA Manual Privileged Specification since version 1.12. Related LLVM commit: https://reviews.llvm.org/D149278 Change-Id: I7c8f2a06a109333f95230bf0a3056c8d5c8a9132 Signed-off-by: Lennart Eichhorn <lennarteichhorn@googlemail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79364 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
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-23arch/riscv/romstage: Start from assemblyArthur Heymans
Without this it would use the exception handler from the previous stage. Change-Id: I79d875aca6cd0cffe482e4ebb5f388af0adf6aed Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68840 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-15arch/arm64: Avoid GCC warning about out of bounds array accessZebreus
With the update to GCC 13 a new warning about subtracting numbers from arrays appears. src/arch/arm64/armv8/mmu.c:296:9: error: array subscript -1 is outside array bounds of 'u8[]' {aka 'unsigned char[]'} [-Werror=array-bounds=] Change-Id: I4757ca2e7ad3f969d7416041ea40c3e9866cdf49 Signed-off-by: Zebreus <lennarteichhorn@googlemail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79014 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-13arch/x86/riscv: Use 'all' target to include files in all stagesArthur Heymans
This adds a few new files to romstage, that will be needed in follow-up patches. Change-Id: I2ba84e0becee883b5becf12e51f40734cad83d7d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68839 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
2023-11-13arch/riscv/ramstage.S: Add comments for passed argumentsMaximilian Brune
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Ib1af1359249008d9eba351271637748a7edcec26 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78966 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-10src: Remove unnecessary semicolons from the end of macrosMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ia005915a05d02725f77b52ccd7acebefaf25d058 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78964 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-04arch/arm64/arch_timer: Fix possible overflow in multiplicationYidi Lin
The value from raw_read_cntfrq_el0() could be large enough to cause overflow when multiplied by USECS_PER_SEC. To prevent this, both USECS_PER_SEC and tfreq can be reduced by dividing them by their GCD. BUG=b:307790895 TEST=emerge-geralt coreboot TEST=boot to kernel and check the timestamps from `cbmem` Change-Id: I366667de05392913150414f0fa9058725be71c52 Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78800 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-25arch/arm64/cache: Implement helpers to obtain CPU cache detailsBenjamin Doron
This is required for compliant ACPI/SMBIOS implementations on AArch64, and can optionally be displayed to the user. Change-Id: I7022fc3c0035208bc3fdc716fc33f6b78d8e74fc Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78042 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 16:15:44 +0000