summaryrefslogtreecommitdiff
path: root/src/device
AgeCommit message (Collapse)Author
2024-01-24device, security: 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: I41f8a9b5d1bdb647a915da1a5e95161b2e34df28 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80082 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-24device/device_util: Add method to retrieve the domainPatrick Rudolph
Add a function to return the PCI domain device for the specified device. On multi PCI domain platforms this function allows to determine which domain and thus which socket the PCI device belongs to. Change-Id: I0068b82e139fe7a35e6b1b91b7d386b750c80748 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80090 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>
2024-01-22device/device_util: Print full domain IDPatrick Rudolph
Print the whole 32bit of the domain ID. Change-Id: Iae0752f3ae8ed683d4f61c7a47d0dee223a1ba22 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80098 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-21device_util: Drop unused function bus_pathArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Id23a291af20473c3b3e67178b66fcde920d49984 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80097 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2024-01-19device/Kconfig: Move Intel/ACPI/USB4 specific Kconfig optionsArthur Heymans
This options should not be visible on !Intel, !ACPI and !USB4. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ia515d52baead9e151533278c33fda9436ee56168 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79669 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-15device/Kconfig: handle ECAM_MMCONF_BUS_NUMBER being 32Felix Held
Provide a default for the ECAM_MMCONF_LENGTH Kconfig option for the ECAM_MMCONF_BUS_NUMBER option being set to 32. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I01e7da5d49f296dde2de41e23e86e3f49fe78193 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79974 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2024-01-12device/Kconfig: Add an option to allocate above 4G by defaultArthur Heymans
Historically resource allocation in coreboot was 32bit x86 thing. To remain compatible with this behavior (e.g. to keep 32bit payloads happy), resource allocation limits resources to 32 bits unless explicitly overridden. However this behavior is not always appropriate: e.g. on non x86 platforms the PCIe mem decode window could be above 4G. Another case on x86 is where the decode window(s) below 4G are not adequate for fitting all resources and the payload is 64bit capable (e.g. Linux). This adds a Kconfig flag to override the behavior to limit resources to 32bit by default and to allocate resources according to the real hardware limits. TEST=intel/archercity CRB Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I01218a8a3efc4a5f8ba344808949ca6b8898525f Reviewed-on: https://review.coreboot.org/c/coreboot/+/78331 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> Reviewed-by: Shuo Liu <shuo.liu@intel.com>
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-20device/i2c_bus.c: Check pointer for NULL before using itMartin Roth
Found-by: Coverity Scan #1489753 Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I4f3794cf17875cdb35010c79a6537a4c13a18224 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78615 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-12-19device: Drop MULTIPLE_VGA_ADAPTERS KconfigNico Huber
This option is nowhere selected and there is only a single case left where it's used. Guarding the check in pci_rom_load() seems like a bad idea: As the code would be copying all VGA ROMs to the same location, it would be only working by chance (if the last encoun- tered ROM is the right one). Hence, drop the guard and always check for the correct device. Change-Id: Ib283bf0a65367b99099a3bfcbd27585d44235eb9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79596 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-10device/Kconfig: rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORTFelix Held
Rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORT and add a help text to this Kconfig option to clarify what this option is about. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71e36869c6ebf77f43ca78f5e451aebfb59f1c74 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78986 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-10-25device/dram/ddr3.c: Check SPD byte before using as a divisorMartin Roth
The Medium Time Base (MTB) value is calculated by dividing one SPD byte by another. Return an error if the divisor is zero before using the value for division. Found-by: Coverity Scan #1469303 Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic0a70291c42b5c2d21d65de92487b2dd88609983 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78613 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-10-20device/device.h: Rename pci_domain_scan_busArthur Heymans
On all targets the domain works as a host bridge. Xeon-sp code intends to feature multiple host bridges below a domain, hence rename the function to pci_host_bridge_scan_bus. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Yidi Lin <yidilin@google.com>
2023-09-08arch to drivers/intel: Fix misspellings & capitalization issuesMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-06device/pci_rom: rename pci_rom_acpi_fill_vfct()Matt DeVillier
Rename pci_rom_acpi_fill_vfct() to ati_rom_acpi_fill_vfct() to make it clear that the function is only used for AMD/ATI VGA option ROMs. Change-Id: I0e310dd2d7a0432918861632e09a23e162082ea5 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77634 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-06device/pci_rom: Set VBIOS checksum when filling VFCT tableMatt DeVillier
AMD's Windows display drivers validate the checksum of the VBIOS data in the VFCT table (which gets modified by the FSP GOP driver), so ensure it is set correctly after copying the VBIOS into the table if the FSP GOP driver was run. Without the correct checksum, the Windows GPU drivers will fail to load with a code 43 error in Device Manager. Thanks to coolstar for root causing the issue. TEST=build/boot Win11 on google/skyrim (frostflow), ensure GPU driver loaded and functional. Change-Id: I809f87865fd2a25fb106444574b619746aec068d Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Signed-off-by: CoolStar <coolstarorganization@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77628 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2023-08-28src/device/dram/Makefile.inc: specify one file per lineSergii Dmytruk
A trivial follow-up on CB:67060. This makes contents of the file look a bit less regular, but more like the rest Makefile.inc in the code base. Change-Id: I772d37825e4b59cf927637dc39bfb3ee06115860 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77533 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-21device/dram: add DDR4 RCD I2C access functionsKrystian Hebel
Registering Clock Driver (RCD) is responsible for driving address and control nets on RDIMM and LRDIMM applications. Its operation is configurable by a set of Register Control Words (RCWs). There are two ways of accessing RCWs: in-band on the memory channel as MRS commands ("MR7") or through I2C. Access through I2C is generic, while MRS commands are passed to memory controller registers in an implementation-specific way. See JESD82-31 JEDEC standard for full details. Change-Id: Ie4e6cfaeae16aba1853b33d527eddebadfbd3887 Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67060 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-21device/dram: add DDR4 MRS commandsKrystian Hebel
Change-Id: I9d4f048c859bc89897d50a5a07468c3375aa1dcf Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67059 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-15device/oprom/realmode/x86: temporary disable NULL breakpointsFelix Held
Disable NULL breakpoints in setup_realmode_idt before calling write_idt_stub in a loop. TEST=No more spurious Null dereference errors in the console output. Before Mandolin showed these two errors before running the VBIOS: [ERROR] Null dereference at eip: 0x4e6f1a35 [ERROR] Null dereference at eip: 0x4e6f1a4f Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2255d85030e41192ae8a3a7f0f6576c0d373eead Reviewed-on: https://review.coreboot.org/c/coreboot/+/77172 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-15device/pnp_device: Remove return statement from void functionElyes Haouas
Change-Id: Ie766807ae1538b21acf471cfacbfe75cfeead921 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77187 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-14commonlib,console,nb,sb,security: Add SPDX licenses to MakefilesMartin Roth
To help identify the licenses of the various files contained in the coreboot source, we've added SPDX headers to the top of all of the .c and .h files. This extends that practice to Makefiles. Any file in the coreboot project without a specific license is bound to the license of the overall coreboot project, GPL Version 2. This patch adds the GPL V2 license identifier to the top of all makefiles in the commonlib, console, northbridge, security, and southbridge directories that don't already have an SPDX license line at the top. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I02804a10d0b0355e41271a035613d9f3dfb122f8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68985 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-08-09treewide: Get rid of "NO_DDRx" selectionElyes Haouas
Change-Id: I8fa26e7a398eee855c31a76f0f89b4111368c2a6 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76387 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-06device, soc: Add SPDX license headers to MakefilesMartin Roth
To help identify the licenses of the various files contained in the coreboot source, we've added SPDX headers to the top of all of the .c and .h files. This extends that practice to Makefiles. Any file in the coreboot project without a specific license is bound to the license of the overall coreboot project, GPL Version 2. This patch adds the GPL V2 license identifier to the top of all makefiles in the device and soc directories that don't already have an SPDX license line at the top. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I89c05c7c1c39424de2e3547c10661c7e3f58b8f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76951 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Tim Crawford <tcrawford@system76.com>
2023-07-08allocator_v4: Disable top-down allocation for EDK2Nico Huber
EDK2 seems to have problems at least with the resource allocation for Intel's IGD. While the investigation is ongoing, disable top-down allocation by default if the payload is known to be EDK2. Change-Id: I771d8a3b74b54a043624843a00498225d1f509ad Signed-off-by: Nico Huber <nico.h@gmx.de> Ticket: https://ticket.coreboot.org/issues/499 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76373 Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sean Rhodes <sean@starlabs.systems>
2023-06-23commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-06-23allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4GNico Huber
When moving the code to allocate at the top level in commit 9260ea60bfa4 (allocator_v4: Use memranges only for toplevel), a call to restrict the limit of the resource was dropped. Probably by accident in one of the earliest rebases. Without this call to effective_limit(), 64-bit resour- ces at the top level, i.e. PCI bus 0, were always placed above 4G. Even when this was not requested with the IORESOURCE_ABOVE_4G flag. Tested on kontron/ktqm77 where the issue could be reproduced with x86_64. Without the fix, boot hangs when trying to access the GMA MMIO registers of PCI 00:02.0, which were placed above 4G. Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Signed-off-by: Nico Huber <nico.h@gmx.de> Found-by: 9elements QA Reviewed-on: https://review.coreboot.org/c/coreboot/+/76090 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-22allocator_v4: Remove redundant parameterNico Huber
update_bridge_resource() already gets the type passed as part of the resource. Change-Id: I6b3c9809caecdd1bad5b98891a00c3392190a3e0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67022 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
2023-06-22allocator_v4: Manually inline some thin functionsNico Huber
Inline functions that are only called once to improve readability. The calling functions still have rather short bodies, and the reader won't have to look down yet another layer to understand what they are doing. Change-Id: Ib4aa5d61dfa88c804a1aaee028185e00c5fbb923 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65422 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-22allocator_v4: Factor resource printing outNico Huber
Factor all the resource printing out into separate functions. This results in one-liners in the actual program code which hopefully will distract less during reading. Change-Id: I766db379f3b62d641cb3c41ebe0394b60ba57f7a Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65421 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-22allocator_v4: Use memranges only for toplevelNico Huber
During phase 1 of the resource allocation we gather all the size requirements. Starting from the leafs of our devicetree, we cal- culate the requirements per bus, until we reach the resource do- main. However, because alignment plays a role, we can't just accumulate the sizes of all resources on a bus. Instead, we already sort all the resources per bus to predict their relative placement, inclu- ding alignment gaps. Then, phase 2 has to perform the final allo- cations with the exact same relative placement. This patch introduces a very simple mechanism to avoid repeating all the calculations: In phase 1, we note the relative `base` of each resource on a bus. And after we allocated all the resources directly below the domain in phase 2, we add the absolute `base` of bridge resources to the relative `base` of child resources. This saves most of the computational complexity in phase 2. How- ever, with a shallow devicetree with most devices directly below the domain, this won't have a measurable impact. Example after phase 1: domain | `-- bridge #0 | res #0, base 0x000000 (relative), | size 12M, align 8M | |-- device #0 | res #1, base 0x800000 (relative), | size 4M, align 4M | `-- bridge #1 | res #2, base 0x000000 (relative), | size 8M, align 8M | `-- device #1 res #3, base 0x000000 (relative), size 8M, align 8M After phase 2 allocation at the domain level (assuming res #0 got 0xa000000 assigned): domain | `-- bridge #0 | res #0, base 0xa000000 (absolute), | size 12M, align 8M | |-- device #0 | res #1, base 0x800000 (relative), | size 4M, align 4M | `-- bridge #1 | res #2, base 0x000000 (relative), | size 8M, align 8M | `-- device #1 res #3, base 0x000000 (relative), size 8M, align 8M Now, all we need to do is to add the `base` of bridge resources recursively. Starting with resources on the bus below bridge #0: domain | `-- bridge #0 | res #0, base 0xa000000 (absolute), | size 12M, align 8M | |-- device #0 | res #1, base 0xa800000 (absolute), | size 4M, align 4M | `-- bridge #1 | res #2, base 0xa000000 (absolute), | size 8M, align 8M | `-- device #1 res #3, base 0x000000 (relative), size 8M, align 8M And finally for resources on the bus below bridge #1: domain | `-- bridge #0 | res #0, base 0xa000000 (absolute), | size 12M, align 8M | |-- device #0 | res #1, base 0xa800000 (absolute), | size 4M, align 4M | `-- bridge #1 | res #2, base 0xa000000 (absolute), | size 8M, align 8M | `-- device #1 res #3, base 0xa000000 (absolute), size 8M, align 8M Change-Id: I70c700318a85f6760f27597730bc9c9a86dbe6b3 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65420 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-06-22allocator_v4: Treat above 4G resources more nativelyNico Huber
We currently have two competing mechanisms to limit the placement of resources: 1. the explicit `.limit` field of a resource, and 2. the IORESOURCE_ABOVE_4G flag. This makes the resource allocator unnecessarily complex. Ideally, we would always reduce the `.limit` field if we want to "pin" a specific resource below 4G. However, as that's not done across the tree yet, we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint to implicitly lower the `limit` of a resource. In this patch, this is done inside the effective_limit() function that hides the flag from the rest of the allocator. To automatically place resources above 4G if their limit allows it, we have to allocate from top down. Hence, we disable the prompt for RESOURCE_ALLOCATION_TOP_DOWN and turn it on by default. Platforms that are incompatible should be fixed, but can also override the default as a temporary measure. One implication of the changes is that we act differently when a cold-plugged device reports a prefetchable resource with 32-bit limit. Before this change, we would fail to allocate the resource. After this change, it forces everything on the same root port below the 4G line. A possible solution to get completely rid of the IORESOURCE_ABOVE_4G flag would be rules to place resources of certain devices below 4G. For instance, the primary VGA device and storage and HID devices could be made available to a payload that can only address 32 bits. For now, effective_limit() provides us enough abstraction as if the `limit` would be the only variable to consider. With this, we get rid of all the special handling of above 4G resources during phase 2 of the allocator. Which saves us about 20% of the code :D An earlier version of this change (commit 117e43611548) had to be reverted because of missing resource reservations in platform code. This is worked around now with commit ae81497cb6c7 (device/pci: Limit default domain memory window). Change-Id: Ia822f0ce648c7f7afc801d9cb00b6459fe7cebea Signed-off-by: Nico Huber <nico.h@gmx.de> Original-reviewed-on: https://review.coreboot.org/c/coreboot/+/65413 Original-reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Original-reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75012 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-19device/resource_allocator_v4: Remove "ERROR: " from log messageElyes Haouas
It is no longer necessary to explicitly add "ERROR: " in front of BIOS_ERR message. Change-Id: I3ff2081d38f94556481efa02f242795bbfc77517 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75876 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-01device/pci: Limit default domain memory windowNico Huber
When the default pci_domain_read_resources() is used, keep 32-bit memory resources below the limit given by CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT. This serves as a workaround for missing/wrong reservations of chipset resources. This will help to get more stable results from our own allocator, but is far from a complete solution. Indvi- dual platform ASL code also needs to be considered, so the OS won't assign conflicting resources. Most platforms have reserved space between 0xfe000000 and the 4G barrier. So use that as a global default. In case of `soc/intel/common/`, use 0xe0000000 because this is what is advertised in ACPI and there are traces of resources below 0xfe000000 that are unknown to core- boot's C code (PCH_PRESERVED_BASE?). Tested on QEMU/Q35 and Siemens/Chili w/ and w/o top- down allocation. Fixes EHCI w/ top-down in QEMU. Change-Id: Iae0d888eebd0ec11a9d6f12975ae24dc32a80d8c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75102 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-01device/resource_allocator_v4.c: Fix printing unsigned integersArthur Heymans
Use the proper format specifier for unsigned integers. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I5e39377d62981229531027b3153d5b343a0a7538 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75400 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-01device/allocator: Allow for multiple domain resources of a typeArthur Heymans
Don't assume only one IO and one MEM domain resource. Currently the code is awkward for bridge devices where loops over resources are done twice. This would be avoided on top of other patches that improve the allocator (topic:allocator) by adding a top-down mode. However those patches break the tree and having the option to have multiple resources per type would make it easier to get those patches in without breaking the tree. Change-Id: I3d3a60c9a4438accdb06444e2b50cc9b0b2eb009 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67018 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-05-31device/dram: Update RDIMM classification from RIMM to DIMMZiang Wang
Registered DIMM should be 'FORMFACTOR_DIMM' with 'DETAIL_REGISTERED' instead of 'FORMFACTOR_RIMM', RIMM has been EOL for so many years. Memory form factor info is now correct on 4th Gen Xeon server platform with registered DIMM. Signed-off-by: Ziang Wang <ziang.wang@intel.com> Signed-off-by: Kehong Chen <kehong.chen@intel.com> Change-Id: I1eea4717a2d60c6100c262a2284a2ac5109f114a Reviewed-on: https://review.coreboot.org/c/coreboot/+/75489 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-05-19device/Kconfig: Reduce PCIe hotplug bus numbers and IO resourcesArthur Heymans
The rationale behind this change is that multiple nested bridges using a lot of bus numbers and IO resources is not likely to be a common hotplug setup. When there is a large amount of hotplug ports using 32 subordinate busses results in boot failures (e.g. make qemu). 8K IO busses for hotplug devices is also excessive in most use cases when only 64K is available in total (again make qemu results in failure to allocate resources but does boot to payload). Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I8371958037d479e7d2053f49814735e15461ca6e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74774 Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-05-17console: Add format-checking __printf() to die()Nico Huber
Code changes are necessary because `-Wformat` warns about empty format strings by default. Change-Id: Ic8021b70f4cd4875b06f196f88b84940c9a79fe0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75147 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-15device/allocator: Fix format string for resource flags (%lu)Nico Huber
Change-Id: I56ffb82ec417530527ea1ea7e97a593e5bf6b756 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75148 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-04-22lib/version: Move board identification stringsKyösti Mälkki
These strings are now only expanded in lib/identity.c. This improves ccache hit rates slightly, as one built object file lib/version.o is used for all variants of a board. Also one built object file lib/identity.o can become a ccache hit for successive builds of a variant, while the commit hash changes. Change-Id: Ia7d5454d95c8698ab1c1744e63ea4c04d615bb3b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74449 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-20device: Move D3COLD_SUPPORT symbolSean Rhodes
Move D3COLD_SUPPORT to device, so it can be used by multiple SOCs. Signed-off-by: Sean Rhodes <sean@starlabs.systems> Change-Id: Ie92736458ab95374c51346107665dc0fd1e653a4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74404 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-12Revert "device: Add Kconfig options for D3COLD_SUPPORT and NO_S0IX_SUPPORT"Michael Niewöhner
This reverts commit 655f7362e13ca49e3e13a822c916c7dc52573d74. Reason for revert: Apparently, the change was not properly reviewed. It not only contains conflicting name and description of the D3COLD Kconfig, but also creates a conflict between existing devicetree and Kconfig options for D3Cold/S3/S0ix. Change-Id: I56ce8f59f8548fc58bc2b3b07c1314e2eed7061c Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73903 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2023-04-06cpu/x86/topology: Add code to fill in topology on struct pathArthur Heymans
This is needed to generate MADT and SRAT where lapicid for threads need to be added last. When CPUID leaf '0xB' is not present assume some defaults that would result in identical ACPI code generation. Change-Id: I2210eb9b663dd90941a64132aa7154440dc7e5a9 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69222 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06cpu/x86/mp_init.c: Keep track of initial lapic ID inside device_pathArthur Heymans
It's quite confusing to keep track of lapic ID inside the device struct and initial lapic ID inside an array. Change-Id: I4d9f8d23c0b0e5c142f6907593428d8509e4e7bb Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64342 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-09device/Kconfig: explain which PCI ID needs to be used for VGA_BIOS_IDFelix Held
Add a paragraph to the help text for VGA_BIOS_ID to explain which PCI ID needs to be used. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1a0f25481e275b7d190f29f5670cc98443dbe719 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73613 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-09device/pci_rom: rework PCI ID remapping in pci_rom_probeFelix Held
Only call cbfs_boot_map_optionrom/cbfs_boot_map_optionrom_revision once and pass the already remapped PCI ID to it. This avoids the spurious warning that the CBFS file wasn't found from the first cbfs_boot_map_optionrom call in cases where the PCI ID needs to be remapped to get the right ID for which a file in CBFS exists. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If7da78c69dd702280a78996a5823972516e0319b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73612 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-05device/xhci: Add functions to work with resource pointersRobert Zieba
The XHCI device functions currently use functions that require a access to the device tree. Create variant of these functions that can operate with a resource* as an argument and refactor the existing device*-based functions to operate by calling the resource*-based variants. This is useful for stages like SMM that may not have access to the device tree. BRANCH=guybrush BUG=b:186792595 TEST=Ran on skyrim device, verified that XHCI ACPI tables are still generated correctly. Change-Id: If5a74f9529d5dc6031ec968ef5f40a9cad5ffbc4 Signed-off-by: Robert Zieba <robertzieba@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69914 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-03-02device/pciexp_device.c: Do not enable common clock if already activeWerner Zeh
The Common Clock Configuration (CCC) is a PCIe feature for cases where the upstream and downstream device of a link share the same reference clock. After a change in this setting a link re-training is mandatory to make it effective. On recent Intel platforms (tested on Elkhart Lake) the FSP code which is executed before coreboot performs the PCI scan already enumerates all PCI buses for its internal uses. While this is done, all the PCI express features of a link are configured, which includes CCC. If the link supports common clock, FSP performs the link re-training already. When the execution flow is returned to coreboot, the same link treatment is applied again (coded in 'pciexp_tune_dev()') and CCC is enabled a second time, just a few milliseconds after FSP did this already. Because enabling CCC requires a link re-training, there are two link re-trainings on the PCIe link within a few milliseconds (one from the FSP code and one from coreboot) which can lead to issues with a connected PCIe device on this link. In particular, link issues were discovered with a Pericom PCIe switch (PI7C9X2G608) on mc_ehl1 where the link has stalled for a while after the second re-training. This in turn leads to non-initialized PCI devices on the bus after coreboot has finished. This patch checks if CCC is already enabled on a link and does not perform the steps to enable it again in coreboot which safes a link re-training (and thus execution time) and a potential link stability issue. Test=Check log output on mc_ehl1 which shows the following lines: [DEBUG] PCI: pci_scan_bus for bus 09 [DEBUG] PCI: 09:00.0 [8086/1533] enabled [INFO ] PCIe: Common Clock Configuration already enabled Change-Id: I747fa406a120a215de189d7252f160c8ea2e3716 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73310 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-27device/dram/spd.c: Add Nanya's Manufacturer IDMartin Roth
There is a Nanya device used on one of the Google Guybrush devices, so add it to the list of SPD manufacturer names. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ia449f4d14385cdd5a2548e2a05e3928ea3602c12 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73254 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-02-17device: Add Kconfig options for D3COLD_SUPPORT and NO_S0IX_SUPPORTSean Rhodes
Add NO_S0IX_SUPPORT for boards that do not support, or do not want to support S0IX. As all the boards in the tree that do this, don't support D3Cold, add D3COLD_SUPPORT that defaults to `n` when NO_S0IX_SUPPORT is selected to disable D3Cold support. Signed-off-by: Sean Rhodes <sean@starlabs.systems> Change-Id: I03378cc7bb76fd65fcec81018e47f6288d437cd8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73042 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-02-09treewide: Remove repeated wordsElyes Haouas
Found by linter Change-Id: I7a49cce0b56cf83d0e4490733f9190284a314c4a Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72896 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2023-02-06device/pci_device.c: Add way to limit max bus numbersArthur Heymans
By default this limits PCI buses to CONFIG_MMCONF_BUS_NUMBER. Some platforms have multiple PCI root busses (e.g. xeon_sp), where bus numbers are limited. This provides a basic check. On some platforms it looks like programming 0xff to the subordinate bus number confuses and hangs the hardware. Change-Id: I0582b156df1a5f76119a3687886c4d58f2d3ad6f Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59395 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
2023-02-01treewide: Remove duplicated include <device/pci.h>Elyes Haouas
<device/pci.h> chain-includes <device/pci_def.h> & <device/pci_type.h>. Change-Id: I4e5999443e81ee1c4b1fd69942050b47f21f42f8 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72626 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-11device/Kconfig: Fix selection of software connection managerMartin Roth
The patch that introduced the selection of software connection manager, CB:64561 - 060df17f1d (soc/intel/alderlake/acpi: Add Kconfig options for SCM and FCM) added a default to enable the software configuration manager directly in the choice. This leads to warnings when running make menuconfig: src/soc/intel/alderlake/Kconfig:439: warning: defaults for choice values not supported src/soc/intel/meteorlake/Kconfig:337: warning: defaults for choice values not supported src/soc/intel/tigerlake/Kconfig:299: warning: defaults for choice values not supported I'm not sure why the Kconfig linter didn't catch this, but this issue is currently breaking the build for me. This patch fixes it so that instead of setting the default directly, a new Kconfig value is selected that then sets the default correctly. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I674046a93af8f7c2f3003900804deefa89dae295 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71776 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Reviewed-by: Sean Rhodes <sean@starlabs.systems>
2023-01-11drivers/intel/gma: Hook up libgfxinit in romstageJeremy Compostella
A mainboard port needs to: - select `CONFIG_MAINBOARD_HAS_EARLY_LIBGFXINIT' - implement the Ada package `GMA.Mainboard' with a single function `ports' that returns a list of ports to be probed for displays. - set the desired `GFX_GMA_DEFAULT_MMIO' IO memory address to use in romstage (and ramstage) for the graphic device. BUG=b:252792591 BRANCH=firmware-brya-14505.B TEST=libgfxinit compiles in romstage. libgfxinit successfully executes in romstage and ramstage using the requested MMIO setting on skolas. Change-Id: I3c2101de10dc5df54fe873e43bbe0f1c4dccff44 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70276 Reviewed-by: Tarun Tuli <taruntuli@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-08soc/intel/alderlake/acpi: Add Kconfig options for SCM and FCMSean Rhodes
Software Connection Manager doesn't work with Linux 5.13 or later, resulting in TBT ports timing out. Not advertising this results in Firmware Connection Manager being used and TBT works correctly. Add Kconfig options to chose between SCM (Software Connection Manager) and FCM (Firmware Connection Manager). FCM is primary, as it's more compatible save for ChromeOS devices as ChromeOS uses SCM. Linux patch: torvalds/linux@c6da62a c6da62a219d028de10f2e22e93a34c7ee2b88d03 Tested with StarBook Mk VI (i7-1260P). Signed-off-by: Sean Rhodes <sean@starlabs.systems> Change-Id: Iac31d37c0873f41f7b14e1051fe214466d1ebdd8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64561 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-01-04spd.h: Move enum ddr3_module_type to ddr3.hElyes Haouas
Move specific enum ddr3_module_type to <device/dram/ddr3.h>. Change-Id: I8fd7892dda26158a5bdd6cd4972c7859a252153e Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71547 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-04spd.h: Move enum ddr2_module_type to ddr2.hElyes Haouas
Move specific enum ddr2_module_type to <device/dram/ddr2.h>. Change-Id: I748658f9b349bff9b1ebe2c0a6acf71bf2a221ce Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71546 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-12-17device/Kconfig: bump desktop framebuffer max height/width to support 4KMatt DeVillier
Increase the default linear framebuffer max height/width for desktops so that native display resolution works properly on 2160p and 1440p ultrawide displays. TEST=build/boot google/fizz, verify libgfxinit display init works properly on 3440x1440p and 3840x2160p displays. Change-Id: I95a1f1275a4faea195b73997c648023119807958 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70369 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-12-17device/oprom/yabel/io: use __fallthrough instead of commentFelix Held
Unlike gcc, a clang build will fail when only a comment is used to indicate that the fallthough is intended. To fix the clang build, use __fallthrough instead. This will fix the build errors introduced by commit f45c7671d9ed ("Set x86_64 as supported architecture for clang") that enabled clang builds for a case that uses yabel to run the VBIOS. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4ed337025adeb833f352d198fc0f13b5e1c209c4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70889 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-12-14device/cpu_device.c: Zero initialize structArthur Heymans
Don't rely on this being 0. Change-Id: I7c0d16b6a265bf9c7abcfdf2f18a43706ee03ea1 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69752 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-12-10treewide: Include <device/mmio.h> instead of <arch/mmio.h>Elyes Haouas
<device/mmio.h>` chain-include `<arch/mmio.h>: https://doc.coreboot.org/contributing/coding_style.html#headers-and-includes Also sort includes while on it. Change-Id: Ie62e4295ce735a6ca74fbe2499b41aab2e76d506 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-11-24device/mdio: Provide helper functions for read and writeWerner Zeh
This patch provides helper functions to read or write a register via the MDIO bus. They can be used from drivers to easily access registers on the MDIO bus. Change-Id: I293d93435d27269a071b4b9b94a1b55307c575a7 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69611 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-24src/device + util/sconfig: Introduce new device 'mdio'Mario Scheithauer
This patch extends the available device paths with a new device 'mdio'. MDIO is the 'Management Data Input/Output' called interface which is used to access an Ethernet PHY behind a MAC to change settings. The real payload data path is not handled by this interface. To address the PHY correctly on the MDIO bus, there is a 5 bit address needed, which often can be configured via pins on the mainboard. Therefore, the new introduced device has an 'addr' field to define its address. If one wants to use a MDIO device in devicetree, the syntax is straight forward (example): device mdio 0x2 on end As the MDIO interface is driven by the MAC, most likely this MDIO device will be hooked in as a child device of the (PCI attached) MAC device. With the new introduced ops_mdio a new interface is added to provide an API for read and write access over MDIO. Change-Id: I6691f92c4233bc30afc9029840b06f74bb1eb4b2 Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com> Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69382 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-22src/device/pci_: Remove unnecessary space after castsElyes Haouas
Change-Id: I11593245fedc26489e3506d773aaff1ad34188b1 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69804 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-20device/pciexp: add pcie_find_dsn()Jonathan Zhang
Add pcie_find_dsn() to detect and match PCIe device serial number. In addition, vendor ID is matched when provided. Change-Id: I54b6dc42c8da47cd7b4447ab23a6a21562c7618 Signed-off-by: Jonathan Zhang <jonzhang@meta.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54510 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
2022-11-14device/Kconfig: Don't allow native mode in x86_64Arthur Heymans
This option is not working so don't advertise it. Change-Id: I910162756a567289b2484a5445360a3197ae848c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2022-11-12device & commonlib: Update pci_scan_bus postcodesMartin Roth
The function pci_scan_bus had 3 post codes in it: 0x24 - beginning 0x25 - middle 0x55 - end I got rid of the middle postcode and used 0x25 for the code signifying the end of the function. I don't think all three are needed. 0x24 & 0x25 postcodes are currently also used in intel cache-as-ram code. Those postcodes should be adjusted to avoid conflicting. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I19c9d5e256505b64234919a99f73a71efbbfdae3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69201 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-11-10/: Remove "ERROR: "/"WARNING: " prefixes from log messagesElyes Haouas
It is no longer necessary to explicitly add "ERROR: "/"WARNING: " in front of every BIOS_ERR/BIOS_WARN message. Change-Id: I22ee6ae15c3d3a848853c5460b3b3c1795adf2f5 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69405 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2022-11-07device/resource_allocator_v3: Drop codeArthur Heymans
No platform uses this anymore. Change-Id: Ifccb59ae45daa8fec41a9a2d46c628ff24a0c998 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69140 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2022-11-04device/dram: Add kconfig options for memory typesMartin Roth
Currently, we're building support for all memory types into every board, and letting the linker remove anything that isn't needed. This is okay, but it'd be nice to be able to build in just what's actually needed. This change adds options to specify both what is used and what is not. By doing it that way, the default values don't change, but platforms can start removing support for memory types that are not needed. When all platforms (SoCs, CPUs and/or Northbridge chips) specify what memory types they support, the defaults on the options to use a particular memory type can be set to no, and the options not to use a memory type can be removed. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I07c98a702e0d67c5ad7bd9b8a4ff24c9288ab569 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68992 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2022-11-03{device,drivers}: Include <cpu/cpu.h> instead of <arch/cpu.h>Elyes Haouas
Also sort includes. Change-Id: I1727bf56b4090d040aab413006dec7aca0587d44 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69038 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-26src/device: Clean up includesElyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: Idd78271f2158bdc29ce9ac8d81f46ad8cbe84c5e Reviewed-on: https://review.coreboot.org/c/coreboot/+/68205 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-10-12device/dram/ddr2: Use 'enum cb_err' instead of 'int'Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I8ea6e773d858b30d75ff93d4fe07301f3825c1cb Reviewed-on: https://review.coreboot.org/c/coreboot/+/68240 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-10-06include/device/device_util.c: add predicates for pci devicesFabio Aiuto
add functions to check whether a device is enabled pci device or a pci device on a specific bus number. TEST: compile and qemu run successfully Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Change-Id: I3257c8404017372f6cdd9f6cf9453502447343a0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68101 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-06device/device_const.c: Clean up includes and add <types.h>Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I7e84760566db5da7ff88dcbe9fb028ebcb390bdc Reviewed-on: https://review.coreboot.org/c/coreboot/+/68043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2022-09-29treewide: use is_enabled_cpu() on cycles over device listFabio Aiuto
use is_enabled_cpu() on cycles over device list to check whether the current device is enabled cpu. TEST: compile test and qemu run successfully with coreinfo payload Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Change-Id: If64bd18f006b6f5fecef4f606c1df7d3a4d42883 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67797 Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-09-29include/device/path.h: use functions for enabled cpu selectionFabio Aiuto
Add function defs and prototypes of functions checking whether a device is {a cpu,an enabled cpu} TEST: compile test and qemu executed successfully with coreinfo payload Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Change-Id: Iabc0e59d604ae4572921518a8dad47dc3d149f81 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67502 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-09-13device/dram: Reformat codeElyes Haouas
Most of these changes are suggested by clang-format(13.0-54) tool on Debian testing. Change-Id: I9bf5f516db4f12ffe1e9a714c7a8ae179c12b149 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64780 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-09-12device: Clear lane error statusWilson Chou
Refer to PCI Express Base rev6.0 v1.0, 4.2.7 Link Training and Status State Rules, Lane Error Status is normal to record the error when link training. To make sure Lane Error Status is correct in OS runtime, add a Kconfig PCIEXP_LANE_ERR_STAT_CLEAR that clears the PCIe lane error status register at the end of PCIe link training. Test=On Crater Lake, lspci -vvv shows bb:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) (prog-if 00 [Normal decode]) Capabilities: [a30 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: LaneErr at lane: 0 Signed-off-by: Wilson Chou <Wilson.Chou@quantatw.com> Change-Id: I6344223636409d8fc25e365a6375fc81e69f41a5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67264 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
2022-09-08device/pci_device: Add missing spaces to log messagesPaul Menzel
Add the missing spaces to two log message, like the one below. WARNING: Device PCI: 03:00.0 requests a BAR with34 bits of address space, which coreboot is notconfigured to hand out, truncating to 29 bits Change-Id: If933d8fb0db5b58ff12f043cc73172a3f6ffc624 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67370 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-09-06allocator_v4: Disable top-down mode by defaultNico Huber
The top-down allocation feature was merged prematurely before platforms that don't report their resources correctly were fixed. Let's turn it off by default. Change-Id: I982e6d7355b9e689de10357d6c16ed718705270e Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67328 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2022-09-05Revert "allocator_v4: Treat above 4G resources more natively"Nico Huber
This reverts commit 117e436115484f0ce184114b22b716616592e77e. Depends on top-down allocation to keep the behavior to place hot-plug reservations above 4G. The latter was merged prema- turely, though. Change-Id: I5721cb84b29fc42240dff94f49a94461d88e7fbc Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67329 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2022-09-04allocator_v4: Treat above 4G resources more nativelyNico Huber
We currently have two competing mechanisms to limit the placement of resources: 1. the explicit `.limit` field of a resource, and 2. the IORESOURCE_ABOVE_4G flag. This makes the resource allocator unnecessarily complex. Ideally, we would always reduce the `.limit` field if we want to "pin" a specific resource below 4G. However, as that's not done across the tree yet, we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint to implicitly lower the `limit` of a resource. In this patch, this is done inside the effective_limit() function that hides the flag from the rest of the allocator. To automatically place resources above 4G if their limit allows it, we have to allocate from top down. Hence, we disable the prompt for RESOURCE_ALLOCATION_TOP_DOWN if resources above 4G are requested. One implication of the changes is that we act differently when a cold-plugged device reports a prefetchable resource with 32-bit limit. Before this change, we would fail to allocate the resource. After this change, it forces everything on the same root port below the 4G line. A possible solution to get completely rid of the IORESOURCE_ABOVE_4G flag would be rules to place resources of certain devices below 4G. For instance, the primary VGA device and storage and HID devices could be made available to a payload that can only address 32 bits. For now, effective_limit() provides us enough abstraction as if the `limit` would be the only variable to consider. With this, we get rid of all the special handling of above 4G resources during phase 2 of the allocator. Which saves us about 20% of the code :D Change-Id: I4c7fcd1f5146f6cc287bd3aa5582da55bc5d6955 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65413 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-09-04pciexp_device: Propagate above-4G flag to all hotplug devicesNico Huber
The `IORESOURCE_ABOVE_4G` flag was only explicitly set for our dummy device that reserves resources behind a hotplug port. The current re- source allocator implicitly extends this to all devices below the port, including real ones. Let's make that explicit, so future changes to the allocator can't break this rule. Change-Id: Id4c90b60682cf5c8949cde25362d286625b3e953 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66719 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2022-09-04allocator_v4: Introduce RESOURCE_ALLOCATION_TOP_DOWNNico Huber
Add option to resource allocator v4 that restores the top-down allocation approach at the domain level. This makes it easier to handle 64-bit resources natively. With the top-down approach, resources that can be placed either above or below 4G would be placed above, to save precious space below the 4G boundary. Change-Id: Iaf463d3e6b37d52e46761d8e210034fded58a8a4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41957 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Subrata Banik <subratabanik@google.com>
2022-09-04device/i2c_bus: Add routines to read and write multiple bytesWerner Zeh
Some devices require that several bytes are written with a single I2C write command. Extend the i2c_bus interface functions and add both, read and write for more than one byte at a defined byte offset. Change-Id: I0eec2e1d4185170f02b4ab35aa6546dc69569303 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67098 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
2022-08-31device/dram/ddr4.c: note that dimm size calculation won't work for 3DSKrystian Hebel
Change-Id: I52548e544165b4732d9989da6455c8fd77bf99d3 Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67185 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2022-08-31device/dram/ddr4.c: fill missing ECC info from SPDKrystian Hebel
Change-Id: I80fccfa6d108b68d6f33a3d47766205b423a41ff Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67058 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2022-08-31allocator_v4: Completely ignore resources with 0 limitNico Huber
It seems pass 1 and 2 were inconsistent. The first would account for resources with a limit of 0 even though the second can't assign anything for them. Change-Id: I86fb8edc8d4b3c9310517e07f29f73a6b859a7c4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65402 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-08-29pciexp: Move PCI path check one level up to pciexp_enable_ltr()Nico Huber
If we have a PCIe root port without `ops_pci` or without `get_ltr_max_latencies`, the parent device wouldn't be PCI. Hence, check for a PCI path early. Change-Id: I358cb6756750bb10d0a23ab7133b917bfa25988b Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-08-25device/dram: Add function to convert freq to MT/s for (LP)DDR5Matt DeVillier
As the frequency field in the SMBIOS type 17 table is deprecated, we need to provide the maximum and configured speed in MT/s. Add a method to convert from frequency to MT/s using a lookup table. BUG=b:239000826 TEST=Build and verify with other patches in train Change-Id: I0402b33a667f7d72918365a6a79b13c5b1719c0d Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66953 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2022-08-17pciexp_device: Fix offset handling for extended capabilitiesNico Huber
The PCIe spec explicitly states that the bottom-two bits of the next offset are reserved for future use and should be masked. We can also change the loop condition to avoid wrong offsets below 0x100 (exten- ded capabilities always reside in the extended config space). The whole patch series was tested on Google Samus and keeps the L1ss configuration of the WiFi device in tact. Change-Id: I0b622a0ce0a4a1127d266226ade0ec1e66e9fb79 Signed-off-by: Nico Huber <nico.h@gmx.de> Tested-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66459 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-17pciexp: Refactor extended capability handlingNico Huber
Add some inline functions for the bit-wise operations, change the loop body to an if-bail-out style and remove stateful variables. Change-Id: Ia8db915f375737064e3486d313383d9b6c3eb2b8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66458 Reviewed-by: Bill XIE <persmule@hardenedlinux.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-17pciexp_device: Drop quirk handling in pciexp_get_ext_cap_offset()Nico Huber
Keeping these checks in generic code seems rather dangerous. In theory, it could lead to endless loops even for compliant devices, if we accidentally detect arbitrary register contents as capability and use them as a pointer to another one. Not to forget that the register reads can have side effects. All users of this `cafe` have been converted to use pciexp_find_ext_vendor_cap(). Change-Id: I70d21534e04282a4156572a290b83c46be085e0c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66456 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-17pciexp_device: Properly search for Intel's 0xcafe capabilityNico Huber
We have this quirk in our tree since the introduction of L1-substate support[1]. The way we searched for this capability was rather crude: We simply assumed that it would show up in the first data word of another capability. As it turned out that it is actually a proper vendor-specific capa- bility that we are looking for, we can drop some of the mystic code. This was confirmed to work on the device that was originally used during development, Google/Samus. [1] commit 31c6e632cf (PCIe: Add L1 Sub-State support.) Change-Id: I886fb96e9a92387bc0e2a7feb746f7842cee5476 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66455 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-08-17pciexp_device: Introduce pciexp_find_ext_vendor_cap()Nico Huber
Vendors can choose to add non-standard capabilities inside a Vendor-Specific Extended Capability. These are identified by the Extended Capability ID 0x0b. Change-Id: Idd6dd0e98bd53b19077afdd4c402114578bec966 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66454 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-08-17pciexp_device: Join pciexp_find_(next_)extended_cap() APIsNico Huber
Move the `offset` parameter into pciexp_find_extended_cap(). If it's called with `0`, we start a new search. If it's an existing offset, we continue the search. This makes it easier to search for multiple occurences of a capa- bility in a single loop. Change-Id: I80115372a82523b90460d97f0fd0fa565c3f56cb Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66453 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 14:30:12 +0000