summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* mb/google/nissa/var/anraggar: Config DP AUX BIAS according to fw_configWeimin Wu2024-02-092-15/+34
| | | | | | | | | | | | | | EVT mini-build changes redriver IC from PS8745 to ANX7493, the ANX7493 not support DP AUX BIAS, so connects DP AUX BIAS of DB to SOC directly. Add DB_AUX_BIAS bit field to fw_config for compatibility. BUG=b:320235566 TEST=DP function of MB and DB workable Change-Id: I53974ec7444912a63d0fe0a9303c9e5d6941f68d Signed-off-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80259 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* drivers/qemu: Drop redundant vga_io addition to ramstageAlper Nebi Yasak2024-02-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | While introducing driver support for QEMU Cirrus display device, commit 7905f9254ebc ("qemu: cirrus native video init") also explicitly adds VGA I/O functions into ramstage class when Bochs display driver support is enabled. Later, commit db7d04d1b753 ("qemu: Support textmode gfx init.") makes the related config option select CONFIG_VGA, which also adds the same file into ramstage class (among other things) in another Makefile. Doing this twice is unnecessary. Remove the addition based on the Bochs display driver's config option. Adding it based on CONFIG_VGA is clearer, and future patches will try to support a Bochs display without legacy VGA support on non-x86 architectures. Change-Id: Ib31344e242689682d74d8a83c97b6e8027641926 Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80374 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* mb/google/puff/var/*: Clean up SerialIO/I2C config in overridetreeMatt DeVillier2024-02-0811-75/+21
| | | | | | | | | | | | | | | | Ensure that the SerialIoDevMode config and common_soc_config registers for each variant are programmed consistently with the devices' enabled status in that variant's overridetree; remove and disable extraneous devices as appropriate. TEST=build/boot several puff variants, verify all components working as expected, nothing missing from cbmem, lspci, etc. Change-Id: Ib9d0cf48e405be7c00c553646651fc6f28c4e3f0 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80164 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* mb/google/puff/var/*: Drop redundant device entries in overridetreeMatt DeVillier2024-02-0811-196/+128
| | | | | | | | | | | | | | Now that the puff baseboard uses chipset devicetree references, remove all references whose value is identical to the chipset devicetree default or the baseboard default, since they are pointless clutter. TEST=tested with rest of patch train Change-Id: Iada32111367fdc964d6126ee43e261c1feb123cf Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80163 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
* mb/google/puff: Delegate I2C device configuration to overridetreeMatt DeVillier2024-02-081-6/+0
| | | | | | | | | | | | | | | Don't enable the i2c controllers, since the variants will enable the ones they need individually in their overrridetrees. Disable gspi1 since all variants disable it in their overridetrees. TEST=tested with rest of patch train Change-Id: Ia9c67a8e05923a080e31d04721ecae4c810e82e8 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
* mb/google/puff: Drop devicetree entries identical to chipset.cbMatt DeVillier2024-02-081-50/+21
| | | | | | | | | | | | | | Now that puff uses chipset devicetree references, remove all references whose value is identical to the chipset devicetree default, since they are pointless clutter. TEST=tested with rest of patch train Change-Id: I3a515f13df1252ed2b769a535da22a523c95c359 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80141 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* mb/google/puff: Use chipset dt reference namesFelix Singer2024-02-0812-290/+345
| | | | | | | | | | | Use the references from the chipset devicetree as this makes the comments superfluous. Change-Id: I06a3acca0a72ff158a0143acc87d9479b2deb0d5 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80017 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
* soc/amd/common/data_fabric/domain: drop unneeded parenthesisFelix Held2024-02-081-1/+1
| | | | | | | | Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I84a7b7b1b2c45b773c6f10b39e7813db3f96546e Reviewed-on: https://review.coreboot.org/c/coreboot/+/80408 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/amd/common/data_fabric/domain: don't report DRAM as MMIO producerFelix Held2024-02-081-0/+3
| | | | | | | | | | | | | | | | | | | | In commit 30f36c35e75a ("soc/amd: rework DRAM and fixed resource reporting") the reporting of the DRAM resources was moved from the northbridge PCI device to the domain device. amd_pci_domain_fill_ssdt didn't skip those DRAM resources when generation the resource producer ranges which made Windows 10 very unhappy when it tried to evaluating the ACPI tables causing it to reboot in a loop. To fix this, add a check to also skip the resources that have the IORESOURCE_STORED flag set when generating the resource producer ranges for the PCI root. TEST=Windows 10 now successfully boots and reboots again on Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b6d3fd8c7f89aa4364de7963d745aef8d6b6f42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80407 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* libpayload: timer: Revert timer_hz() return type to 64-bitsJulius Werner2024-02-085-10/+8
| | | | | | | | | | | | | | | | | | It seems that reducing the return type of timer_hz() to uint32_t in CB:78888 was a bad idea... some Intel platforms actually use their raw CPU clock for the timestamp counter which can be higher than 4GHz. This patch reverts it back to uint64_t. Also remove the redundant assertion in timer/generic.c since timer_us() itself already does that check. Cq-Depend: chromium:5274555 Change-Id: I471c7de7a28aec5bb965b23525ed579481ac8361 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80320 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Yidi Lin <yidilin@google.com>
* mb/google/nissa/var/yaviks: Enable USE_MTCL and DRIVERS_MTK_WIFIDavid Ruth2024-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch selects the DRIVERS_MTK_WIFI and USE_MTCL configs for google/yaviks as the first platform that provides a country list to the Linux kernel via an ACPI function (MTCL) in SSDT for MediaTek WiFi chipsets that are capable of operating on the 6GHz band. BUG=b:295544553 TEST=Build on similar model (PUJJO) that I have access to and verify the flag and feature work as intended. TEST=Add wifi_mtcls.bin blob to cbfs TEST=Build coreboot for pujjo `emerge-nissa coreboot chromeos-bootimage` TEST=Verify that MTCL defined in the file is present: TEST=`acpidump -b` TEST=`iasl ssdt.dat` TEST=`less ssdt.dsl` TEST=Search for MTCL Change-Id: Iec54fc582d68b443665fceda47187c28f1a9216c Signed-off-by: David Ruth <druth@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80305 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Subrata Banik <subratabanik@google.com>
* commonlib: Change GCD function to always use 64 bitsJulius Werner2024-02-0810-23/+28
| | | | | | | | | | | | | | | | | | | | 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>
* cpu/x86/64bit: Turn jumping to long mode into a macroArthur Heymans2024-02-0811-19/+30
| | | | | | | | | | | This makes it easier to reuse, e.g. if you want to do it twice in one assembly file. Change-Id: Ida861338004187e4e714be41e17c8447fa4cf935 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79261 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* cpu/qemu-x86/cache_as_ram: Move guardArthur Heymans2024-02-081-1/+1
| | | | | | | | | | | | Although entry64.inc does guard against ENV_X86_64, it's more aesthetic to have it with the other 64bit code below a guard just like other platforms. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: If3ef19dd6654cd2fa0be3c68dee4a472e7a7935d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80354 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* soc/mediatek/mt8188: Enable CROS_WIDEVINE_SMCYi Chou2024-02-081-0/+1
| | | | | | | | | | | | | BUG=b:248612503 TEST=Test with crrev.com/c/4756330 BRANCH=none Signed-off-by: Yi Chou <yich@google.com> Change-Id: I3dded9042abd85a948598f98475c21a1af9b4d80 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80315 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yidi Lin <yidilin@google.com>
* cpu/x86: Add 1GiB pages for memory access up to 512GiBAshish Kumar Mishra2024-02-083-1/+43
| | | | | | | | | | | | | | | | | | | Current pagetable implementation allows memory access up to 4GiB using 2MiB pages. If user wants to access more than 4GiB with a 2MiB page it will require more pagetable entries. By using a 1GiB page table, users can access more than 4GiB of memory while reducing the number of pagetable entries. This patch enables memory access up to 512GiB through 1GiB pages by selecting USE_1G_PAGES_TLB in Kconfig. TEST: Verified in 64bit mode boot and access above 4GiB Change-Id: Id569ae5b50abf5b72e4db33b5e4cd802399e76ec Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80088 Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* mb/google/brox: Handle GPI_INT pin lower to GPI_WAKEAshish Kumar Mishra2024-02-083-3/+26
| | | | | | | | | | | | | | | | | | | In case where PAD_CFG_GPI_INT() is initialized with a pin value lower to PAD_CFG_GPI_IRQ_WAKE() for same GPIO community the set_ioapic_used() is only called for the PAD_CFG_GPI_IRQ_WAKE() pin. Due to this the IRQ associated with PAD_CFG_GPI_INT() is found free by find_free_unique_irq() during IRQ assignment and assigned to other pins which causes IRQ conflicts BUG=b:322984217 BRANCH=None TEST=Boot test on brox, check if correct IRQ assigned to EC Change-Id: I8c3d557e888b8d0ceac203f49b702910fba26d6d Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80334 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* arch/arm64/armv8: Add exception output without printkMaximilian Brune2024-02-071-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* soc/amd/genoa_poc/chip: print data fabric MMIO decoding configurationFelix Held2024-02-071-0/+3
| | | | | | | | | | | | Printing the data fabric MMIO decode window configuration might be useful and it also aligns this SoC more with the other AMD family 17h+ SoCs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I52f6655a5c63e31165549dcb6f5f95d4e74bad3d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80356 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
* soc/amd: drop unneeded data_fabric_set_mmio_npFelix Held2024-02-0714-139/+6
| | | | | | | | | | | | | | | | | | | | | | | Drop the unneeded data_fabric_set_mmio_np function and the corresponding SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig symbol. In systems with only one FCH, its MMIO region will be subtractively decoded and there's no need to add a non-posted data fabric MMIO region after the FSP/openSIL has already configured the data fabric decode windows. In systems with more than one FCH, openSIL will already take care of initializing everything for the additional FCH, so we also won't need to do anything in that case. Since dropping this function also removes both data_fabric_print_mmio_conf calls before and after adding the unneeded non-posted MMIO region, replace the data_fabric_set_mmio_np call with a data_fabric_print_mmio_conf call to still print the data fabric MMIO decode regions set up by the FSP/openSIL. TEST=Mandolin still boots successfully Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I474b6e066060abb3fe5b78505521c7782cc192ee Reviewed-on: https://review.coreboot.org/c/coreboot/+/80355 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
* arch/x86/mpspec: reduce scope of smp_write_ioapicFelix Held2024-02-072-3/+1
| | | | | | | | | | | | 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>
* drivers/pc80/tpm: probe for TPM family of a deviceSergii Dmytruk2024-02-072-25/+80
| | | | | | | | | | | | | At the moment this is to handle the situation when device ID is the same for TPM1 and TPM2 versions of a device. Later this TPM family will be returned to the caller. Change-Id: I23b85e6da0e02999704f3ec30412db0bdce2dd8a Ticket: https://ticket.coreboot.org/issues/433 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76955 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* arch/riscv: Add OPENSBI_FW_DYNAMIC_BOOT_HART optionMaximilian Brune2024-02-072-0/+12
| | | | | | | | | | | | | | | 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>
* Update arm-trusted-firmware submodule to upstream masterYidi Lin2024-02-071-0/+0
| | | | | | | | | | | | | | | | Updating from commit id 23d6774ab: 2024-01-16 09:47:43 +0100 - (Merge "feat(qemu-sbsa): mpidr needs to be present" into integration) to commit id 17bef2248: 2024-02-05 23:33:50 +0100 - (Merge "feat(fvp): delegate FFH RAS handling to SP" into integration) This brings in 142 new commits. Change-Id: If89a3f0d32180ff7ae0a6b447687b9749dfab2ea Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80352 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
* mb/google/brya/var/xol: Update GPIO configurationsSeunghwan Kim2024-02-072-0/+213
| | | | | | | | | | | | | | | | Upload initial GPIO configuration for xol based on proto schematics. BUG=b:319506033 BRANCH=firmware-brya-14505.B TEST=FW_NAME=xol emerge-brya coreboot chromeos-bootimage xol proto board can boot to ChromeOS Change-Id: I224e58628e44571c07ce034136d690587e62be08 Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80325 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* mb/google/brya/var/xol: Update Kconfig and devicetreeSeunghwan Kim2024-02-072-2/+429
| | | | | | | | | | | | | | | | Upload the initial devicetree and update Kconfig for xol following proto schematics. BUG=b:319506033 BRANCH=firmware-brya-14505.B TEST=FW_NAME=xol emerge-brya coreboot Change-Id: I411932eb4872d77993394a290e8afdd1a0038faf Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80324 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
* sb/intel/i82371eb/isa: make IOAPIC ID constFelix Held2024-02-061-1/+1
| | | | | | | | | | | | Since the local IOAPIC ID variable is initialized as 2 and never changed afterwards, so make it const to make this more obvious. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1f19cc43b44a938758a43346f4fa75f8ed39ddea Reviewed-on: https://review.coreboot.org/c/coreboot/+/80349 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* arch/x86/ioapic: always write IOAPIC ID in set_ioapic_idFelix Held2024-02-061-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* soc/intel/xeon_sp/smihandler: Lock SMM_FEATURE_CONTROL on all socketsPatrick Rudolph2024-02-0620-66/+100
| | | | | | | | | | | | | | | | | Remove hardcoded B:D:F numbers for the first socket and pass the PCI addresses to be locked within SMM by using the smm_pci_resource_store. This allows to lock down SMM on all sockets without knowing the actual bus topology or PCI segment group at compile time where the UBOX devices reside on. Tested: SMM is locked on all 4 sockets instead of just one. Change-Id: Ica694911384005681662d3d7bed354a60bf08911 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80247 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* drivers/wifi: Use depends instead of if in KconfigDavid Ruth2024-02-061-4/+1
| | | | | | | | | | | | | Cleanup to make the file follow the same convention after USE_MTCL was added and the depends structure was requested instead of the if guards. Signed-off-by: David Ruth <druth@google.com> Change-Id: I3604b394f999b28de4723337b3b6b4e21139c83b Reviewed-on: https://review.coreboot.org/c/coreboot/+/80307 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
* drivers/wifi: Add MTCL function to ACPI SSDTDavid Ruth2024-02-066-1/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MTCL function provides a country list to the Linux kernel via an ACPI function in SSDT for MediaTek WiFi chipsets that are capable of operating on the 6GHz band. The country list is used to selectively disable 6GHz and 5.9GHz operation based on the country the device is operating in. The function needs to read a binary file and send it as a package via the MTCL method in SSDT for PCIe WiFi with MediaTek chipsets. Change Summary: * Add src/drivers/wifi/generic/mtcl.c to abstract functionaltity related to MTCL * Add write_mtcl_aml function to convert the byte data into the format expected by the MTCL functionality in the Linux kernel. * Add validate_mtcl function to validate that the byte data read in from a file is in the expected format. * Add write_mtcl_function function to read a binary file called "wifi_mtcl".bin" from cbfs, then call validate_mtcl to verify that it is in an expected format, and if so write the aml via acpigen * Add config flag DRIVERS_MTK_WIFI to src/drivers/wifi/generic in order to include MediaTek WiFi specific functionality * Add config flag USE_MTCL which depends on DRIVERS_MTK_WIFI and enables including the specific ACPI function defined in SSDT * Add config flag CONFIG_MTCL_CBFS_FILEPATH which depends on DRIVERS_MTK_WIFI which enables configuring the file to add as "wifi_mtcl.bin" * Add a call to write_mtcl_function to src/drivers/wifi/generic/acpi.c to include the MTCL function in SSDT for MTK WiFi devices when USE_MTCL is enabled. * Add MediaTek VID to src/include/device/pci_ids.h. BUG=b:295544553 TEST=Add Kconfig entry USE_MTCL for pujjo TEST=Add wifi_mtcl_defaults.bin blob to cbfs TEST=Build coreboot for pujjo `emerge-nissa coreboot chromeos-bootimage` TEST=Verify that MTCL defined in the file is present: TEST=`acpidump -b` TEST=`iasl ssdt.dat` TEST=`less ssdt.dsl` TEST=Search for MTCL Signed-off-by: David Ruth <druth@chromium.org> Change-Id: I9b5e7312a44e114270e664b983626faa6cfee350 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80170 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
* soc/intel/common/tcss: Guard disabling MUX with TCSS_HAS_USBC_OPSSean Rhodes2024-02-052-13/+23
| | | | | | | | | | | | | | | | | | Currently, SOC_INTEL_COMMON_BLOCK_TCSS will set MUX to disabled. The two related options to re-configure it for either USB devices or displays, are currently only supported by the ChromeEC. As such, any device without the ChromeEC will boot with attached USB-C devices in a non-functional state. Add TCSS_HAS_USBC_OPS to make this feature configurable, and set the default to enabled if the board features the ChromeEC. Signed-off-by: Sean Rhodes <sean@starlabs.systems> Change-Id: Ia848668ae9af4637fc7cffec9eb694f29d7deba9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79882 Reviewed-by: Kapil Porwal <kapilporwal@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
* drivers/intel/fsp2_0: Remove unused function fsp_write_lineJeremy Compostella2024-02-052-15/+0
| | | | | | | | | | This is just a clean-up commit. Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec97 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80302 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
* soc/intel/xeon_sp/bootblock: Fix out of order header filesJeremy Compostella2024-02-051-6/+6
| | | | | | | | | Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec96 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80301 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shuo Liu <shuo.liu@intel.com>
* mb/google/brox: Fix the I2C configurationKarthikeyan Ramasubramanian2024-02-051-3/+3
| | | | | | | | | | | | | | | Update the I2C configuration to match the usage such that only required I2C controllers are enabled. BUG=b:319390850 TEST=Build Brox BIOS image and boot to OS. Ensure that only the required I2C controllers are enabled. Change-Id: I9f24beb9ef587163362cc6ded88efb05be1329b9 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80303 Reviewed-by: Shelley Chen <shchen@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* util/kconfig: Uprev to Linux 6.7's kconfigPatrick Georgi2024-02-053-23/+21
| | | | | | | | | | | Just a memory leak fix in Linux 6.7. Change-Id: I1ff302dafa01e78429a30ff18e21ffe0b45ce46e Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80263 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* mb/google/rex/var/karis: Follow rex0 CNVi/PCIe switchingTyler Wang2024-02-031-10/+0
| | | | | | | | | | | | | | | | Follow reference design rex0, keep the GPIO settings of CNVi/PCIe. Only set GPP_F04,GPP_F05/GPP_S01,GPP_S02 to NC when WIFI_PCIE/WIFI_CNVI is selected. BUG=none TEST=Build and test on karis Change-Id: Id23a2cfe0639f2d423980db9badc16c1477434d1 Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80215 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eran Mitrani <mitrani@google.com> Reviewed-by: Subrata Banik <subratabanik@google.com>
* mb/google/rex/var/karis: Update fw_config KB_TYPE fieldTyler Wang2024-02-031-0/+1
| | | | | | | | | | | | | | | | Update element "KB_TYPE_CA" for align fw_config. Only EC will reference KB_TYPE field in fw_config. This CL is just for align fw_config. BUG=none TEST=emerge coreboot pass Change-Id: Ied54f78dddd9dddca1272fc31c9502fc11c61dde Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80331 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Eran Mitrani <mitrani@google.com>
* util/cbmem: Use commonlib ipchksum() algorithmJulius Werner2024-02-022-23/+6
| | | | | | | | | | | | | | This patch switches the cbmem utility from its own IP checksum implementation to the commonlib version (which is good because the old one had a couple of bugs: doesn't work on odd sizes and may overflow its carry accumulator with input larger than 64K). Change-Id: I0bef2c85c37ddd3438b7ac6389e9daa3e4955b31 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80256 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* commonlib: Add assembly optimization for ipchksum() on x86Julius Werner2024-02-021-1/+24
| | | | | | | | | | | | | | | This patch adds a bit of optimized assembly code to the ipchksum() algorithm for x86 targets in order to take advantage of larger load sizes and the add-with-carry instruction. The same assembly (with one minor manual tweak) works for both 32 and 64 bit mode (with most of the work being done by GCC which automatically inserts `rax` or `eax` in the inline assembly depending on the build target). Change-Id: I484620dc14679ff5ca02b2ced2f84650730a6efc Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80255 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* commonlib: Add assembly optimization for ipchksum() on arm64Julius Werner2024-02-021-0/+25
| | | | | | | | | | | | | | This patch adds a bit of optimized assembly code to the ipchksum() algorithm for arm64 targets in order to take advantage of larger load sizes and the add-with-carry instruction. This improves execution speed on a Cortex-A75 by more than 20x. Change-Id: I9c7bbc9d7a1cd083ced62fe9222592243a796077 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80254 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Yidi Lin <yidilin@google.com>
* libpayload: Switch to commonlib ipchksum() algorithmJulius Werner2024-02-025-94/+4
| | | | | | | | | | | | | This patch moves libpayload over to the commonlib implementation for calculating the IP checksum. Change-Id: Ie8d323ce9f8d946758619761b4b22d54bce222b6 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80253 Reviewed-by: Jakub Czapiga <czapiga@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Yidi Lin <yidilin@google.com>
* tests: Add some more ipchksum() test casesJulius Werner2024-02-021-0/+30
| | | | | | | | | | | | | This patch adds a few more test cases for the IP checksum algorithm to catch more possible corner cases (large data with more than 64K carries, unaligned data, checksum addition with offset, etc.). Change-Id: I39b4d3f1bb833894985649872329eec88a02a22c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80252 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Jakub Czapiga <czapiga@google.com>
* lib: Move IP checksum to commonlibJulius Werner2024-02-0223-128/+119
| | | | | | | | | | | | | | | | | | | | | | 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>
* soc/amd: commonize PCI root IOAPIC initializationFelix Held2024-02-0214-41/+36
| | | | | | | | | | | | | | | | | | | Make the initialization of the IOAPIC(s) in the PCI root(s) common across all AMD family 17h+ SoCs. For this the more general implementation from the Genoa code that supports multiple PC roots is moved to the common AMD code. All other family 17h+ SoCs are then adapted to use the common code. For those non-Genoa SoCs, the initialization of this second IOAPIC is moved from the northbridge device to the domain device above to match Genoa. Test=Both the FCH IOAPIC and the PCIe root IOAPIC are still initialized on Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7c0ec6ac2f11cb11e46248cceec96c1fd2a49c16 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80286 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* mb/amd/birman: add Phoenix with openSIL mainboard optionFelix Held2024-02-024-2/+155
| | | | | | | | | | | | | Introduce BOARD_AMD_BIRMAN_PHOENIX_OPENSIL which selects the openSIL based Phoenix SoC code. Since the Phoenix chip.c is different due to some FSP-specific data structures in there that are guarded in the openSIL case, a separate devicetree for the openSIL case is added. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I248102e92818b2d395d561a4bf2627f80906b2f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80299 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
* soc/amd/phoenix/chip.h: guard FSP-specific data structuresFelix Held2024-02-021-0/+4
| | | | | | | | | | | | Since the USB configuration data structure is FSP-specific, add guards on this part of the soc_amd_phoenix_config struct and the corresponding include. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6c324421fbc3dc7b9a7bf6f5868785e9718147a5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80298 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/amd/phoenix/fch: only init ACPI IO ports in FSP caseFelix Held2024-02-021-4/+6
| | | | | | | | | | | Since openSIL configures the APCI IO port addresses, coreboot should not overwrite them. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If10e5a9f52ab313ad1afebd7f9e722994d48b0a7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80297 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/amd/phoenix: add openSIL callsFelix Held2024-02-023-6/+20
| | | | | | | | | | | Add the calls to the openSIL stubs to do the silicon initialization, to get the APCI IO ports, and to get the memory map. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6f37bf211e130cb44927f8a0e7f9134d246dfc1c Reviewed-on: https://review.coreboot.org/c/coreboot/+/80296 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/amd/phoenix/fch: only call gpp_clk_setup in FSP caseFelix Held2024-02-021-1/+3
| | | | | | | | | | | | | | | | | The configuration of the PCIe clock generators in the FCH was moved from the FSP to coreboot, since all registers are documented. This initialization is however tightly integrated in the rest of the PCIe init code inside the reference code. In the FSP case, this code was manually removed. openSIL will do that part of the initialization so that there's no coreboot-specific change needed in openSIL. This will also avoid the problems caused by mismatching configurations done by the coreboot code and the PCIe init part of the reference code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6d64285a301ade6860c07e62dcb1a718e7a96644 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80295 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>