summaryrefslogtreecommitdiffstats
path: root/src/device/Kconfig
Commit message (Collapse)AuthorAgeFilesLines
* device/Kconfig: Move Intel/ACPI/USB4 specific Kconfig optionsArthur Heymans2024-01-191-30/+0
| | | | | | | | | | | 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>
* device: Add support for multiple PCI segment groupsFelix Held2024-01-161-0/+9
| | | | | | | | | | | | | | | | | | 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>
* device/Kconfig: handle ECAM_MMCONF_BUS_NUMBER being 32Felix Held2024-01-151-0/+1
| | | | | | | | | | | | | 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>
* device/Kconfig: Add an option to allocate above 4G by defaultArthur Heymans2024-01-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* device: Drop MULTIPLE_VGA_ADAPTERS KconfigNico Huber2023-12-191-4/+0
| | | | | | | | | | | | | | | 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>
* device/Kconfig: rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORTFelix Held2023-11-101-2/+7
| | | | | | | | | | | | 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>
* allocator_v4: Disable top-down allocation for EDK2Nico Huber2023-07-081-2/+5
| | | | | | | | | | | | | | 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>
* allocator_v4: Treat above 4G resources more nativelyNico Huber2023-06-221-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* device/pci: Limit default domain memory windowNico Huber2023-06-011-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* device/Kconfig: Reduce PCIe hotplug bus numbers and IO resourcesArthur Heymans2023-05-191-6/+4
| | | | | | | | | | | | | | | | | | 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>
* device: Move D3COLD_SUPPORT symbolSean Rhodes2023-04-201-0/+14
| | | | | | | | | | | | 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>
* Revert "device: Add Kconfig options for D3COLD_SUPPORT and NO_S0IX_SUPPORT"Michael Niewöhner2023-04-121-13/+0
| | | | | | | | | | | | | | | 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>
* device/Kconfig: explain which PCI ID needs to be used for VGA_BIOS_IDFelix Held2023-03-091-0/+4
| | | | | | | | | | | | 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>
* device: Add Kconfig options for D3COLD_SUPPORT and NO_S0IX_SUPPORTSean Rhodes2023-02-171-0/+13
| | | | | | | | | | | | | | | 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>
* device/Kconfig: Fix selection of software connection managerMartin Roth2023-01-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drivers/intel/gma: Hook up libgfxinit in romstageJeremy Compostella2023-01-111-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* soc/intel/alderlake/acpi: Add Kconfig options for SCM and FCMSean Rhodes2023-01-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* device/Kconfig: bump desktop framebuffer max height/width to support 4KMatt DeVillier2022-12-171-2/+4
| | | | | | | | | | | | | | | | 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>
* device/Kconfig: Don't allow native mode in x86_64Arthur Heymans2022-11-141-1/+1
| | | | | | | | | | 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>
* device/resource_allocator_v3: Drop codeArthur Heymans2022-11-071-20/+0
| | | | | | | | | | | | 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>
* device/dram: Add kconfig options for memory typesMartin Roth2022-11-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* device: Clear lane error statusWilson Chou2022-09-121-0/+7
| | | | | | | | | | | | | | | | | | | | | 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>
* allocator_v4: Disable top-down mode by defaultNico Huber2022-09-061-1/+4
| | | | | | | | | | | | | | | 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>
* Revert "allocator_v4: Treat above 4G resources more natively"Nico Huber2022-09-051-1/+1
| | | | | | | | | | | | | | | | 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>
* allocator_v4: Treat above 4G resources more nativelyNico Huber2022-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* allocator_v4: Introduce RESOURCE_ALLOCATION_TOP_DOWNNico Huber2022-09-041-0/+5
| | | | | | | | | | | | | | | | | | 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>
* payloads/tianocore: Rename TianoCore to edk2Sean Rhodes2022-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | coreboot uses TianoCore interchangeably with EDK II, and whilst the meaning is generally clear, it's not the payload it uses. EDK II is commonly written as edk2. coreboot builds edk2 directly from the edk2 repository. Whilst it can build some components from edk2-platforms, the target is still edk2. [1] tianocore.org - "Welcome to TianoCore, the community supporting" [2] tianocore.org - "EDK II is a modern, feature-rich, cross-platform firmware development environment for the UEFI and UEFI Platform Initialization (PI) specifications." Signed-off-by: Sean Rhodes <sean@starlabs.systems> Change-Id: I4de125d92ae38ff8dfd0c4c06806c2d2921945ab Reviewed-on: https://review.coreboot.org/c/coreboot/+/65820 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* payloads/external: Add support for coreDOOM payloadNicholas Chin2022-05-281-0/+1
| | | | | | | | | | | | | | | | | | coreDOOM is a port of DOOM to libpayload, based on the doomgeneric source port. It renders the game to the coreboot linear framebuffer, and loads WAD files from CBFS. Tested with QEMU i440fx/q35 and a Dell Latitude E6400 using the libgfxinit provided linear framebuffer. Project page: https://github.com/nic3-14159/coreDOOM Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> Change-Id: Ice0403b003a4b2717afee585f28303c2f5abea5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/57222 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Martin L Roth <gaumless@tutanota.com>
* i2c: Add configurable I2C transfer timeoutJes Klinke2022-03-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces CONFIG_I2C_TRANSFER_TIMEOUT_US, which controls how long to wait for an I2C devices to produce/accept all the data bytes in a single transfer. (The device can delay transfer by stretching the clock of the ack bit.) The default value of this new setting is 500ms. Existing code had timeouts anywhere from tens of milliseconds to a full second beween various drivers. Drivers can still have their own shorter timeouts for setup/communication with the I2C host controller (as opposed to transactions with I2C devices on the bus.) In general, the timeout is not meant to be reached except in situations where there is already serious problem with the boot, and serves to make sure that some useful diagnostic output is produced on the console. Change-Id: I6423122f32aad1dbcee0bfe240cdaa8cb512791f Signed-off-by: Jes B. Klinke <jbk@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/62278 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* treewide: Get rid of CONFIG_AZALIA_MAX_CODECSElyes Haouas2022-02-221-8/+0
| | | | | | | | | | | | | Get rid of Kconfig symbol introduced at commit 5d31dfa8 High Definition Audio Specification Revision 1.0a says, there are 15 SDIWAKE bits. Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: Ib8b656daca52e21cb0c7120b208a2acdd88625e1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62202 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Add support for PCIe Resizable BARsTim Wawrzynczak2022-02-161-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can indicates support for "Resizable BARs" via a PCIe extended capability. When support this capability is indicated by the device, the size of each BAR is determined in a different way than the normal "moving bits" method. Instead, a pair of capability and control registers is allocated in config space for each BAR, which can be used to both indicate the different sizes the device is capable of supporting for the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and to also inform the device of the size that the allocator actually reserved for the MMIO range. This patch adds a Kconfig for a mainboard to select if it knows that it will have a device that requires this support during PCI enumeration. If so, there is a corresponding Kconfig to indicate the maximum number of bits of address space to hand out to devices this way (again, limited by what devices can support and each individual system may want to support, but just like above, this number can range from 20 to 63) If the device can support more bits than this Kconfig, the resource request is truncated to the number indicated by this Kconfig. BUG=b:214443809 TEST=compile (device with this capability not available yet), also verify that no changes are seen in resource allocation for google/brya0 before and after this change. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I14fcbe0ef09fdc7f6061bcf7439d1160d3bc4abf Reviewed-on: https://review.coreboot.org/c/coreboot/+/61215 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
* Rename ECAM-specific MMCONF KconfigsShelley Chen2021-11-101-15/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the MMCONF Kconfigs only support the Enhanced Configuration Access mechanism (ECAM) method for accessing the PCI config address space. Some platforms have a different way of mapping the PCI config space to memory. This patch renames the following configs to make it clear that these configs are ECAM-specific: - NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT - MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT - MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS - MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER - MMCONF_LENGTH --> ECAM_MMCONF_LENGTH Please refer to CB:57861 "Proposed coreboot Changes" for more details. BUG=b:181098581 BRANCH=None TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max Make sure Jenkins verifies that builds on other boards Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* src/acpi to src/lib: Fix spelling errorsMartin Roth2021-10-051-1/+1
| | | | | | | | | | | | These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/mipi: Move to drivers/mipiJulius Werner2021-08-261-2/+0
| | | | | | | | | | | | | | Sounds like we prefer to have this under drivers/ instead of device/. Also move all MIPI-related headers out from device/ into their own directory. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib3e66954b8f0cf85b28d8d186b09d7846707559d Reviewed-on: https://review.coreboot.org/c/coreboot/+/57128 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Move MIPI panel library from mainboard/google/kukui into commonJulius Werner2021-08-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | All boards that are trying to use MIPI panels eventually run into the problem that they need to store physical parameters and a list of DCS initialization commands for each panel, and these commands can be very different (e.g. a large amount of very short commands, a few very large commands, etc.). Finding a data format to fit all these different cases efficiently into the same structures keeps being a challenge, and the Kukui mainboard already once put a lot of effort into designing a clean, flexible and efficient solution for this. This patch moves that framework into a common src/device/mipi/ library where it can be used by other boards as well. (Also, this will hopefully allow us to save some duplicated work when using the same panel on different boards at some point.) Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I877f2b0c7ab984412b288e2ed27f37cd93c70863 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56965 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* device/azalia_device.c: Add option to lock down GCAPAngel Pons2021-04-191-0/+9
| | | | | | | | | | | | | | | On Intel 6-series PCHs, the GCAP register is R/WO (Read / Write Once), and needs to be written to after the HD Audio controller is taken out of reset. Add a Kconfig option to read and write back GCAP in order to lock it down. Follow-up commits will select this option when switching platforms to use common Azalia code, to preserve original behaviour. Change-Id: I70bab20816fb6c0bf7bff35c3d2f5828cd96172d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50794 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* device/Kconfig: Adapt PCIEXP_HOTPLUG_BUSESNico Huber2021-04-181-0/+2
| | | | | | | | | | | | | | | | | | The default of 32 buses per hotplug bridge is rather high. Especially for platforms that limit MMConf space to 64 buses: they run out of numbers if there is more than a single hotplug bridge. Lower the default to * 8 if MMConf is limited to 64 or less buses, * 16 if MMConf is limited to 128 or less buses. Change-Id: I06d522dd92ceea9f4798273b26f947a5333800c3 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52069 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/azalia_device.c: Introduce AZALIA_MAX_CODECSAngel Pons2021-03-241-0/+8
| | | | | | | | | | | Add the AZALIA_MAX_CODECS Kconfig option and use it. Change-Id: Ibb10c2f2992257bc261e6cb35f11cc4b2d956054 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51640 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
* device: Add unit to Kconfig option name: `PRE_GRAPHICS_DELAY_MS`Paul Menzel2021-02-151-1/+1
| | | | | | | | | | | It’s good practice to put the unit into the name. Change-Id: I1493f61d4e495c22f09abf1829bb2eab9b1fd2b6 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50517 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* soc/intel/broadwell: Conditionally skip PRE_GRAPHICS_DELAYKyösti Mälkki2021-02-061-0/+10
| | | | | | | | | | | | | | | | | | It was commented that the need for the delay was mainly related to external displays and only with VBIOS execution. Move the delay such that it is done only when we actually need to execute the VBIOS aka option rom. A delay is currently only defined for librem/purism_bdw in its Kconfig. As the description of the issue sounds like it would equally happen on other platforms when VBIOS is involved, promote the Kconfig visible option to global scope. Change-Id: I4503158576f35057373f003586bbf76af4d59b3d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48787 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* device/Kconfig: Introduce MMCONF_LENGTHAngel Pons2021-01-301-0/+8
| | | | | | | | | | | | This is necessary because ASL Memory32Fixed values cannot contain operations, even if they can be evaluated to constants. Add a sanity check in pci_mmio_cfg.h to ensure consistency with MMCONF_BUS_NUMBER. Change-Id: I8f0b5edf166580cc12c1363d8d6b6ef0f2854be9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50033 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/Kconfig: Declare MMCONF symbols' type onceAngel Pons2021-01-291-0/+8
| | | | | | | | | | | Only specify the type of MMCONF_BASE_ADDRESS and MMCONF_BUS_NUMBER once. Change-Id: Iacd2ed0dae5f1fb6b309124da53b3fa0eef32693 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50032 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Add new Kconfig VGA_ROM_RUN_DEFAULT for mainboard userSubrata Banik2021-01-101-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Platform can now select VGA_ROM_RUN_DEFAULT Kconfig to perform graphics initialization for PCI-E based discrete card through VGA OpRom (SoC or Mainboard user can't select VGA_ROM_RUN directly because it's part of choice option). (Note: Some payloads, like SeaBIOS, are also able to run Option ROMs, so coreboot does not need to enable VGA_ROM_RUN Kconfig) For payload like depthcharge, create VGA_ROM_RUN_DEFAULT Kconfig for mainboard to select design with DGPU where OpROM is embedded inside the DGPU card. Allow auto selection of VGA_ROM_RUN_DEFAULT from VGA_BIOS Kconfig. Also NO_GFX_INIT Kconfig to avoid running VGA_ROM_RUN by default in case SeaBIOS is used. TEST=Able to get Pre-OS splash screen with AMD Radeon RX 5700 PCI-E DGPU when mainboard user selects VGA_ROM_RUN_DEFAULT. Change-Id: Iecb2fcdb105af449bc20ad727759cdef17d5e376 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49016 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Drop unused HyperTransport codeAngel Pons2020-11-251-12/+0
| | | | | | | | | | Only two definitions are actually used somewhere, the rest is unused. Change-Id: Iec52d0d47fce6a1ec5455b670824b995a7a34a4c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47407 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Allow configuring bus mastering for PCI bridges conditionallyFelix Singer2020-11-161-0/+11
| | | | | | | | Change-Id: Ic7cacce28f473dda76ca203016dbb8e00149a990 Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Rework bus master optionFelix Singer2020-11-021-0/+11
| | | | | | | | | | | | | As an intermediate step for CB:45150, add an additional Kconfig option which is used to configure bus mastering for any devices and use PCI_ALLOW_BUS_MASTER to allow coreboot setting the bus mastering bit in general. Change-Id: I33b37a79022007a16e97350db61575b63fa8256b Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45149 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Rephrase bus master Kconfig optionFelix Singer2020-10-271-1/+1
| | | | | | | | | Change-Id: I902915133035fb2adff7edd9c931d4b1d3e7dc40 Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46341 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* lint: check for misuse of Kconfig SUBSYSTEM_*_IDMichael Niewöhner2020-09-201-0/+6
| | | | | | | | | | | | | | | | | | | Check that nobody misuses the Kconfigs SUBSYSTEM_*_ID. They are meant to be used for overriding the devicetree subsystem ids locally but shall not be added to a board's Kconfig. Instead, the devicetree option `subsystemid` should be used. Add a linter script for this that finds and warns about such misuse. Also add a note in the Kconfigs' description. TEST=CB:45513 Change-Id: I21c021c718154f1396f795a555af47a76d6efe03 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45513 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Add method to configure bus mastering based on KconfigFelix Singer2020-08-311-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The bus master bit is set at many places in coreboot's code, but the reason for that is not quite clear. We examined not setting the bus master bit whereever possible and tried booting without it, which worked fine for internal PCI devices but not for PCIe. As a PCIe device we used a Samsung M.2 NVMe SSD. For security reasons, we would like to disable bus mastering where possible. Depending on the device, bus mastering might get enabled by the operating system (e.g. for iGPU) and it might be required for some devices to work properly. However, the idea is to leave it disabled and configure the IOMMU first before enabling it. To have some sort of "backwards compatibility", add a method which configures bus mastering based on an additional config option. Since CB:42460 makes usage of this treewide, enable it by default to keep the current behaviour for now. Tested with Siemens/Chili, a Coffee Lake based platform. Change-Id: I876c48ea3fb4f9cf7b6a5c2dcaeda07ea36cbed3 Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42459 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Kconfig: Escape variable to accommodate new Kconfig versionsPatrick Georgi2020-06-191-3/+3
| | | | | | | | | | | | | | | | | | | | | Kconfig 4.17 started using the $(..) syntax for environment variable expansion while we want to keep expansion to the build system. Older Kconfig versions (like ours) simply drop the escapes, not changing the behavior. While we could let Kconfig expand some of the variables, that only splits the handling in two places, making debugging harder and potentially messing with reproducible builds (e.g. when paths end up in configs), so escape them all. Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 22:46:14 +0000