_GPE cannot be anywhere but at the root of the ACPI namespace.
This change ensures that is always the case.
Tested on lemp9, GPE still in correct location.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: Ib31683b06e61da4b1859cd939c36879cebf4c03c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43630
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIOs required for DeepSx (e.g. SLP_SUS#) are not hooked up on the
lemp9. Therefore, drop the DeepSx settings.
Tested on lemp9, suspend works correctly.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: Iab179abd7adc3a65dcfc43ce1b5742d514b711fb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43629
Reviewed-by: Michael Niewöhner
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested on lemp9, SA thermal device appears in lspci.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: I527e586b1dae5f8087d2364c63c9db5bcb643214
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Michael Niewöhner
Setting USBx_PORT_EMPTY is not a requirement anymore, since unset
devicetree settings default to 0 and the OC pin now only gets set when
the USB port is enabled (see CB:45112).
Thus, drop the setting from all devicetrees.
Change-Id: I899349c49fa7de1c1acdca24994ebe65c01d80c6
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Fsp configures the USB over-current pin and overrides the according pad
configuration to NF1, regardless of the port being configured as disabled.
Thus, set the OC pin to 0xff ("disabled") in this case to prevent this.
This allows us to skip setting USBx_PORT_EMPTY in the devicetree for
disabled USB ports.
Change-Id: Ib8ea2ea26c0623d4db910e487b37255e907b299d
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45112
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
List of changes:
1. Add required SoC programming till bootblock
2. Include only required headers into include/soc
3. Add CPU/PCH/SA EDS document number and chapter number
4. Include ADL-P related DID, BDF
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I204e692fabb84fce297bebee465f4ca624c6fe56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44857
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Don't configure USB3 port 4 since it's not used.
Change-Id: I6919f5ec3a5be53373f2ab75063764287b53baf5
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Reviewed-by: Michael Niewöhner
According to the xHCI spec, the Slot State field in the Slot Context
Data Structure is 5 bits wide. So, fix the code to match.
ref. xHCI spec 1.2
section 6.2.2, Figure 6-2: Slot Context Data Structure
BUG=none
TEST=xHCI compiles
Change-Id: I0ae735af3d0840aeee846fa939c37af9aea3dff1
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45023
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently HECI3 gets enabled by the option Heci3Enabled, but this
duplicates the devicetree on/off options. Therefore depend on the
devicetree for enablement of the HECI3 controller.
All corresponding mainboards were checked if the devicetree
configuration matches the Heci3Enabled setting, and divergent
devicetrees were adjusted.
Change-Id: Ic7d52096aee225c2ced1e1bc29ca850fe5073edc
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44579
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Previous CL (1916f8969b) misinterpreted
spec as requiring size alignment on all IVHD device entries. The correct
requirement specifies only for 4-byte entries. The unneeded realignments
result in gaps in the table. The kernel hangs in early boot due to the
malformed table.
Remove 8-byte entry alignment.
BUG=b:166519072
TEST=Boot fully to morphius board with and without amd_iommu kernel
parameter. Confirm IVRS contains no alignment gaps/corruption.
Change-Id: Iddcff98279be1d910936b13391dd2448a3bb2d74
Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
ddr_frequency is ambiguous and is interpreted differently in several
places. Instead of renaming this field, this deprecates it and adds
two new fields with unambiguous naming, max_speed_mts and
configured_speed_mts. smbios.c falls back to using ddr_frequency
when either of these fields are 0.
The same value was being used for both configured memory speed and
max memory speed in SMBIOS type 17, which is not accurate when
configured speed is not the max speed.
BUG=b:167218112
TEST=Boot ezkinil, no change to dmidecode -t17
Change-Id: Iaa75401f9fc33642dbdce6c69bd9b20f96d1cc25
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44549
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To allow using the 3 remaining Comet Lake SoCs, add a new Kconfig option
for each of them and configure the paths to FSP header files and FSP
binary.
Change-Id: I4272a6ee08e19769a8a17c93bb3ce2421be0bbc9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Michael Niewöhner
Since there are 4 different versions of FSPs for the Comet Lake
platform, add a new Kconfig option for the currently used SoC being able
to differ between the various SoCs and FSPs.
The new Kconfig option selects the Comet Lake SoC as base for taking
over its specific configuration and is only used for configuring the
path to its specific FSP header files and FSP binary.
Also, adjust all related mainboards so that their Kconfig selects the
new option.
For details, please see
https://github.com/intel/FSP/tree/master/CometLakeFspBinPkg
Built System76/lemp9 with BUILD_TIMELESS=1 before and after this patch
and both images are equal.
Change-Id: I44b717bb942fbcd359c7a06ef1a0ef4306697f64
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
GPP_F14 should be configured to be routed via APIC and not SCI.
BUG=b:162528549
TEST=verified on a volteer
Change-Id: Ie262ceeaea1c07bcc99e1545f5eb99e0d0dee905
Signed-off-by: Alex Levin <levinale@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44948
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While GMP supports fat builds on x86 that adapt to the CPU's
capabilities, by default it builds for the CPU of the builder.
Running that binary on an older CPU then can fail.
Change-Id: Iafdc2eb696189b9e2c5ead316f310d98c949ef74
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45044
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PSP bootloader and verstage are only used out of the RO region,
so don't build them into the RW sections.
BUG=None
TEST=Build & Boot
BRANCH=zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ic7bcb9a6a78926325e80755c010bb047e4a9485c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Eric Peers <epeers@google.com>
This allows a platform to specify the location of the signing token
for the PSP verstage, and build it into the firmware image.
BUG=b:166108929
TEST=Build file into PSP firmware, verify that it's present and has
the correct ID.
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I182ad9b48a2776ccd29ead0f54cfe14c5bf45560
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Eric Peers <epeers@google.com>
To use a signed PSP verstage, we're going to need to build it first,
then sign and store the binary. This patch allows the stored (signed)
verstage binary to be used.
BUG=b:166108929
TEST=Build with existing verstage binary instead of re-building it.
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I5cbceca3b75f05c5460190b1c829d1ffaab2c736
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Eric Peers <epeers@google.com>
Add the field for the PSP verstage signature entry. This adds the
public key signing token to the PSP Directory table to verify the signed
PSP verstage binary
BUG=b:166100797
TEST=Build in a file and verify that it's present with the correct ID.
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I7525045d8746b6857979d07b02758ab4d4835026
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Eric Peers <epeers@google.com>
GCC9 introduced a new warning [-Waddress-of-packed-member]. This
is giving the following warning when building amdfwtool: warning: taking
address of packed member of ‘struct _bios_directory_entry’ may result in
an unaligned pointer value. Looking at the definition of the struct, it
looks like this is probably true.
Since the function being called doesn't read from the values, zeroing
them out in the beginning of the function, the code just passes pointers
to the temporary variables without initializing them.
BUG=None
TEST=Build & use AMD firmware table.
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I2f1e0aede8563e39ab0f2ec6daed91d6431eac43
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Eric Peers <epeers@google.com>
Move PSP_SHAREDMEM_DRAM_END after _etransfer_buffer to ensure that the
transfer buffer actually lives within the 32KiB that is supported to be
transferred. Resulting symbol address change in bootblock.debug file
summarized below.
BEFORE:
02011000 T _psp_sharedmem_dram
02011000 T _transfer_buffer
02011000 T _transfer_info
02011040 T _etransfer_info
02011040 T _vboot2_work
02014040 T _evboot2_work
02019000 T _epsp_sharedmem_dram
02019000 T _preram_cbmem_console
0201a600 T _epreram_cbmem_console
0201a600 T _timestamp
0201a800 T _etimestamp
0201a800 T _fmap_cache
0201ac52 T _efmap_cache
0201ac52 T _etransfer_buffer
AFTER:
02011000 T _psp_sharedmem_dram
02011000 T _transfer_buffer
02011000 T _transfer_info
02011040 T _etransfer_info
02011040 T _vboot2_work
02014040 T _evboot2_work
02014040 T _preram_cbmem_console
02015640 T _epreram_cbmem_console
02015640 T _timestamp
02015840 T _etimestamp
02015840 T _fmap_cache
02015c92 T _efmap_cache
02015c92 T _etransfer_buffer
02019000 T _epsp_sharedmem_dram
BUG=b:167243965
BRANCH=None
TEST=checked 'cbmem -1' for FMAP error after ec reboot
Signed-off-by: Josie Nordrum <josienordrum@google.com>
Change-Id: I9b482aced5deb40bd87d19d9c42585d8a6db5fc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45045
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some Trogdor variants power their USB hub from a PMIC LDO that is
already enabled by QcLib, and some have a discrete LDO that is
controlled by GPIO_84. For the latter, let's make sure we assert that
GPIO on boot.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9d206cd7154ded3bf179e68c2b1421d0a8ee89f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: mturney mturney <mturney@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Philip Chen <philipchen@google.com>
We're moving a lot of pins around on Trogdor again. For firmware this
only affects the RAM and SKU strapping ID pins. Since there are quite a
few of the old devices in circulation this time and some people seem to
care about mosys RAM information working, let's actually check the board
revision and support both cases this time.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If7728d8ea4b7f6e7ff6721ade90f975f6efd5ddd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Philip Chen <philipchen@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Set tcc offset to 5 degree celsius
2. Apply the DPTF parameters receive from the thermal team.
3. Change PL2 min value from 25W to 15W.
BUG=b:167477885
BRANCH=puff
TEST=build and verify by thermal team
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Change-Id: I68fdefe99cf36a39797c29ad84d08321bb8175f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This reverts commit 2ad859988b.
Reason for revert: broke the build
Change-Id: I7e7d917c2e8b698d5c7c3ce0b6d34e80696185f3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44993
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Add new SPD file, "samsung_dimm_K4E8E324ED-EGCG.spd.hex".
2. Add SPD support in Rammus memory table, as follows:
SPD_SOURCES += samsung_dimm_K4E8E324ED-EGCG # 0b0110
SPD_SOURCES += samsung_dimm_K4E6E304ED-EGCG # 0b0111
BUG=b:166576463
BRANCH=firmware-rammus-11275.B
TEST=emerge-rammus coreboot chromeos-ec chromeos-bootimage
Flash FW to DUT, and make sure system boots up.
Signed-off-by: Kane Chen <kane_chen@pegatron.corp-partner.google.com>
Change-Id: I82386507c4e996e0a59c26ce50de3bced45b1196
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44854
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:153888802
TEST=Able to list correct eSPI frequency as per TGL SPI flash guide
Without this CL :
Found Component Section
FLCOMP 0x093030f6
Dual Output Fast Read Support: not supported
Read ID/Read Status Clock Frequency: 50MHz
Write/Erase Clock Frequency: 50MHz
Fast Read Clock Frequency: 50MHz
Fast Read Support: supported
Read Clock Frequency: 20MHz
With this CL :
Found Component Section
FLCOMP 0x093030f6
Dual Output Fast Read Support: not supported
Read ID/Read Status Clock Frequency: 50MHz
Write/Erase Clock Frequency: 50MHz
Fast Read Clock Frequency: 50MHz
Fast Read Support: supported
Read eSPI/EC Bus Frequency: 60MHz
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I20840e6f931d7c1fabea0b6892e3bd19ead81168
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
BUG=b:153888802
TEST=Able to list correct SPI frequency as per TGL SPI flash guide
Without this CL :
Found Component Section
FLCOMP 0x093030f6
Dual Output Fast Read Support: not supported
Read ID/Read Status Clock Frequency: 33MHz
Write/Erase Clock Frequency: 33MHz
Fast Read Clock Frequency: 33MHz
Fast Read Support: supported
Read Clock Frequency: 20MHz
With this CL :
Found Component Section
FLCOMP 0x093030f6
Dual Output Fast Read Support: not supported
Read ID/Read Status Clock Frequency: 50MHz
Write/Erase Clock Frequency: 50MHz
Fast Read Clock Frequency: 50MHz
Fast Read Support: supported
Read Clock Frequency: 20MHz
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: Id0a0a0cbd948ef8334cf522c09e881b464e87f0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44819
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Consider IBEX_PEAK onwards all chipsets are belong to PCH family.
BUG=b:153888802
TEST=Able to print correct PCH revision on Hatch Platform.
> ifdtool -d coreboot.rom
Without this CL :
ICH Revision: 300 series Cannon Point/ 400 series Ice Point
With this CL :
PCH Revision: 300 series Cannon Point/ 400 series Ice Point
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: Ifd40dddc9179f347c0ea75149ec08089a829fdb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
BOOTBLOCK_CONSOLE is already set to yes in console/Kconfig file.
Change-Id: I2a4ee517795bc7b378afc5eae92e2799ad36111b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
GENERATE_SMBIOS_TABLES is already set to yes at src/Kconfig
Change-Id: I2845f4f329283360a49ea40dfee7d9a232ab4ea1
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Jeremy Soller