Simply return the current resource settings in the _PRS method. This
means that coreboot has to correctly set up the resources on the
device. This won't result in any regression as without _PRS the ACPI
OS would not know what resources settings are valid, so it would never
use _SRS.
Change-Id: I2726714cbe076fc7c772c06883d8551400ff2baa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64218
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This patch adds unique device-locators, bank-locators and
asset-tags to the smbios type17 tables by making use of a
DIMMs controller-ID. This way we avoid name clashes when,
for example, two DIMMs share the same channel-ID and DIMM-ID
but have a distinct controller-ID.
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Change-Id: I8aef79faa43f2475485f581c675ee152e580f678
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The dimm_info structure (defined in src/include/memory_info.h)
currently does not hold information about the DIMM's
node/controller ID.
This patch extends the dimm_info structure by adding a new field for
the node ID, called node_num. Also, adapt the dimm_info_fill()
function accordingly to populate the newly-added field.
Background: These changes are necessary for the Atlas mainboard, where
we are currently experiencing issues with the DIMMs device/bank
locator. Our 2 DIMMs share the same CHANNEL and DIMM ID but have a
distinct NODE ID. By looking at the smbios table we see
Channel-0-DIMM-0 for both DIMMs. Thus, we need their NODE IDs in order
to distinguish them.
This patch was tested by building and booting for the Alderlake-P
RVP board, which has the same DIMM slot configuration as the
Prodrive Atlas mainboard.
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Change-Id: I6ffa5bdff0ba0e3c4a4a51f2419291fd1278cd68
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68525
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update touchscreen setting.
Change hid as panel team request to fix touchscreen with no function.
The panel team verification result is on b/251378772 comment#17.
BUG=b:251378772
TEST=Build/boot ChromeOS on winterhold, ensure touchscreen is
functional.
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I07d446111b1c18bfe15d00b6eacff23382cd461a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
None of the touchscreens (over I2C) used in the rex program requires
exporting GPIOs in the ACPI _CRS method.
This can cause i2c devices to malfunction or cause timing
sequence violations if ACPI exports a PowerResource for the
device that uses GPIOs that are also exported in _CRS.
BUG=none
TEST=Able to build and boot Google, Rex platform.
Without this patch:
[ERROR] I2C: 00:10: Exposing GPIOs in Power Resource and _CRS
With this patch:
None
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I578a60eff27f94d6dc94b900604bc7560337d60b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69612
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As per Intel doc #627331 Section 3.6.1 "Intel CSME Production Machine
Determination", from ADL onwards there are three criteria which
determine whether a device is in production mode:
1. Fuses are programmed
2. SPI descriptor is locked
3. Manufacturing variables are locked
When logging whether the device is in manufacturing mode, 1 and 2 are
already checked. Add a check for 3 as well.
Also add logs for each individual criteria so it's easy to tell why the
overall Manufacturing Mode is set or not.
BUG=b:255462682
TEST=On a nivviks which has not gone through EOM:
Before:
[DEBUG] ME: Manufacturing Mode : YES
[DEBUG] ME: SPI Protection Mode Enabled : NO
After:
[DEBUG] ME: Manufacturing Mode : YES
[DEBUG] ME: SPI Protection Mode Enabled : NO
[DEBUG] ME: FPFs Committed : NO
[DEBUG] ME: Manufacturing Vars Locked : NO
On an anahera which has gone through EOM:
Before:
[DEBUG] ME: Manufacturing Mode : NO
[DEBUG] ME: SPI Protection Mode Enabled : YES
After:
[DEBUG] ME: Manufacturing Mode : NO
[DEBUG] ME: SPI Protection Mode Enabled : YES
[DEBUG] ME: FPFs Committed : YES
[DEBUG] ME: Manufacturing Vars Locked : YES
Change-Id: Iac605baa291ab5cc5f28464006f4828c12c748fe
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69324
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `hyper_threading` CMOS option was hooked up to the wrong enumeration
and lacked a default value in `cmos.default`. Thus, use the correct enum
for the `hyper_threading` option, remove the now-unused "backwards" enum
and provide a default value in `cmos.default`.
Change-Id: I2ee9ced2881ed5e348e84a35e8abd6b7a363d936
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69491
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When ACPI GPE0 block was extended to 64 events or 8 bytes,
ACPI PM register space was slightly modified. After
adjustment, PM2_CNT register moved to 0x50 where register
SS_CNT was previously defined to be.
For platforms that have a valid use for PM2_CNT==0x50 in
their FADT, remove overlapping definition of SS_CNT.
On i82801dx/gx ACPI GPE0 supports 32 events, reset_gpe0_status()
incorrectly addressed also GPE0_EN register. For a bit cleaner
implementation, define GPE0_HAS_64_EVENTS.
Change-Id: Iec83e9010146ebd487a61f542ac5c6f4c6a60833
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
If TSEG is not enabled, smm_region() should not reserve the region, so
add a test for T_EN flag in ESMRAMC.
For the SMM_ASEG case this moves CBMEM immediately below top-of-ram.
Change-Id: I2da4b846d0767afe00e98fdee375914c1875ddf5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
As per Intel doc #729124 Section 3.6.1 "Intel CSME Production Machine
Determination", from ADL onwards there are three criteria which
determine whether a device is in production mode:
1. Fuses are programmed
2. SPI descriptor is locked
3. Manufacturing variables are locked
When logging whether the device is in manufacturing mode, #1 and #2 are
already checked. Add a check for #3 as well.
TEST=Build and boot MTL RVP
Snippet from coreboot log:
[DEBUG] ME: Manufacturing Mode : YES
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I495a7d8730716fc92e8c57b2caef73e8bb44d30b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Update header files for FSP for Meteor Lake platform to
version 2404_00, previous version being 2364_00.
FSPM:
1. Address offset changes
2. Rename `PlatformDebugConsent` to `PlatformDebugOption`
FSPS:
1. Address offset changes
Additionally, incorporate the UPD name change for MTL romstage.
BUG=b:255481471
TEST=Able to build and boot Google, Rex to ChromeOS.
Signed-off-by: vjadeja-intel <vikrant.l.jadeja@intel.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I63ef4ecb6569141542a3b9bf4ee8cbcd2946582e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
