| Age | Commit message (Collapse) | Author |
|---|
|
This also changes how debug messages will be printed. I focused on
reducing clutter on the screen and made the style of the messages
consistent.
Before:
azalia_audio: Initializing codec #5
codec not ready.
azalia_audio: Initializing codec #4
codec not valid.
azalia_audio: Initializing codec #3
azalia_audio: viddid: ffffffff
azalia_audio: verb_size: 4
azalia_audio: verb loaded.
After:
azalia_audio: codec #5 not ready
azalia_audio: codec #4 not valid
azalia_audio: initializing codec #3...
azalia_audio: - vendor/device id: 0xffffffff
azalia_audio: - verb size: 4
azalia_audio: - verb loaded
Change-Id: I92b6d184abccdbe0e1bfce98a2c959a97a618a29
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80332
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The QEMU Bochs display driver and the QEMU Firmware Configuration
interface code (in the qemu-i440fx mainboard dir) were written for x86.
These devices are available in QEMU VMs of other architectures as well,
so we want to port them to be independent from x86.
The main problem is that the drivers use x86 port I/O functions to
communicate with devices over PCI I/O space. These are currently not
available for ARM* and RISC-V, although it is often still possible to
access PCI I/O ports over MMIO through a translator.
Add implementations of port I/O functions that work with PCI I/O space
on these architectures as well, assuming there is such a translator at a
known address configured at build-time.
Change-Id: If7d9177283e8c692088ba8e30d6dfe52623c8cb9
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80372
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It might be benefical to have utils for domain resource window
creation so that the correct IORESOURCE flags used could be
guaranteed.
TEST=Build and boot on intel/archercity CRB
TEST=Build on intel/avenuecity CRB
Change-Id: I1e90512a48ab002a1c1d5031585ddadaac63673e
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
While the SoC-level defaults for VGA_BIOS_ID are the expected correctly
remapped PCI VID/PID of the GPU which matches the PCI VID/DID inside the
VBIOS file, some mainboards override the VGA_BIOS_ID setting to the
non-remapped PCI ID. This resulted in coreboot not finding the VBIOS
file after commit 42f0396a1028 ("device/pci_rom: rework PCI ID remapping
in pci_rom_probe"). The proper solution would be to not override this
SoC-level config in neither the mainboard code nor some external config
file. This however requires adding/using some mechanism to tell SeaBIOS
which VBIOS image to use for the GPU device. Once this is implemented,
the SoC default for VGA_BIOS_ID shouldn't be overridden any more and
this patch can be reverted again.
This sort-of reverts parts of commit 42f0396a1028 ("device/pci_rom:
rework PCI ID remapping in pci_rom_probe"), but it still tries to find
the VBIOS image with the expected remapped PCI ID and only adds trying
the non-remapped PCI ID as a fallback when the file with the remapped
PCI ID doesn't exist and prints a notice in that case. Before the patch
referenced above, using the correct remapped PCI VID/DID resulted in a
warning about the CBFS file with the non-remapped name not being found,
but first checking the remapped version solves that problem.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7cd8e2036250f4ca2239b04cd070bbf0778b13aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
The CHECK_REV_IN_OPROM_NAME Kconfig option was introduced to solve the
problem of the PCI VID/DID combination of the Picasso iGPU not being
sufficient information to know which VGA BIOS file to run, so a new
function that additionally checks the PCI revision of that device was
introduced. Later it turned out that there might be a case where even
that isn't sufficient, so the soc_is_raven2() function is used in the
remap function to always use the correct VBIOS file.
Picasso is the only SoC that selected the CHECK_REV_IN_OPROM_NAME
Kconfig option, so all other SoCs are unaffected by this change.
Now that we use the VBIOS images with only the PCI VID and DID in the
CBFS file name for Picasso, SeaBIOS will find the VBIOS with the same ID
as the iGPU in CBFS and we don't need the workaround to add a third
VBIOS image via VGA_BIOS_DGPU_* that has the name that SeaBIOS expects.
This will result in SeaBIOS now running the VBIOS that has the same PCI
VID/DID as the hardware which will be the wrong one in the RV2 silicon
showing the PCO silicon PCI VID/DID, but that was also the case with the
VGA_BIOS_DGPU_* workaround where the board's Kconfig just selected one
of the two possible images during build time and hoped that it was the
correct one for that actual hardware. The only board where this patch
might cause a regression compared to the old behavior is the AMD Cereme
reference board with Pollock APU, but I'm not even sure if any coreboot
developer still has one of those boards, so I'm willing to accept that.
To properly solve the problem with SeaBIOS using the correct VBIOS file
in all cases, we'd need to generate that info during coreboot runtime
and somehow pass it to SeaBIOS, but that's out of scope for this patch.
TEST=On Mandolin with PCO silicon, the display output in both SeaBIOS
and Ubuntu still works. Booting Windows 10 via the pre-built EDK2
payload that I'm using also resulted in the display output working.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia6de533c536044698d85404427719b8f534870fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82598
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ifaff19c0117b5247d3321605ccc2e97bf8226ca8
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82216
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I2cc38926b56315d4a828311917ff58051b34b777
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Move specific enum ddr4_module_type to <device/dram/ddr4.h>.
Change-Id: Ia538d2c73affa6560fa1533a40c02b3677588f5a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Rename different spd_raw_data[] for DDR3 and DDR4.
This is to solve the conflict when we include both "ddr3.h" and ddr4.h"
for example here: src/device/dram/spd.c.
Otherwise, it won't compile as DDR3 and DDR4 have different
spd_raw_data[] size.
Change-Id: I46597fe82790410fbb53d60e04b7fdffb7b0094a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82171
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
TEST=Build and boot on intel/archercity CRB
Change-Id: Ied4921f7dc7e144e580d05d4f2262777aa59d895
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81566
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move specific enum ddr5_module_type to <device/dram/ddr5.h>.
Change-Id: Ie38d1e99fa46c278e60ced2d3eef29ca823d4b1d
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
|
|
When the input device pointer pointing to a domain device,
dev_get_domain returns the input device itself.
TEST=Build and boot on intel/archercity CRB
Change-Id: I3a278a8f573de95406ee256fba17767def4ad75d
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
In coreboot, domain indicates hardware units that provide/group
resource windows, For Xeon-SP, domains are PCIe compatible and
further function in many aspects, e.g. PCIe, CXL, IOAT, UBOX.
Rename dev_get_pci_domain to dev_get_domain to align with coreboot
concept and distinguish from Xeon-SP concept.
TEST=Build and boot on intel/archercity CRB
Change-Id: I51b18b30fb41038869ea1384b01091da31a895b9
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81554
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Allows to use the function in more places that expect the
struct device to be readonly.
TEST=Build and boot on intel/archercity CRB
Change-Id: Iac04fe6931a43070f6638b399adbff2ce64829c9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81275
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<string.h> is supposed to provide <stdarg.h> and <stdio.h>
Change-Id: I021ba535ba5ec683021c4dfc41ac18d9cebbcfd2
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81853
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<device/device.h> is supposed to provide <device/{path,resource}.h>
Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
Change-Id: I46a362270f69d0a4a28e5bb9c954f34d632815ff
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Commit a662777b6f57 ("pnp_device: don't treat missing PNP_MSC devicetree
entry as error") lowered the log level for every resource without the
assigned bit set except for the IRQ0 and IRQ1 PNP device resources.
Commit df84fff80fed ("device/pnp_device: Demote unassigned resource
printk to NOTICE") lowered the log level for the IRQ0 and IRQ1 PNP
device resources to a lower log level than for the other warnings that
are less likely a problem. Fix this regression by using the BIOS_NOTICE
log level for all PNP resources that don't have the IORESOURCE_ASSIGNED
bit set.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I232e60ef7ae672e18cc1837b8e6a0427d01c142b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80774
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Current implementation assumes that the endpoint device is connected
directly to the PCIe Root Port, which does not always have to be true.
In a case where there is a PCIe switch between the endpoint and the
root port, the Max Payload Size capability may differ across the
devices in the chain and coreboot will not set a correct Max Payload
Size. This results in a PCIe device malfunction in pre-OS environment,
e.g. if the Ethernet NICs are connected behind a PCIe switch, the iPXE
fails to obtain the DHCP configuration.
Fix this by traversing the topology and programming the highest common
Max Payload Size in the given PCIe device chain during enumeration.
Once finished, the root port has the highest common Max Payload Size
supported by all the devices in the chain. So at the end of root port
bus scan, propagate the root port's Max Payload Size to all downstream
devices to keep Max Payload Size in sync within the whole chain.
TEST=Perform successful dhcp command in iPXE on the NIC connected to
the PCIe root port via ASMedia ASM1806 PCIe switch and again on the
NIC connected directly to the PCIe root port.
Change-Id: I24386dc208363b7d94fea46dec25c231a3968225
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
|
|
Often times not all available resources are used on a PNP function, so
those resources not being specified is intentional, not an error. Keep
the printk but demote it so it doesn't pollute a normal cbmem log.
TEST=build/boot purism/librem_cnl (Mini v2), verify errors in cbmem
related to RTC IO/IRQ not being assigned are no longer present.
Change-Id: I3d9f22a06088596e14680190aede2d69880001fa
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80645
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Fix spelling mistake added in 3e99ba0 "device: Add a helper function to
add a downstream bus".
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I66ae5000f6f5c0e5bfe42bdfbbbcedec6df0c520
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80234
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Multiple links are unused throughout the tree and make the code more
confusing as an iteration over all busses is needed to get downstream
devices. This also not done consistently e.g. the allocator does not
care about multiple links on busses. A better way of dealing multiple
links below a device is to feature dummy devices with each their
respective bus.
This drops the sconfig capability to declare the same device multiple
times which was previously used to declare multiple links.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
Adding downstream busses at runtime is a common pattern so add a helper
function.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic898189b92997b93304fcbf47c73e2bb5ec09023
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I41f8a9b5d1bdb647a915da1a5e95161b2e34df28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80082
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a function to return the PCI domain device for the specified
device. On multi PCI domain platforms this function allows to
determine which domain and thus which socket the PCI device
belongs to.
Change-Id: I0068b82e139fe7a35e6b1b91b7d386b750c80748
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80090
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Print the whole 32bit of the domain ID.
Change-Id: Iae0752f3ae8ed683d4f61c7a47d0dee223a1ba22
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Id23a291af20473c3b3e67178b66fcde920d49984
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The physical address size of the System-on-Chip (SoC) can be different
from the CPU physical address size. These two different physical
address sizes should be used for settings of their respective field.
For instance, the physical address size related to the CPU should be
used for MTRR programming while the physical address size of the SoC
should be used for MMIO resource allocation.
Typically, on Meteor Lake, the CPUs physical address size is 46 if TME
is disabled and 42 if TME is enabled but Meteor Lake SoC physical
address size is always 42. As a result, MTRRs should reflect the TME
status while coreboot MMIO resource allocator should always use
42 bits.
This commit introduces `SOC_PHYSICAL_ADDRESS_WIDTH' Kconfig to set the
physical address size of the SoC for those SoCs.
BUG=b:314886709
TEST=MTRR are aligned between coreboot and FSP
Change-Id: Icb76242718581357e5c62c2465690cf489cb1375
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79665
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Found-by: Coverity Scan #1489753
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4f3794cf17875cdb35010c79a6537a4c13a18224
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
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>
|
|
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>
|
|
The Medium Time Base (MTB) value is calculated by dividing one SPD
byte by another. Return an error if the divisor is zero before using
the value for division.
Found-by: Coverity Scan #1469303
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic0a70291c42b5c2d21d65de92487b2dd88609983
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78613
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
On all targets the domain works as a host bridge. Xeon-sp code intends
to feature multiple host bridges below a domain, hence rename the
function to pci_host_bridge_scan_bus.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Rename pci_rom_acpi_fill_vfct() to ati_rom_acpi_fill_vfct() to make
it clear that the function is only used for AMD/ATI VGA option ROMs.
Change-Id: I0e310dd2d7a0432918861632e09a23e162082ea5
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77634
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
AMD's Windows display drivers validate the checksum of the VBIOS data
in the VFCT table (which gets modified by the FSP GOP driver), so
ensure it is set correctly after copying the VBIOS into the table if the
FSP GOP driver was run. Without the correct checksum, the Windows GPU
drivers will fail to load with a code 43 error in Device Manager.
Thanks to coolstar for root causing the issue.
TEST=build/boot Win11 on google/skyrim (frostflow), ensure GPU driver
loaded and functional.
Change-Id: I809f87865fd2a25fb106444574b619746aec068d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
A trivial follow-up on CB:67060. This makes contents of the file look a
bit less regular, but more like the rest Makefile.inc in the code base.
Change-Id: I772d37825e4b59cf927637dc39bfb3ee06115860
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77533
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Registering Clock Driver (RCD) is responsible for driving address and
control nets on RDIMM and LRDIMM applications. Its operation is
configurable by a set of Register Control Words (RCWs). There are two
ways of accessing RCWs: in-band on the memory channel as MRS commands
("MR7") or through I2C.
Access through I2C is generic, while MRS commands are passed to memory
controller registers in an implementation-specific way.
See JESD82-31 JEDEC standard for full details.
Change-Id: Ie4e6cfaeae16aba1853b33d527eddebadfbd3887
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Change-Id: I9d4f048c859bc89897d50a5a07468c3375aa1dcf
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Disable NULL breakpoints in setup_realmode_idt before calling
write_idt_stub in a loop.
TEST=No more spurious Null dereference errors in the console output.
Before Mandolin showed these two errors before running the VBIOS:
[ERROR] Null dereference at eip: 0x4e6f1a35
[ERROR] Null dereference at eip: 0x4e6f1a4f
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2255d85030e41192ae8a3a7f0f6576c0d373eead
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Change-Id: Ie766807ae1538b21acf471cfacbfe75cfeead921
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77187
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the commonlib, console, northbridge, security, and
southbridge directories that don't already have an SPDX license line
at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I02804a10d0b0355e41271a035613d9f3dfb122f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Change-Id: I8fa26e7a398eee855c31a76f0f89b4111368c2a6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the device and soc directories that don't already have an
SPDX license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I89c05c7c1c39424de2e3547c10661c7e3f58b8f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
|
|
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>
|
|
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
When moving the code to allocate at the top level in commit 9260ea60bfa4
(allocator_v4: Use memranges only for toplevel), a call to restrict the
limit of the resource was dropped. Probably by accident in one of the
earliest rebases. Without this call to effective_limit(), 64-bit resour-
ces at the top level, i.e. PCI bus 0, were always placed above 4G. Even
when this was not requested with the IORESOURCE_ABOVE_4G flag.
Tested on kontron/ktqm77 where the issue could be reproduced with
x86_64. Without the fix, boot hangs when trying to access the GMA
MMIO registers of PCI 00:02.0, which were placed above 4G.
Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483
Signed-off-by: Nico Huber <nico.h@gmx.de>
Found-by: 9elements QA
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76090
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
update_bridge_resource() already gets the type passed as part of
the resource.
Change-Id: I6b3c9809caecdd1bad5b98891a00c3392190a3e0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67022
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
|
|
Inline functions that are only called once to improve readability. The
calling functions still have rather short bodies, and the reader won't
have to look down yet another layer to understand what they are doing.
Change-Id: Ib4aa5d61dfa88c804a1aaee028185e00c5fbb923
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Factor all the resource printing out into separate functions.
This results in one-liners in the actual program code which
hopefully will distract less during reading.
Change-Id: I766db379f3b62d641cb3c41ebe0394b60ba57f7a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65421
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
During phase 1 of the resource allocation we gather all the size
requirements. Starting from the leafs of our devicetree, we cal-
culate the requirements per bus, until we reach the resource do-
main.
However, because alignment plays a role, we can't just accumulate
the sizes of all resources on a bus. Instead, we already sort all
the resources per bus to predict their relative placement, inclu-
ding alignment gaps. Then, phase 2 has to perform the final allo-
cations with the exact same relative placement.
This patch introduces a very simple mechanism to avoid repeating
all the calculations: In phase 1, we note the relative `base` of
each resource on a bus. And after we allocated all the resources
directly below the domain in phase 2, we add the absolute `base`
of bridge resources to the relative `base` of child resources.
This saves most of the computational complexity in phase 2. How-
ever, with a shallow devicetree with most devices directly below
the domain, this won't have a measurable impact.
Example after phase 1:
domain
|
`-- bridge #0
| res #0, base 0x000000 (relative),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0x800000 (relative),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0x000000 (relative),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
After phase 2 allocation at the domain level (assuming res #0 got
0xa000000 assigned):
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0x800000 (relative),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0x000000 (relative),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
Now, all we need to do is to add the `base` of bridge resources
recursively. Starting with resources on the bus below bridge #0:
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0xa800000 (absolute),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0xa000000 (absolute),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
And finally for resources on the bus below bridge #1:
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0xa800000 (absolute),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0xa000000 (absolute),
| size 8M, align 8M
|
`-- device #1
res #3, base 0xa000000 (absolute),
size 8M, align 8M
Change-Id: I70c700318a85f6760f27597730bc9c9a86dbe6b3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65420
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
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>
|
|
It is no longer necessary to explicitly add "ERROR: " in front of
BIOS_ERR message.
Change-Id: I3ff2081d38f94556481efa02f242795bbfc77517
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75876
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Use the proper format specifier for unsigned integers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5e39377d62981229531027b3153d5b343a0a7538
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75400
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Don't assume only one IO and one MEM domain resource.
Currently the code is awkward for bridge devices where loops over
resources are done twice. This would be avoided on top of other patches
that improve the allocator (topic:allocator) by adding a top-down mode.
However those patches break the tree and having the option to have
multiple resources per type would make it easier to get those patches in
without breaking the tree.
Change-Id: I3d3a60c9a4438accdb06444e2b50cc9b0b2eb009
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67018
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Registered DIMM should be 'FORMFACTOR_DIMM' with 'DETAIL_REGISTERED'
instead of 'FORMFACTOR_RIMM', RIMM has been EOL for so many years.
Memory form factor info is now correct on 4th Gen Xeon server platform
with registered DIMM.
Signed-off-by: Ziang Wang <ziang.wang@intel.com>
Signed-off-by: Kehong Chen <kehong.chen@intel.com>
Change-Id: I1eea4717a2d60c6100c262a2284a2ac5109f114a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
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>
|
|
Code changes are necessary because `-Wformat` warns about empty
format strings by default.
Change-Id: Ic8021b70f4cd4875b06f196f88b84940c9a79fe0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75147
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I56ffb82ec417530527ea1ea7e97a593e5bf6b756
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
These strings are now only expanded in lib/identity.c.
This improves ccache hit rates slightly, as one built object file
lib/version.o is used for all variants of a board. Also one built
object file lib/identity.o can become a ccache hit for successive
builds of a variant, while the commit hash changes.
Change-Id: Ia7d5454d95c8698ab1c1744e63ea4c04d615bb3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
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>
|
|
This is needed to generate MADT and SRAT where lapicid for threads need
to be added last. When CPUID leaf '0xB' is not present assume some
defaults that would result in identical ACPI code generation.
Change-Id: I2210eb9b663dd90941a64132aa7154440dc7e5a9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69222
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It's quite confusing to keep track of lapic ID inside the device
struct and initial lapic ID inside an array.
Change-Id: I4d9f8d23c0b0e5c142f6907593428d8509e4e7bb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64342
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Only call cbfs_boot_map_optionrom/cbfs_boot_map_optionrom_revision once
and pass the already remapped PCI ID to it. This avoids the spurious
warning that the CBFS file wasn't found from the first
cbfs_boot_map_optionrom call in cases where the PCI ID needs to be
remapped to get the right ID for which a file in CBFS exists.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If7da78c69dd702280a78996a5823972516e0319b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73612
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The XHCI device functions currently use functions that require a
access to the device tree. Create variant of these functions that can
operate with a resource* as an argument and refactor the existing
device*-based functions to operate by calling the resource*-based
variants. This is useful for stages like SMM that may not have access to
the device tree.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on skyrim device, verified that XHCI ACPI tables are still
generated correctly.
Change-Id: If5a74f9529d5dc6031ec968ef5f40a9cad5ffbc4
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
The Common Clock Configuration (CCC) is a PCIe feature for cases where
the upstream and downstream device of a link share the same reference
clock. After a change in this setting a link re-training is mandatory
to make it effective.
On recent Intel platforms (tested on Elkhart Lake) the FSP code which is
executed before coreboot performs the PCI scan already enumerates all
PCI buses for its internal uses. While this is done, all the PCI express
features of a link are configured, which includes CCC. If the link
supports common clock, FSP performs the link re-training already. When the
execution flow is returned to coreboot, the same link treatment is
applied again (coded in 'pciexp_tune_dev()') and CCC is enabled a second
time, just a few milliseconds after FSP did this already.
Because enabling CCC requires a link re-training, there are two link
re-trainings on the PCIe link within a few milliseconds (one from the FSP
code and one from coreboot) which can lead to issues with a connected
PCIe device on this link. In particular, link issues were discovered
with a Pericom PCIe switch (PI7C9X2G608) on mc_ehl1 where the link has
stalled for a while after the second re-training. This in turn leads to
non-initialized PCI devices on the bus after coreboot has finished.
This patch checks if CCC is already enabled on a link and does not
perform the steps to enable it again in coreboot which safes a link
re-training (and thus execution time) and a potential link stability
issue.
Test=Check log output on mc_ehl1 which shows the following lines:
[DEBUG] PCI: pci_scan_bus for bus 09
[DEBUG] PCI: 09:00.0 [8086/1533] enabled
[INFO ] PCIe: Common Clock Configuration already enabled
Change-Id: I747fa406a120a215de189d7252f160c8ea2e3716
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73310
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There is a Nanya device used on one of the Google Guybrush devices,
so add it to the list of SPD manufacturer names.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia449f4d14385cdd5a2548e2a05e3928ea3602c12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73254
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
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>
|
|
Found by linter
Change-Id: I7a49cce0b56cf83d0e4490733f9190284a314c4a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
By default this limits PCI buses to CONFIG_MMCONF_BUS_NUMBER.
Some platforms have multiple PCI root busses (e.g. xeon_sp), where bus
numbers are limited. This provides a basic check. On some platforms it
looks like programming 0xff to the subordinate bus number confuses and
hangs the hardware.
Change-Id: I0582b156df1a5f76119a3687886c4d58f2d3ad6f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
<device/pci.h> chain-includes <device/pci_def.h> & <device/pci_type.h>.
Change-Id: I4e5999443e81ee1c4b1fd69942050b47f21f42f8
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72626
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
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>
|
|
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>
|
|
Move specific enum ddr3_module_type to <device/dram/ddr3.h>.
Change-Id: I8fd7892dda26158a5bdd6cd4972c7859a252153e
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71547
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move specific enum ddr2_module_type to <device/dram/ddr2.h>.
Change-Id: I748658f9b349bff9b1ebe2c0a6acf71bf2a221ce
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71546
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
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>
|
|
Unlike gcc, a clang build will fail when only a comment is used to
indicate that the fallthough is intended. To fix the clang build, use
__fallthrough instead. This will fix the build errors introduced by
commit f45c7671d9ed ("Set x86_64 as supported architecture for clang")
that enabled clang builds for a case that uses yabel to run the VBIOS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4ed337025adeb833f352d198fc0f13b5e1c209c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70889
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Don't rely on this being 0.
Change-Id: I7c0d16b6a265bf9c7abcfdf2f18a43706ee03ea1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69752
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
<device/mmio.h>` chain-include `<arch/mmio.h>:
https://doc.coreboot.org/contributing/coding_style.html#headers-and-includes
Also sort includes while on it.
Change-Id: Ie62e4295ce735a6ca74fbe2499b41aab2e76d506
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This patch provides helper functions to read or write a register via the
MDIO bus. They can be used from drivers to easily access registers on
the MDIO bus.
Change-Id: I293d93435d27269a071b4b9b94a1b55307c575a7
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69611
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch extends the available device paths with a new device 'mdio'.
MDIO is the 'Management Data Input/Output' called interface which is
used to access an Ethernet PHY behind a MAC to change settings. The real
payload data path is not handled by this interface.
To address the PHY correctly on the MDIO bus, there is a 5 bit address
needed, which often can be configured via pins on the mainboard.
Therefore, the new introduced device has an 'addr' field to define its
address. If one wants to use a MDIO device in devicetree, the syntax is
straight forward (example):
device mdio 0x2 on end
As the MDIO interface is driven by the MAC, most likely this MDIO device
will be hooked in as a child device of the (PCI attached) MAC device.
With the new introduced ops_mdio a new interface is added to provide an
API for read and write access over MDIO.
Change-Id: I6691f92c4233bc30afc9029840b06f74bb1eb4b2
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69382
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I11593245fedc26489e3506d773aaff1ad34188b1
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69804
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add pcie_find_dsn() to detect and match PCIe device serial
number. In addition, vendor ID is matched when provided.
Change-Id: I54b6dc42c8da47cd7b4447ab23a6a21562c7618
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
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>
|
|
The function pci_scan_bus had 3 post codes in it:
0x24 - beginning
0x25 - middle
0x55 - end
I got rid of the middle postcode and used 0x25 for the code signifying
the end of the function. I don't think all three are needed.
0x24 & 0x25 postcodes are currently also used in intel cache-as-ram
code. Those postcodes should be adjusted to avoid conflicting.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I19c9d5e256505b64234919a99f73a71efbbfdae3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
It is no longer necessary to explicitly add "ERROR: "/"WARNING: " in
front of every BIOS_ERR/BIOS_WARN message.
Change-Id: I22ee6ae15c3d3a848853c5460b3b3c1795adf2f5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
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>
|
|
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>
|
|
Also sort includes.
Change-Id: I1727bf56b4090d040aab413006dec7aca0587d44
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Idd78271f2158bdc29ce9ac8d81f46ad8cbe84c5e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
