Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
1) LP5 Memory - 2GB Micron MT62F512M32D2DR-031 WT:B
2) LP5 Memory - 2GB Hynix H9JCNNNBK3MLYR-N6E
3) LP5 Memory - 4GB Samsung K3LKBKB0BM-MGCP
4) LP5 Memory - 4GB Hynix H9JCNNNCP3MLYR-N6E
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
H9JCNNNBK3MLYR-N6E 0 (0000)
K3LKBKB0BM-MGCP 1 (0001)
H9JCNNNCP3MLYR-N6E 2 (0010)
BUG=b:292461498
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: I02e49d60e43c4fed8356556ec194d726c30cd609
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Set the cs_pi_start_high_in_ect if the DUT is using one of the two
following Hynix parts: H54G56CYRBX247 and H54G46CYRBX267. Failure to
set cs_pi_start_high_in_ect when using these parts will result in an
MRC cache failure and DUT will fail to boot.
BUG=b:292153199
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot brya
variant to kernel.
Change-Id: I36040139b959c85c3ac220a34574caa12ca6c5fe
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
With currently set default PSP_SOFTFUSE_BITS for phoenix SoC,
the non-serial build does not boot on Myst.
Override PSP_SOFTFUSE_BITS by disabling SPIConfig to also get
the non-serial build booting.
The documentation of PSP_SOFTFUSE_BITS is available in #55758 doc (NDA).
BUG=b:292489356
TEST=Flash image-myst.bin, verify that it's able to boot on Myst
proto0.
Change-Id: Id4472fd85fdefcafb8378199dbaa054fab8b3274
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76713
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Necessary to allow coolstar's Windows touchpad driver for this board,
since the touchpad is attached to the SMBus. The VID/DID combo used is
not registered/doesn't conflict with any currently in use, and would
be difficult to change at this point since the Windows drivers have
already been signed.
TEST=build/boot Win11, Linux on butterfly/lumpy/parrot, verify
touchpad driver works properly.
Change-Id: Ica3756e117fc58166958f37e7b007abb79d9d350
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76744
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Necessary to allow coolstar's Windows touchpad driver for this board,
since the touchpad is attached to the SMBus. The VID/DID combo used is
not registered/doesn't conflict with any currently in use, and would
be difficult to change at this point since the Windows drivers have
already been signed.
TEST=build/boot Win11, Linux on butterfly/lumpy/parrot, verify
touchpad driver works properly.
Change-Id: Ie1d882cac90211541a636d2dab297c343a12d66d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76743
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Necessary to allow coolstar's Windows touchpad driver for this board,
since the touchpad is attached to the SMBus. The VID/DID combo used is
not registered/doesn't conflict with any currently in use, and would
be difficult to change at this point since the Windows drivers have
already been signed.
TEST=build/boot Win11, Linux on butterfly/lumpy/parrot, verify
touchpad driver works properly.
Change-Id: I61912fd6db9eb4b8d202ab633b8c7ca5913e759f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
After switching to S3, it was found that drives on the SATA port do not
exit D3cold on S3 exit. Disable RTD3 on the port until the issue can be
resolved.
Avoids the following error in Linux:
pcieport 0000:00:1d.0: Unable to change power state from D3cold to D0, device inaccessible
Tested on darp8 with a Samsung 970 EVO or Crucial P5 in J_SSD1.
Change-Id: Ib26f59db61acfbf9248cea379c197765d3d9c470
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76593
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit e33d253793 ("soc/amd/common/block/acpi/ivrs: fix
missing IOAPIC[1] error").
Now that the per PCI root domain IOAPIC MMIO resource is reported on the
domain device, we can again probe the resource on the domain device
instead of the northbridge PCI device in that domain. This will make the
IVRS code compatible again with the work in progress Genoa SoC support.
TEST=Linux doesn't complain about the IOAPIC[1] missing in the IVRS on
Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib861b19d798fc8ee6603e8803d8d1939be08d275
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76659
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Call read_non_pci_resources from amd_pci_domain_read_resources to tell
the resource allocator about the non-PCI MMIO regions within the data
fabric MMIO regions so that the allocator won't place any PCI MMIO in
the same areas.
TEST=On Mandolin 3 new non-PCI resources get reported to the allocator:
avoid_fixed_resources: DOMAIN: 0000 04 base fd100000 limit fd1fffff mem (fixed)
avoid_fixed_resources: DOMAIN: 0000 05 base fd000000 limit fd0fffff mem (fixed)
avoid_fixed_resources: DOMAIN: 0000 20000120 base fec01000 limit fec01fff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7f69b86e376e3368d4f156ccf93791cc00886489
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Introduce the common read_non_pci_resources function to read the base
address of the non-PCI resources within the MMIO regions configured in
the data fabric registers and pass that info to the resource allocator.
Each SoC will need to provide implementations for get_iohc_misc_smn_base
and get_iohc_non_pci_mmio_regs in order for read_non_pci_resources to
know the SoC-specific base addresses, register offsets and MMIO region
sizes. In case of SoCs with only one PCI root domain, the domain
parameter of get_iohc_misc_smn_base will be unused, but in the case of
SoCs with more than one PCI root domains, this parameter will be used by
the SoC-specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If9aca67fa0f5a0d504371367aaae5908bcb17dd9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The SuperIO is not used so don't enable decoding of 0xE2 and
drop all code using it. It's not even required for the virtual
UART on 0x3f8 to work.
Add the virtual UART on 0x3f8 as ACPI device.
TEST: Verified on SBP1 that serial still works.
Change-Id: I8e431a0c8417435cc6e3ba16f97ff080e1656a7b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add pujjo new supported memory parts in mem_parts_used.txt, generate
SPD id for this part.
1. Hynix H58G56BK7BX068
2. Samsung K3KL6L60GM-MGCT, K3KL8L80CM-MGCT
3. Micron MT62F1G32D2DS-026 WT:B
BUG=b:292452868
TEST=Use part_id_gen to generate related settings
Signed-off-by: Leo Chou <leo.chou@lcfc.corp-partner.google.com>
Change-Id: Ia123a1cfd93a5e08ab0ba65f1d9be240d60ff356
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76672
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch increases the `tcc_offset` to reduce the TCC
(Thermal Control Circuit) activation temperature to avoid running
into abrupt power off during power cycle tests.
On Intel processors, the core frequency can be by an HW agent when
the current temperature reaches the TCC activation temperature.
The default TCC activation temperature is specified by MSR_IA32_TEMPERATURE_TARGET (which is 90°C for google/rex variants).
However, this patch adjusted the TCC by specifying an offset in
degrees C (i.e., using `tcc_offset` from variant override device tree).
Note: The bigger the TCC offset is, the lower the effective TCC activation temperature would be, to ensure that processors can be throttled earlier before the system critical overheats.
BUG=b:283008762
TEST=Able to perform power cycle on google/screebo w/o any crash/shutdown.
Change-Id: Ib19703877dbbfc26b2d9f538dda4f10c27cf872d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76658
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Hook the PchHdaSdiEnable UPD so that mainboard can change the
settings via devicetree. PchHdaSdiEnable UPD enable HDA SDI lanes.
BUG=b:268546941
TEST=Verified the settings on google/brya using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I82bbfa5442936aefa53f8826e395b7ce75c895a3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Adding EC_HOST_EVENT_PANIC to SCI mask allows the EC to interrupt the
Kernel when an EC panic occurs. If system safe mode is also enabled
on the EC, the kernel will have a short period to extract and save info
about the EC panic.
BUG=b:290985698
BRANCH=firmware-volteer-13672.B
TEST=Observe kernel ec panic handler run when ec panics
Change-Id: I87173f93d0e47baa816d15dad0777007342b4fdb
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch creates a new variant rex4es. The new variant will support ESx samples. The existing rex variant will support the QS samples.
BUG=b:290732344
TEST=Able to build google/rex4es board and boot on target hardware.
Change-Id: I25dd1f42ee812f47289da0c2ef7aa79d6f340d48
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch creates a rex model so that other variants developed using
`rex` baseboard are easy to land without duplicating the config
selection.
So far, `rex0` and `rex_ec_ish` are developed using the `rex` model.
The plan is to extend the support for `rex4es` and `rex4es_ec_ish`
variants.
TEST=Able to build and boot google/rex.
Change-Id: Id4e8d1162da93b7266ee1108f870e89b6d884ab9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76608
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
acpi.c contains architectural specific things like IOAPIC, legacy IRQ,
DMAR, HPET, ... all which require the presence of architectural headers.
Instead of littering the code with #if ENV_X86 move the functions to
different compilation units.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5083b26c0d4cc6764b4e3cb0ff586797cae7e3af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
With arm64 -Wstack-usage= is enabled which is triggered on any use of
alloca(). Since this function basically works on x86 without wrecking
things and causing massive stack consumption it's unlikely to cause
problems on arm64.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5d445d151db5e6cc7b6e13bf74ce81007d819f1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76007
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
AGESA S3 restore needs to occur before SMM finalization/locking,
but it's a crapshoot as to which runs first since both use the same
BS_OS_RESUME/BS_ON_ENTRY boot state callback, and there's no way
to prioritize/force ordering.
To work around this, move the AGESA S3 resume call to the preceding
boot state (BS_OS_RESUME_CHECK) to ensure it runs first, and guard it
to ensure it only runs on the S3 resume path.
BUG=none
TEST=build/boot google/liara, verify S3 resume successful.
Change-Id: I765db140c6708a0b129f79fb7d3dc8a4ab3095bd
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76592
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>