Modify the chromeos FMD file for nissa variants to redistribute the
buffer in SI_ME region obtained due to CSE size optimizations to SI_BIOS
region.
1. Modify SI_ALL region size to 3712K. SI_DESC remains at 4K and SI_ME
is 3708K.
2. Modify SI_BIOS region to 12672K. This results in an addition of 32K
buffer each to FW_MAIN_A/B regions.
BUG=b:228936671
BRANCH=firmware-nissa-15217.B
TEST=Verify CSE FW update with new FMD and ME RW blobs on craask.
Cq-Depend: chrome-internal:5094491
Change-Id: I5ead2f81850a2aa79e677c7f271db672e235750a
Signed-off-by: Krishna P Bhat D <krishna.p.bhat.d@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
+-----------+-------+-------+---------+-------------+----------+
| Setting | AC LL | DC LL | ICC MAX | TDC Current | TDC Time |
| |(mOhms)|(mOhms)| (A) | (A) | (msec) |
+-----------+-------+-------+---------+-------------+----------+
| IA | 2.8 | 2.8 | 80 | 43 | 28000 |
+-----------+-------+-------+---------+-------------+----------+
| GT | 3.2 | 3.2 | 40 | 23 | 28000 |
+-----------+-------+-------+---------+-------------+----------+
- IA TDC current from 20A to 43A.
- GT TDC current from 20A to 23A.
BUG=b:256754175
TEST=Build test image and use PTAT to check IA and GT value
Signed-off-by: Johnny Li <johnny_li@wistron.corp-partner.google.com>
Change-Id: Ife36655f077bae567bff3c3e33f779c990cf5ed9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69135
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Yang <paul.f.yang@intel.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
revert commit 1b9e740a8 (kconfig: fix failing to generate auto.conf) [1]
The above change caused all of the enabled kconfig options to be written
into the top level build directory. We don't want that, so go back to
the old behavior for the coreboot tree.
[1] 1b9e740a81
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2904f69a5d85337ad0a6b48590ccd4b4a6e38b70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
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>
