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>
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>
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>
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 9260ea60bf
(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 117e436115) had to be
reverted because of missing resource reservations in platform code.
This is worked around now with commit ae81497cb6 (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>
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 655f7362e1.
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>
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>
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 f45c7671d9 ("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>
