summaryrefslogtreecommitdiff
path: root/src/device/Kconfig
AgeCommit message (Collapse)Author
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-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-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-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-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-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-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-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>
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-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-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-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-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-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-08-13payloads/tianocore: Rename TianoCore to edk2Sean Rhodes
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>
2022-05-28payloads/external: Add support for coreDOOM payloadNicholas Chin
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>
2022-03-15i2c: Add configurable I2C transfer timeoutJes Klinke
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>
2022-02-22treewide: Get rid of CONFIG_AZALIA_MAX_CODECSElyes Haouas
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>
2022-02-16device: Add support for PCIe Resizable BARsTim Wawrzynczak
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>
2021-11-10Rename ECAM-specific MMCONF KconfigsShelley Chen
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>
2021-10-05src/acpi to src/lib: Fix spelling errorsMartin Roth
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>
2021-08-26device/mipi: Move to drivers/mipiJulius Werner
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>
2021-08-18device: Move MIPI panel library from mainboard/google/kukui into commonJulius Werner
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>
2021-04-19device/azalia_device.c: Add option to lock down GCAPAngel Pons
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>
2021-04-18device/Kconfig: Adapt PCIEXP_HOTPLUG_BUSESNico Huber
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>
2021-03-24device/azalia_device.c: Introduce AZALIA_MAX_CODECSAngel Pons
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>
2021-02-15device: Add unit to Kconfig option name: `PRE_GRAPHICS_DELAY_MS`Paul Menzel
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>
2021-02-06soc/intel/broadwell: Conditionally skip PRE_GRAPHICS_DELAYKyösti Mälkki
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>
2021-01-30device/Kconfig: Introduce MMCONF_LENGTHAngel Pons
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>
2021-01-29device/Kconfig: Declare MMCONF symbols' type onceAngel Pons
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>
2021-01-10device: Add new Kconfig VGA_ROM_RUN_DEFAULT for mainboard userSubrata Banik
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>
2020-11-25device: Drop unused HyperTransport codeAngel Pons
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>
2020-11-16device: Allow configuring bus mastering for PCI bridges conditionallyFelix Singer
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>
2020-11-02device: Rework bus master optionFelix Singer
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>
2020-10-27device: Rephrase bus master Kconfig optionFelix Singer
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>
2020-09-20lint: check for misuse of Kconfig SUBSYSTEM_*_IDMichael Niewöhner
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>
2020-08-31device: Add method to configure bus mastering based on KconfigFelix Singer
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>
2020-06-19Kconfig: Escape variable to accommodate new Kconfig versionsPatrick Georgi
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>
2020-06-18src/device/Kconfig: Introduce WANT_LINEAR_FRAMEBUFFERAngel Pons
This decouples the linear framebuffer type from the symbols needing it. Change-Id: I733e630e0aa2fb2947d079caef26253ce443fe91 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42432 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-10device/xhci: Add xHCI utility to enumerate capabilitiesRaul E Rangel
This will allow enumerating an xHCI controller to allow dynamically generating the ACPI device nodes. BUG=b:154756391 TEST=Boot trembyle and see capabilities printed on console xHCI Supported Protocol: Major: 0x2, Minor: 0x0, Protocol: 'USB ' Port Offset: 1, Port Count: 2 xHCI Supported Protocol: Major: 0x3, Minor: 0x10, Protocol: 'USB ' Port Offset: 3, Port Count: 1 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I3065c3fffad01b5378a55cfe904f971079b13d0f Reviewed-on: https://review.coreboot.org/c/coreboot/+/41899 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-28Revert "Revert "pciexp_device: Add option to allocate prefetch memory above ↵Furquan Shaikh
4G boundary"" This reverts commit e15f352039a371156ceef37f0434003228166e99. Reason for revert: Resource allocator is split into old(v3) and new(v4). So, this change to provide an option to allocate prefetch memory above 4G boundary can be added back. Since the support for allocating above 4G boundary is available only in resource allocator v4, Kconfig option is accordingly updated to add depends on RESOURCE_ALLOCATOR_V4. Change-Id: I94e5866458c79c2719fd780f336fb5da71a7df66 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41467 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26device: Switch to resource allocator v4 by default treewideFurquan Shaikh
This change disables the old resource allocator by default and instead uses the new v4 resource allocator. Only the chipsets that explicitly select RESOURCE_ALLOCATOR_V3 will continue to use the old v3 resource allocator. Change-Id: I2ab9f1d612b5f193f058011a18b1d6373e09f788 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41445 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com>
2020-05-26device: Add support for resource allocator v4Furquan Shaikh
This change adds back support for the resource allocator using multiple ranges as originally landed in CB:39486(commit hash 3b02006) and reverted in CB:41413(commit hash 6186cbc). The new resource allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It was identified that there are some AMD chipsets in the tree that do not really work well with the dynamic resource allocation. Until these chipsets are fixed, old (v3) and new (v4) of the resource allocator need to live side-by-side in the tree. There were some other chipsets in the tree which originally demonstrated problems with the new resource allocator, but have been since fixed in the tree. This change picks up the same additions as performed in CB:39486 along with the following changes: 1. Changes to avoid fixed resources in the entire tree. Use of search_bus_resources() is replaced with a walk of the entire tree in avoid_fixed_resources(). This is required to ensure that all fixed resources added to any device (including domain) are taken into consideration to avoid overlap during dynamic resource allocation. 2. Changes to set up alignment for memranges when initializing them. This is done to ensure that the right granularity is used for IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource requests. 3. mark_resource_invalid() is dropped as the resource no longer needs to be marked in any special way if allocation is not being done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this case. 4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED instead of base == limit. Original commit message: This change updates the resource allocator in coreboot to allow using multiple ranges for resource allocation rather than restricting available window to a single base/limit pair. This is done in preparation to allow 64-bit resource allocation. Following changes are made as part of this: a) Resource allocator still makes 2 passes at the entire tree. The first pass is to gather the resource requirements of each device under each domain. It walks recursively in DFS fashion to gather the requirements of the leaf devices and propagates this back up to the downstream bridges of the domain. Domain is special in the sense that it has fixed resource ranges. Hence, the resource requirements from the downstream devices have no effect on the domain resource windows. This results in domain resource limits being unmodified after the first pass. b) Once the requirements for all the devices under the domain are gathered, resource allocator walks a second time to allocate resources to downstream devices as per the requirements. Here, instead of maintaining a single window for allocating resources, it creates a list of memranges starting with the resource window at domain and then applying constraints to create holes for any fixed resources. This ensures that there is no overlap with fixed resources under the domain. c) Domain does not differentiate between mem and prefmem. Since they are allocated space from the same resource window at the domain level, it considers all resource requests from downstream devices of the domain independent of the prefetch type. d) Once resource allocation is done at the domain level, resource allocator walks down the downstream bridges and continues the same process until it reaches the leaves. Bridges have separate windows for mem and prefmem. Hence, unlike domain, the resource allocator at bridge level ensures that downstream requirements are satisfied by taking prefetch type into consideration. e) This whole 2-pass process is performed for every domain in the system under the assumption that domains do not have overlapping address spaces. Noticeable differences from previous resource allocator: a) Changes in print logs observed due to flows being slightly different. b) Base, limit and size of domain resources are no longer updated based on downstream requirements. c) Memranges are used instead of a single base/limit pair for determining resource allocation. d) Previously, if a resource request did not fit in the available base/limit window, then the resource would be allocated over DRAM or any other address space defeating the principle of "no overlap". With this change, any time a resource cannot fit in the available ranges, it complains and ensures that the resource is effectively disabled by setting base same as the limit. e) Resource allocator no longer looks at multiple links to determine the right bus for a resource. None of the current boards have multiple buses under any downstream device of the domain. The only device with multiple links seems to be the cpu cluster device for some AMD platforms. Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26device: Move resource allocation into a separate compilation unitFurquan Shaikh
This change moves the resource allocator functions out of device.c and into two separate files: 1. resource_allocator_v3.c: This is the old implementation of resource allocator that uses a single window for resource allocation. It is required to support some AMD chipsets that do not provide an accurate map of allocated resources by the time the allocator runs. They work fine with the old allocator since it restricts itself to allocations in a single window at the top of the 4G space. 2. resource_allocator_common.c: This file contains the functions that can be shared by the old and new resource allocator. Entry point into the resource allocation is allocate_resources() which can be implemented by both old and new allocators. This change also adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old resource allocator. This config option is enabled by default currently, but in the following CLs this will be enabled only for the broken boards. Reason for this split: Both the old and new resource allocators need to be retained in the tree until the broken chipsets are fixed. Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-18src: Remove leading blank lines from SPDX headerElyes HAOUAS
Change-Id: I8a207e30a73d10fe67c0474ff11324ae99e2cec6 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41360 Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16Revert "pciexp_device: Add option to allocate prefetch memory above 4G boundary"Furquan Shaikh
This reverts commit dcbf6454b6d2d9b3627a14126ef20ed4b9c7d954. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. Change-Id: I58c9fff1a18ea1c9941e29c2c6e60e338c517c30 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41465 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com>
2020-05-12pciexp_device: Add option to allocate prefetch memory above 4G boundaryFurquan Shaikh
This change adds a Kconfig option to request allocation of prefetch memory for hotplug devices above the 4G boundary. In order to select this option by default and still allow users to disable this if required, another option is added to request allocation of prefetch memory below 4G boundary which defaults to n but can be overriden by mainboards. Without this change, if the number of pciexp bridges supporting hot-plug is more than 4 or if the reserved prefetch memory size for hot-plug cases was increased, then the resource allocator would fail to satisfy the resource requirement below 4G boundary. BUG=b:149186922 TEST=Enabled resource allocation above 4G for prefetch memory on volteer and verified that it gets allocated above 4G boundary. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I061d935eef9fcda352230b03b5cf14e467924e50 Reviewed-on: https://review.coreboot.org/c/coreboot/+/39489 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-09src/: Replace GPL boilerplate with SPDX headersPatrick Georgi
Used commands: perl -i -p0e 's|\/\*[\s*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-only */|' $(cat filelist) perl -i -p0e 's|\/\*[\s*]*.*is[\s*]*free[\s*]*software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*either[\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License,[\s*]*or[\s*]*.at[\s*]*your[\s*]*option.[\s*]*any[\s*]*later[\s*]*version.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-or-later */|' $(cat filelist) perl -i -p0e 's|\/\*[\s*]*.*is[\s*#]*free[\s*#]*software[;:,][\s*#]*you[\s*#]*can[\s*#]*redistribute[\s*#]*it[\s*#]*and/or[\s*#]*modify[\s*#]*it[\s*#]*under[\s*#]*the[\s*#]*terms[\s*#]*of[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*as[\s*#]*published[\s*#]*by[\s*#]*the[\s*#]*Free[\s*#]*Software[\s*#]*Foundation[;:,][\s*#]*either[\s*#]*version[\s*#]*3[\s*#]*of[\s*#]*the[\s*#]*License[;:,][\s*#]*or[\s*#]*.at[\s*#]*your[\s*#]*option.[\s*#]*any[\s*#]*later[\s*#]*version.[\s*#]*This[\s*#]*program[\s*#]*is[\s*#]*distributed[\s*#]*in[\s*#]*the[\s*#]*hope[\s*#]*that[\s*#]*it[\s*#]*will[\s*#]*be[\s*#]*useful[;:,][\s*#]*but[\s*#]*WITHOUT[\s*#]*ANY[\s*#]*WARRANTY[;:,][\s*#]*without[\s*#]*even[\s*#]*the[\s*#]*implied[\s*#]*warranty[\s*#]*of[\s*#]*MERCHANTABILITY[\s*#]*or[\s*#]*FITNESS[\s*#]*FOR[\s*#]*A[\s*#]*PARTICULAR[\s*#]*PURPOSE.[\s*#]*See[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*for[\s*#]*more[\s*#]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-3.0-or-later */|' $(cat filelist) perl -i -p0e 's|(\#\#*)[\w]*.*is free software[:;][\#\s]*you[\#\s]*can[\#\s]*redistribute[\#\s]*it[\#\s]*and\/or[\#\s]*modify[\#\s]*it[\s\#]*under[\s \#]*the[\s\#]*terms[\s\#]*of[\s\#]*the[\s\#]*GNU[\s\#]*General[\s\#]*Public[\s\#]*License[\s\#]*as[\s\#]*published[\s\#]*by[\s\#]*the[\s\#]*Free[\s\#]*Software[\s\#]*Foundation[;,][\s\#]*version[\s\#]*2[\s\#]*of[\s\#]*the[\s\#]*License.*[\s\#]*This[\s\#]*program[\s\#]*is[\s\#]*distributed[\s\#]*in[\s\#]*the[\s\#]*hope[\s\#]*that[\s\#]*it[\s\#]*will[\#\s]*be[\#\s]*useful,[\#\s]*but[\#\s]*WITHOUT[\#\s]*ANY[\#\s]*WARRANTY;[\#\s]*without[\#\s]*even[\#\s]*the[\#\s]*implied[\#\s]*warranty[\#\s]*of[\#\s]*MERCHANTABILITY[\#\s]*or[\#\s]*FITNESS[\#\s]*FOR[\#\s]*A[\#\s]*PARTICULAR[\#\s]*PURPOSE.[\#\s]*See[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*for[\#\s]*more[\#\s]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) perl -i -p0e 's|(\#\#*)[\w*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) Change-Id: Ia01908544f4b92a2e06ea621eca548e582728280 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41178 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-31device/Kconfig: fix circular dependency for RUN_FSP_GOPMatt DeVillier
Change Graphics Init default for RUN_FSP_GOP to depend on INTEL_GMA_HAVE_VBT rather than INTEL_GMA_ADD_VBT, since RUN_FSP_GOP selects INTEL_GMA_ADD_VBT for several Intel SoC's. Test: create default config for gogle/cyan, RUN_FSP_GOP still default display init selection but no more circular dependency warning from config. Change-Id: I8b978d9938c3d0024d4dd40000b988430664cee7 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39910 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-03-29src/device/Kconfig: Adjust Graphics init defaultsMatt DeVillier
Adjust the defaults for Graphics Initialization so that the "best" option for a board is selected by default. Net effect is to select RUN_FSP_GOP over VGA_ROM_RUN in cases where the platform supports GOP init and the mainboard has a VBT file included. Test: run 'make menuconfig' and check default Display Init option for google/cyan, observe RUN_FSP_GOP is default. Change-Id: I2184dbdd943d035d1682b3ae7bd8d005221434b1 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39871 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-03-25src/device: Add option to look at revision in option romsMartin Roth
AMD's Family 17h SOCs have the same vendor and device IDs for their graphics blocks, but need different video BIOSes. The only difference is the revision number. Add a Kconfig option that allows us to add the revision number of the graphics device to the PCI option rom saved in CBFS. Because searching CBFS takes a non-trivial amount of time, only enable the option if it's needed. If it's not used, or if nothing matches, the check will fall through and search for an option rom with no version. BUG=b:145817712 TEST=With surrounding patches, loads dali vbios Change-Id: Icb610a2abe7fcd0f4dc3716382b9853551240a7a Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/2013181 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39792 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-03-25arch/x86: Add Kconfig option for 2nd VGA BIOS imageMartin Roth
Picasso and Dali need different video bioses even though they use the same code in most other places. The Kconfig symbol names are changed from the downstream commit to make them more consistent with current coreboot code. BUG=b:145817712 TEST=Build Dali vBIOS into the coreboot image Change-Id: Ide0d061fda0abc78a74ddf97ba81fc3cf2b02e4f Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1956534 Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org> Reviewed-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-02-24device/Kconfig: select linear framebuffer for TianocoreMatt DeVillier
Automatically select the linear framebuffer mode option if available when Tianocore selected as payload, since VGA text mode will not work properly with the default Tianocore payload. Change-Id: Ic36fd035526f3efd00ffa12ad613fbac304b18cf Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39048 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-02-17treewide: capitalize 'BIOS'Elyes HAOUAS
Also replace 'BIOS' by coreboot when the image is 'coreboot.rom'. Change-Id: I8303b7baa9671f19a036a59775026ffd63c85273 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38932 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-02-05pciexp: Add support for allocating PCI express hotplug resourcesJeremy Soller
This change adds support for allocating resources for PCI express hotplug bridges when PCIEXP_HOTPLUG is selected. By default, this will add 32 PCI subordinate numbers (buses), 256 MiB of prefetchable memory, 8 MiB of non-prefetchable memory, and 8 KiB of I/O space to any device with the PCI_EXP_SLTCAP_HPC bit set in the PCI_EXP_SLTCAP register, which indicates hot-plugging capability. The resource allocation is configurable, please see the PCIEXP_HOTPLUG_* variables in src/device/Kconfig. In order to support the allocation of hotplugged PCI buses, a new field is added to struct device called hotplug_buses. This is defaulted to zero, but when set, it adds the hotplug_buses value to the subordinate value of the PCI bridge. This allows devices to be plugged in and unplugged after boot. This code was tested on the System76 Darter Pro (darp6). Before this change, there are not enough resources allocated to the Thunderbolt PCI bridge to allow plugging in new devices after boot. This can be worked around in the Linux kernel by passing a boot param such as: pci=assign-busses,hpbussize=32,realloc This change makes it possible to use Thunderbolt hotplugging without kernel parameters, and attempts to match closely what our motherboard manufacturer's firmware does by default. Signed-off-by: Jeremy Soller <jeremy@system76.com> Change-Id: I500191626584b83e6a8ae38417fd324b5e803afc Reviewed-on: https://review.coreboot.org/c/coreboot/+/35946 Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-04device/smbus: Drop SMBUS_HAS_AUX_CHANNELSKyösti Mälkki
The guarded prototypes are no longer implemented in the tree. Change-Id: I5bfedde2aaf691826e7537eceb8578a855800ea2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38153 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-01-03device/Kconfig: make sure display can't be selected by accidentMichael Niewöhner
Make sure display can't be selected by accident when NO_GFX_INIT is selected. Change-Id: Iec5a47f84b8c776a45edc6f4b31a03b9ac714b4e Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-11-20device: Add back dummy HT_CHAIN_UNITID_BASEKyösti Mälkki
This should be defined by mainboard. Add a dummy default to fix master while HyperTransport files are still around referencing this. Change-Id: I58188a200a2cad5fa20affee1844117ba71ac338 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37036 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-01console/kconfig: Move ONBOARD_VGA_IS_PRIMARY to 'devices'Arthur Heymans
This has nothing to do with console options. This also improves the help text to reflect what it actually does. Change-Id: I039f4f6bbe144769d6a362192b225838ed3d9d43 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32042 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2019-10-27device: add Kconfig option to hide GOP initialization optionMichael Niewöhner
There are mainboards that do not have any graphics ports connected to the SoC. It would be senseless to initialize the iGD, thus add a new mainboard Kconfig to hide the GOP option. Change-Id: Ica3b3a7a0c8120c95412369a24d8d669fb59fded Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36348 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-09-17AUTHORS: Move src/device copyrights into AUTHORS fileMartin Roth
As discussed on the mailing list and voted upon, the coreboot project is going to move the majority of copyrights out of the headers and into an AUTHORS file. This will happen a bit at a time, as we'll be unifying license headers at the same time. Additional cleanup - Unify "Inc" to "Inc." and "LLC." to "LLC" Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ie03a3ce1f6085494bd5f38da76e2467970cf301a Reviewed-on: https://review.coreboot.org/c/coreboot/+/35430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-09-15lib/coreboot_table: Show splashscreen in lb_table_initJohanna Schander
Every vga init implementation needs to cache the framebuffer state to be able to fill the lb_framebuffer struct later on in the fill_lb_framebuffer call. Showing the bootsplash afterwards guarantees to have the same interface into all the vga drivers. This is by far from ideal, as it only allows for a single driver at compile-time and should be adapted in the future. It was tested on the wip razer blade stealth using vgabios @ 1280x1024 and also in Qemu @ 1280x1024. By default the qemu framebuffer will be initialized in 800x600@32. This can be overwriten by configuration by setting CONFIG_DRIVERS_EMULATION_QEMU_BOCHS_{X,Y}RES . Change-Id: I4bec06d22423627e8f429c4b47e0dc9920f1464e Signed-off-by: Johanna Schander <coreboot@mimoja.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34599 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-07-24device: Default to VESA/linear framebuffer for ChromeOSNico Huber
Building for ChromeOS implies the use of Depthcharge which doesn't support legacy text mode. Change-Id: I7fd82bfed1e59de2de75419cfaea6f0c19cfdf5e Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34483 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-27drivers/intel/gma: Make libgfxinit available w/o gfxinitNico Huber
We might want to make use of libgfxinit functions without using it for actual graphics init. Change-Id: I29c3b19989acb678d0d447e83d38bad9d584caa9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31455 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-07src/device/Kconfig: Include the discrete VGA OpROM at config UIMike Banon
Create the way of adding the discrete VGA OpROM at config UI (alternative to ./cbfstool ./cb.rom add -f vgabios_dgpu.bin -n pci1002,6663.rom -t optionrom ) DGPU options are accessible only if CONFIG_VGA_BIOS is enabled. Signed-off-by: Mike Banon <mikebdp2@gmail.com> Change-Id: I0a7bf0fe95c833cf3df0c7cb20fc27b6ab218c5a Reviewed-on: https://review.coreboot.org/c/coreboot/+/31449 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2019-02-25src/device/Kconfig: Change default VESA mode from 117h to 118hMike Banon
Change default VESA/native framebuffer mode (needed for bootsplash and graphical framebuffer console) from 117h (1024x768 64k-color (5:6:5)) to 118h (1024x768 16.8M-color (8:8:8)) mode. This provides console output at Lenovo G505S even if e.g. GRUB is the payload, while it is unlikely to cause any downsides for the other boards. Signed-off-by: Mike Banon <mikebdp2@gmail.com> Change-Id: Ia348199bbd430532b1399706dd84490c9680b5f5 Reviewed-on: https://review.coreboot.org/c/31595 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-02-06libgfxinit: Add options to limit framebuffer sizeNico Huber
Add maximum width and height options and set the default to 2560x1600 (WQXGA). The framebuffer will be scaled up to the displays' native resolutions. So this should help with tiny fonts on high-DPI displays. For laptops, reasonable defaults can be set at the mainboard level. Change-Id: I47fba063629260c3a2854caf7a73f1a1e933d063 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/30585 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-12-21cpu/amd/geode_lx: Drop supportArthur Heymans
These chips are still using LATE_CBMEM which was agreed upon to be removed after release 4.7. It is now more than 1 year later and they still linger around. The work and review to bring this code up to date can happen on the 4.9 branch and then squashed together and merged back into mainline when done. Change-Id: I11290a5e92397b9b7e7e5a19b029278e728671a3 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30326 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Nico Huber <nico.h@gmx.de>
2018-11-30arch/power8: Rename to ppc64Jonathan Neuschäfer
POWER8 is a specific implementation of ppc64, which is by now outdated (POWER9 has been on the market for a while). Rename arch/power8/ to potentially cover a wider range of hardware. TEST=Toolchains built before/after this commit can build coreboot for emulation/qemu-power8 from before/after this commit. Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/29943 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
2018-06-12drivers/intel/gma: Unify VBT related Kconfig namesNico Huber
Shuffle words and drop the _DATA_FILE suffix. Change-Id: I0b0d50ea729e5580c0bc7b43f250ff387ce59cfc Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/26898 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2018-06-06drivers/intel/gma: Include mainboard data.vbtArthur Heymans
This adds a INTEL_GMA_VBT_HAVE_DATA_FILE Kconfig option for the path to point to the mainboard dir and to select INTEL_GMA_ADD_VBT_DATA_FILE by default. Change-Id: I730cb0737945631e2d5379a9e26b8c039ec6dc49 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/26653 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2018-06-04device: Only expose VGA_ROM_RUN on supported architecturesPatrick Rudolph
The yabel emulator depends on IO ports, that aren't available on ARM and MIPS. Add additional dependencies to fix compilation errors with the default configuration. Change-Id: If0e28b356c01cb3ae0739a54aa3531a2acedbfbb Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/26754 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-02-01Add a default path for vbt.binArthur Heymans
FSP_GOP needs a vbt.bin to work but before this patch it was able to build with the default configuration which was an empty path for vbt.bin. To make Jenkins happy don't select FSP_GOP by default, at least until all boards have the proper vbt blobs in the blobs repo. Change-Id: Ibc36d6d4dd1a56c53819b169e6f4799ce3c23e03 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23290 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-02-01device: add ALWAYS_RUN_OPROM optionAaron Durbin
Certain platforms require that the option rom always needs to be ran in order for display to work correctly. Therefore, provide this ability for the platform to select such that we force option rom loading. BUG=b:72400950 Change-Id: I597bc8af7ac8b68fe8505aac5f1c7e1ccd34ac27 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/23505 Reviewed-by: Justin TerAvest <teravest@chromium.org> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2018-01-15Intel i82830 boards & chips: Remove - using LATE_CBMEM_INITMartin Roth
All boards and chips that are still using LATE_CBMEM_INIT are being removed as previously discussed. If these boards and chips are updated to not use LATE_CBMEM_INIT, they can be restored to the active codebase from the 4.7 branch. chips: cpu/intel/socket_mFCBGA479 northbridge/intel/i82830 Mainboards: mainboard/rca/rm4100 mainboard/thomson/ip1000 Change-Id: I9574179516c30bb0d6a29741254293c2cc6f12e9 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/22032 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2017-09-04Kconfig: Move and rename ADD_VBT_DATA_FILEPatrick Rudolph
Move ADD_VBT_DATA_FILE to "Devices" menu and rename it to INTEL_GMA_ADD_VBT_DATA_FILE. Depend on Intel platforms to avoid confusing users of non-Intel platforms. The Intel GMA driver will use the vbt.bin, if present, to fill the ACPI OpRegion. Change-Id: I688bac339c32e9c856642a0f4bd5929beef06409 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/20619 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-06-08fsp/gop: Add running the GOP to the choice of gfx initNico Huber
The new config choice is called RUN_FSP_GOP. Some things had to happen on the road: * Drop confusing config GOP_SUPPORT, * Add HAVE_FSP_GOP to chipsets that support it, * Make running the GOP an option for FSP2.0 by returning 0 in random VBT getters. Change-Id: I92f88424004a4c0abf1f39cc02e2a146bddbcedf Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19815 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-06-08device/Kconfig: Put gfx init methods into a `choice`Nico Huber
Provide all gfx init methods as a Kconfig `choice`. This elimates the option to select native gfx init along with running a Video BIOS. It's been only theoretically useful in one corner case: Hybrid graphics where only one controller is supported by native gfx init. Though I suppose in that case it's fair to assume that one would use SeaBIOS to run the VBIOS. For the case that we want the payload to initialize graphics or no pre-boot graphics at all, the new symbol NO_GFX_INIT was added to the choice. If multiple options are available, the default is chosen as follows: * NO_GFX_INIT, if we add a Video BIOS and the payload is SeaBIOS, * VGA_ROM_RUN, if we add a Video BIOS and the payload is not SeaBIOS, * NATIVE_VGA_INIT, if we don't add a Video BIOS. As a side effect, libgfxinit is now an independent choice. Change-Id: I06bc65ecf3724f299f59888a97219fdbd3d2d08b Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19814 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-06-08device/Kconfig: Introduce MAINBOARD_FORCE_NATIVE_VGA_INITNico Huber
MAINBOARD_FORCE_NATIVE_VGA_INIT is to be selected instead of the user option MAINBOARD_DO_NATIVE_VGA_INIT. The distinction is necessary to use the latter in a choice. Change-Id: I689aa5cadea9e1091180fd38b1dc093c6938d69c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19813 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-06-06device/Kconfig: Move "Display" menu below gfx optionsNico Huber
Make the "Display" menu a submenu of "Devices", place it below the graphics options and reorder options by their dependencies. Change-Id: I9de3d8f76ae10b0a77678ce2d71f840fac32379c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/19806 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-06-04Kconfig: Add choice of framebuffer modeNico Huber
Rename `FRAMEBUFFER_KEEP_VESA_MODE` to `LINEAR_FRAMEBUFFER` and put it together with new `VGA_TEXT_FRAMEBUFFER` into a choice. There are two versions of `LINEAR_FRAMEBUFFER` that differ only in the prompt and help text (one for `HAVE_VBE_LINEAR_FRAMEBUFFER` and one for `HAVE_LINEAR_FRAMEBUFFER`). Due to `kconfig_lint` we have to model that with additional symbols. Change-Id: I9144351491a14d9bb5e650c14933b646bc83fab0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/19804 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-06-04device/Kconfig: Clarify ON_DEVICE_ROM_LOADNico Huber
It's only used for VGA ROMs. Change-Id: I898765f79cbf5ccce871a3598b56eda83e5efaca Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/19805 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-06-02Kconfig: Introduce HAVE_(VBE_)LINEAR_FRAMEBUFFERNico Huber
Like HAVE_VGA_TEXT_FRAMEBUFFER, these are selected by graphics drivers that support a linear framebuffer. Some related settings moved to the drivers (i.e. for rockchip/rk3288 and nvidia/tegra124) since they are hardcoded. Change-Id: Iff6dac5a5f61af49456bc6312e7a376def02ab00 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/19800 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-06-02Kconfig: Rework MAINBOARD_HAS_NATIVE_VGA_INIT_TEXTMODECFGNico Huber
* Rename it to HAVE_VGA_TEXT_FRAMEBUFFER. * Let drivers select it if they are in charge. * Don't select it on the mainboard level if a driver handles it. Change-Id: I2d9d09be9aa6d019e77460e69a245ad2d8cda4ea Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-05-30lib/edid: Split out fill_lb_framebuffer()Nico Huber
Place it into new edid_fill_fb.c, and invert the logic of the Kconfig guard (NATIVE_VGA_INIT_USE_EDID is now !NO_EDID_FILL_FB). It has to be selected by all drivers that use MAINBOARD_DO_NATIVE_VGA_INIT but pro- vide their own fill_lb_framebuffer() implementation. Change-Id: I90634b835bd8e2d150b1c714328a5b2774d891bd Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19764 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-03lib/edid.c: Allow use of when not NGIArthur Heymans
Change-Id: I8709e3e61686979137b08d24efad903700d18e0b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/19501 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-04-08libgfxinit: Select CONFIG_VGA when neededNico Huber
This wasn't caught earlier because many boards select it manually. Change-Id: I245ef8f44923b5384123bd549570db7c348e03b8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/18771 Tested-by: build bot (Jenkins) Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-10ddr3 spd: move accessor code into lib/spd_bin.cPatrick Georgi
It's an attempt to consolidate the access code, even if there are still multiple implementations in the code. Change-Id: I4b2b9cbc24a445f8fa4e0148f52fd15950535240 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/18265 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-29Kconfig: Document what ASPM meansJonathan Neuschäfer
Change-Id: I57dd933ad70ffac95388d832bd5047f2225688e3 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/17973 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-12-19drivers/intel/gma: Add textmode support with libgfxinitNico Huber
Add an alternative gfxinit implementation for textmode. The legacy VGA plane and textmode is configured through coreboot provided functions. libgfxinit uses this plane as alternative to the usual high resolution plane. Change-Id: Iad0754c50fc6faec35f49583fe1c7cb50ac6c0c5 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/17279 Tested-by: build bot (Jenkins) Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2016-12-07MMCONF_SUPPORT: Flip default to enabledKyösti Mälkki
Also remove separate MMCONF_SUPPORT_DEFAULT flag. Change-Id: Idf1accdb93843a8fe2ee9c09fb984968652476e0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17694 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-07PCI ops: MMCONF_SUPPORT_DEFAULT is requiredKyösti Mälkki
Doing PCI config operations via MMIO window by default is a requirement, if supported by the platform. This means chipset or CPU code must enable MMCONF operations early in bootblock already, or before platform-specific romstage entry. Platforms are allowed to have NO_MMCONF_SUPPORT only in the case it is actually not implemented in the silicon. Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17693 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-01PCIEXP_PLUGIN_SUPPORT: Change dependency on PCI accessKyösti Mälkki
Some PCI-e capability registers are located starting from 0x100, these are not accessible using the conventional PCI IO config operations at 0xcf8/0xcfc, unless PCI_CFG_EXT_IO was selected. Thus any feature that calls pciexp_find_extended_cap() depends on either MMCONF_SUPPORT_DEFAULT or PCI_CFG_EXT_IO being enabled on the platform. In theory there can be system without MMCONF_SUPPORT, but with complete PCI Express configuration space available using PCI_CFG_EXT_IO. Do not use explicit PCI MMCONF operations here, but rely on the default PCI access method to be able to access all of the configuration space. While at it, convert to IS_ENABLED() everywhere in the source and organize Kconfig file better. Change-Id: Ica6e16d2fb2adc532e644c4b2c47806490235715 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17546 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 22:45:38 +0000