Provide 3 separate functions for each openSIL time point instead of one,
so that we don't need the xSIM-api header file to be included in
opensil.h to decouple the coreboot code more form the openSIL code. This
will allow to create an openSIL stub implementation to already get most
of the coreboot-side SoC code in place before the openSIL source code is
done and released.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I969bc0862560b7254c48f04e9a03387417f328bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
When a device with no resource is passed it will keep overwriting
the current slot. Remove the conditional and allow a PCI device
to not have any resources.
This is particular useful for the next commits that makes use
of the PCI resource store to pass UBOX devices to SMM that allow
to lock-down SMM from within an SMI handler. Those devices do
not have any resources and cannot be hardcoded in SMM as their
PCI segment group and bus number varies depending on socket
count, CPU discovery and configuration.
Change-Id: I1a1b5944c97da5be6b9794c653b5159683f492e5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80246
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Commit d252776668 ("tree: Replace And(a,b) with ASL 2.0 syntax")
replaced two instances of `And(var, mask) == 0` with `var & mask == 0`.
This expression needs parentheses - `(var & mask) == 0`.
Without parentheses, it is always false, since the masks are nonzero
(`var & (mask == 0)`; `var & 0`; `0`).
This caused brightness changes on Intel GMA to take longer than
normal since the status was never checked. The brightness would
change immediately, but another brightness change could not occur until
the first change timed out.
This was most noticeable in KDE, which waits for the brightness change
to complete before accepting another brightness up/down keypress.
Tapping brightness up/down repeatedly would take much longer to reach
max/min brightness due to many presses being ignored.
It is noticeable in GNOME as well but less obvious. Tapping brightness
up/down repeatedly would handle all keypresses, but the display's
actual brightness would lag behind and skip some intermediate steps.
I tested both Librem 13v2 and Librem 14, as far as I know this would
apply to all systems configuring brightness with Intel GMA.
Test: Verify brightness keys respond quickly again on Librem 13v2 / 14.
Change-Id: I57895e8c654c83368b452d7adfe1856c0a0341fb
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80260
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch adds support for the new command-line option `-E` to
the ifdtool, which enables users (primarily factory users) to
protect GPR0.
Additionally, this patch refactors some code while adding support for
enabling GPR0 protection.
For more information on the scope of GPR0 (General Protection Range 0),
please refer to the Intel Meteor Lake-U Type 4 Client Platform SPI
Programming Guide, Document Number 768150.
BUG=b:270275115
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
> ifdtool -p mtl -E image.bin -O image.bin_lock
...
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
...
GPR0 protection is now enabled
Change-Id: I27c533ae4109c79299f4e7ff75e750d7cc64280f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
On Brox, HDA Codec used is ALC256. Add verb table for the same. Also,
add the related device tree changes for HDA related registers.
Realtek High Definition Audio Configuration-
Version : 5.0.3.1
BUG=b:317398558
BRANCH=None
TEST=verified HDA on Brox.
HDA Sound cards detected. Headphone working verified.
Device listed under sysfs as below:
cat /sys/bus/hdaudio/devices/ehdaudio0D0/chip_name
ID 256
cat /sys/bus/hdaudio/devices/ehdaudio0D0/vendor_name
Realtek
Change-Id: I1edd5aee053debe39b34048266703031c088cd00
Signed-off-by: Poornima Tom <poornima.tom@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79723
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the SoC-specific memory map is reported on the domain device
instead of the northbridge device, factor out the
read_soc_memmap_resources function from root_complex.c to new memmap.c
file. For now each SoC still has its own memmap.c file, but the plan is
to eventually have a common implementation that works for all AMD family
17h+ SoCs. For that I'll still need to look closer into the differences
between the FSP and the openSIL integration though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifd7659e9a55de9df24118b6d6c885a21dc6f14a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since reporting the PCI ECAM MMCONF MMIO region and the IO ports for the
legacy PCI config space access is needed on all AMD SoCs, implement a
common add_pci_cfg_resources function that reports both and gets called
from amd_pci_domain_read_resources and don't report those in the SoC-
specific code any more. The only functional change is that on Genoa now
the IO ports used for the legacy PCI config space access get reserved.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibbcc2aea4f25b6dc68fdf7f360e5a4ce53f6d850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
To make add_opensil_memmap match the other function that are directly or
indirectly called by amd_pci_domain_read_resources, pass the resource
index as a pointer instead of passing it by value and then returning the
new resource index.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a17e488a01cc52b2dab5dd3e3d58bdf3acb554d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Introduce read_soc_memmap_resources which gets called by
amd_pci_domain_read_resources for the first domain of the SoC to report
the DRAM and PCI config space access resources to the allocator. For
Genoa this allows to use amd_pci_domain_read_resources as read_resources
in the genoa_pci_domain_ops instead of needing to wrap that call to be
able to call add_opensil_memmap for the first domain. For the other
family 17h+ SoCs the moves the reporting of the DRAM resources and the
PCI config space access resources from the northbridge device to the
domain device.
TEST=Resources still get reported on Mandolin, but now under the domain
instead of the northbridge PCI device
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib19fd94e06fa3a1d95ade7fafe22db013045a942
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80268
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Previously the code checked if the first downstream bus of the domain
was bus 0 in segment group 0 to only run certain code for the first
domain. Instead check if the domain number is 0 which should make the
code a bit easier to understand.
TEST=add_opensil_memmap still gets called exactly once on Onyx
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id8cc0078843e5e0361a53ba897cde508cee16aad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of manually crafting S:B:D:F numbers for every
VTD device loop over the entire devicetree by PCI DEV IDs.
This adds PCI multi-segment support without any further code
modifications, since the correct PCI segment will be stored in the
devicetree.
Change-Id: I1c24d26e105c3dcbd9cca0e7197ab1362344aa96
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80092
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Attach UBOX stacks on newer generation Xeon-SP.
In order to use PCI drivers for UBOX devices, locating UBOX devices
by vendor and device IDs and replacing device access by specifying
S:B:D:F numbers, add a PCI domain for the UBOX stacks and let the
PCI enumerator index all devices.
Since there are no PCI BARs on the UBOX bus the PCI locator doesn't
have to assign resources on those buses.
Once all PCI devices on the UBOX stack can be located without knowing
their UBOX bus number and PCI segment the Xeon-SP code can fully
enable the multi PCI segment group support.
Test: ibm/sbp1 (4S) is able to find all PCU devices by PCI ID.
Change-Id: I8f9d52dd117364a42de1c73d39cc86dafeaf2678
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80091
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
With Cr50, the GPIO EC_IN_RW is used to determine whether EC is trusted. However, With the switch to Ti50, it is determined by Ti50's boot mode. If the boot mode is TRUSTED_RO, the VB2_CONTEXT_EC_TRUSTED flag will be set in check_boot_mode(). Therefore in the Ti50 case get_ec_is_trusted() can just return 0.
The current code of get_ec_is_trusted() only checks the GPIO, which
causes the EC to be always considered "trusted". Therefore, correct the return value to 0 for TPM_GOOGLE_TI50.
BUG=b:321172119
TEST=emerge-nissa coreboot chromeos-bootimage
TEST=firmware_DevMode passed in FAFT test
Change-Id: I308f8b36411030911c4421d80827fc49ff325a1b
Signed-off-by: Qinghong Zeng <zengqinghong@huaqin.corp- partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
The current panel voltage measured at mainboard side is 1.79V and the
voltage at panel side is 1.74V. Since the panel requires 1.8V or more,
increase the circuit voltage to 1.9V to meet the panel requirement.
After adjustment mainboard side voltage is 1.89V and panel side is
1.84V.
BUG=b:322080023
TEST=Check ciri vm18 ldo voltage
BRANCH=None
Change-Id: I6d6193d45409f53c0b656890c44ddaef253c5e01
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80198
Reviewed-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's what this function family is defined to do, we currently don't
usually run into the case (see: not too many die() instances going
around), it's more useful to try to recover, and the JPEG parser can run
into it if the work buffer size exceeds the remaining heap, whereas its
sole user (the bootsplash code) knows what to do when seeing a NULL.
Use xmalloc() if you want an allocation that either works or dies.
tl;dr: That code path isn't usually taken. Right now it crashes. With
this patch it _might_ survive. There is a use-case for doing it like
that now.
Change-Id: I262fbad7daae0ca3aab583fda00665a2592deaa8
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
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>
CXL IIO stacks
When an IIO stack is connected with CXL cards, its bus range
will be divided by a PCI host bridge object and a CXL host
bridge object, otherwise, all its range will be owned by the
PCI host bridge object. Accordingly, CXL ACPI resources should
be only created when the IIO stack is connected with a CXL
card.
TEST=intel/archercity CRB
Change-Id: I6c1b1343991bc73d90a433d959f6618bbf59532f
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80087
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently resource allocation starts top down from the default value
0xfe000000. This does not match what ACPI reports, so adapt
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT to reflect that.
Change-Id: I32d08ffd5bbd856b17f7ca2775c5923957d92c85
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The CRAT (Component Resource Attribute Table) isn't used on the APUs
from Renoir on and has also been marked as deprecated in version 6.5 of
the ACPI specification. So remove the 'TODO: look into adding CRAT'
comment from all SoCs from Renoir/Cezanne on.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3ea1e3678608b0ace2a1ff7fc104594e90c91476
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80227
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the acpi_add_fsp_tables implementation is identical for all SoCs,
factor it out and move it to the common AMD FSP code. Also guard the
acpi_add_fsp_tables call in soc_acpi_write_tables with
if (CONFIG(PLATFORM_USES_FSP2_0)) to properly handle the FSP dependency.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8917a346f586e77b3b3278c73aed8cf61f3c9e6a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80225
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Factor out acpi_add_fsp_tables from the soc_acpi_write_tables function
and move the remaining parts of the soc_acpi_write_tables function to
the SoC's acpi.c. This aligns the other family 17h/19h SoCs more with
Genoa and only leaves the FSP-specific code in agesa_acpi.c which will
be made common in a following patch. I decided against also renaming
agesa_acpi.c to acpi_fsp.c, since that would have made the diff less
readable and the files get deleted in a following patch anyway.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia87ac0e77c5e673e694703b85a4bab85a34b980e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
A pointer to soc_acpi_write_tables gets assigned to the
write_acpi_tables element of the device_operations struct, so make sure
that the function has the expected function signature which in this case
means using unsigned long as type for both the 'current' parameter and
the return value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iee45badb904fa20c6db146edbc00c40ca09361d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80218
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As a result of hardware changes on this board, the PHY previously
routed to the PSE GbE 1 is now routed to PSE GbE 0 on the Elkhart Lake
SoC.
This patch changes the device PCI ID in the board's devicetree and
accordingly, the GPIO configuration.
BUG=none
TEST=Boot into Linux and observe whether both PSE GbE 0 and PCH GbE
are working, while PSE GbE 1 remains inactive (not listed by 'ip link')
.
Change-Id: I322371f944d15134e6f48ecd84a4026c2fced27b
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
