The offset between registers has to be between different channels.
Change-Id: Ic6d959c31c78073a3ecbf7a17dfb73ac36340599
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This port isn't packed on the board, so remove from
the devicetree.
BUG=b:154585046,b:156429564
BRANCH=none
TEST=none
Change-Id: Ib4aee337f67453adcebff7e93e25db7a838e3b2d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42269
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change reconfigures SPI speeds after FSP-S has run since
FSP-S is currently configuring the SPI frequency when it should
not. Until FSP-S behavior is fixed, this workaround needs to be
applied.
BUG=b:153506142
TEST=Verified that em100 works fine.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id9b8330c6f82c7162ff91e8cc10160fdd8cfedab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested with BUILD_TIMELESS=1, Roda RK9 does not change.
Change-Id: Ie05f484cf4b346601e6128c95ff2b27ce59b995f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42188
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with BUILD_TIMELESS=1, Intel DG43GT does not change.
Change-Id: Ifd5b8cd7644811a56afae82468c8eb0a7b6b7ff9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42157
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The picasso_ prefix on the fsp_pcie_descriptor and fsp_ddi_descriptor
structs isn't needed, since this code is picasso-specific, so drop it.
Change-Id: Ia6a0ddb411aa64becc3c23a876f2ea43cb68e028
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42252
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update DPTF_TSR2_SENSOR_ID to 2. Fixes the issue where TSR1 and
TSR2 have the same DPTF_TSR#_SENSOR_ID value causing them to
report the same temperature under /sys/class/thermal
and also swap TSR0 and TSR1 in DTRT to match physical sensor
in volteer schematics
BRANCH=None
BUG=b:149722146
TEST=On volteer system check TSR1 and TSR2 temperatures, should
report different values
`cat /sys/class/thermal/thermal_zone[3,4]/temp`
Also verify other TSRs using `cat /sys/class/thermal/thermal_zone*/temp`
and `ectool tempsinfo all ; ectool temps all`
Signed-off-by: Deepika Punyamurtula <deepika.punyamurtula@intel.com>
Change-Id: Idc5f35e4faf59b0ee726eb32a08eab4654fb342d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42232
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 9ff4029db9.
Pulling the toplevel Makefile into a tiny one has all sorts of side
effects. For instance, the toplevel (random) .config is also included
so the results depend on the board that is selected there. What finally
broke it is a line that is unconditionally printed for AMD Picasso
boards resulting in lots of lines like this:
skipping LENOVO_W520 because we're missing compilers for \
(Adding PSP c7ce61492157d3237f679c4a40a08b79 \
.../coreboot/3rdparty/amd_blobs/picasso/PSP/PspBootLoader_prod_RV.sbin)
While both issues, the random .config and amd/picasso, could be worked
around easily, it seems hard to predict what other pitfalls are lurking
in the Makefile inclusion. Also, the problem solved by its inclusion
can be fixed by a much simpler `make .xcompile`.
Change-Id: I2ff70f561d717eb30e5f3c06c83e83468e174ec5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
abuild requires the `.xcompile` file to be present already before it
runs any actual `make` builds that would generate it.
Change-Id: Ib485e7741b7700fa241c192e60900ae5f1d977f5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Combine the Ucode binaries for 3 revisions of CPU into one
CBFS module.
This should be moved to the AMD common code later.
BUG=b:153580119
TEST=mandolin
Change-Id: Ib08a65b93c045afc97952a809670c85831c0faf7
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Selecting VBOOT_LID_SWITCH under BOARD_GOOGLE_BASEBOARD_HATCH creates a
requirement for VBOOT, and prevents building in the non-vboot/non-ChromeOS
case. As this symbol is already selected by CHROMEOS below, there's no need
for the baseboard (and only one of the two) to select it, so don't.
Change-Id: I060e82185997bce451648173dd97dd6a3d5d237f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Replace 'cse_bp'(cse boot partition) and 'ME' with 'cse_lite' in all log
messages in the cse_lite.c.
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I3fc677c9ec1962199c91cc310d7695dded4e0ba0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41972
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some cases could not be factored out while keeping reproducibility.
Also mark some potential bugs with a FIXME comment, since fixing them
while also keeping the binary unchanged is pretty much impossible.
Tested with BUILD_TIMELESS=1, Asus P8Z77-V LX2 does not change.
Change-Id: Iafe62d952a146bf53a28a1a83b87a3ae31f46720
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The ASSERT() macro depends on the line number, so changing the line it
appears in breaks reproducibility testing using BUILD_TIMELESS=1.
Work around this problem by placing the `pch_pcie_acpi_name` function,
which contains this macro, at the beginning of the file. This allows
refactoring the rest of the code without affecting the ASSERT() macro.
Change-Id: I2e0432ec9ae6c7d033fc7495afb3a71fe7e77729
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Picasso doesn't really make use of the common mrc_cache driver because
of the PSP/ABL requirements for APOB NV data. The APOB NV data
gets consumed by PSP/ABLs before x86 comes out of reset. Hence, we cannot
really add any metadata to this saved data or use multiple slots as
done by the default MRC cache driver
(CACHE_MRC_SETTINGS). Additionally, FSP-M requires access to this APOB
NV data which coreboot needs to pass in from different locations
depending upon boot mode:
1. Non-S3 boot: PSP/ABLs store APOB NV data in DRAM at predetermined
location which is present in BIOS directory table.
2. S3 boot: PSP/ABLs do not store APOB NV data in DRAM.
Thus, coreboot needs to set FSP-M UPD NvsBufferPtr as the DRAM
location in non-S3 boot and the address of RW_MRC_CACHE on SPI flash
in case of S3 resume.
This change enables MRC cache support in Picasso in order to meet the
above requirements.
1. NvsBufferPtr is set based on boot mode.
2. APOB NV data is not stashed to CBMEM. Instead it is written right
away to SPI flash in romstage.
BUG=b:155990176
Change-Id: I8661a4cf2d34502967e936bf22a13f6f1b88e544
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This change moves the check for NvsBufferPtr in S3 resume case to
happen just before FSP-M is called. This allows SoC/mainboard code to
set NvsBufferPtr if it doesn't use the default MRC cache driver.
BUG=b:155990176
Change-Id: Ia272573ad7117a0cb851f0bfe6a4c7989bc64cde
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This change sets FMDFILE for zork family so that coreboot builds pick
up the right flash layout.
BUG=b:155990176
Change-Id: Ia1673622ccd14a2ff7bde555ed33d5b51cf4272a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42106
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CB:41612 added a new set of tools for generating SPDs for TGL and JSL
based mainboards. This change adds relevant documentation to
coreboot-4.13 release notes.
Change-Id: I168adad25df9195dec64e8104f2dbe992eebddc6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42092
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From `Documentation/coding_style.md`:
> This does not apply if only one branch of a conditional statement is a
> single statement; in the latter case use braces in both branches:
Change-Id: I5672949e587a9c0e4efa01521a659e4c224085d0
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Unify the file with the Cannon Lake version
`src/soc/intel/cannonlake/smmrelocate.c`. Now they are identical.
Change-Id: I8cae66038edb3966604c92597986839badd617c5
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42198
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Unify the file with the Cannon Lake version
`src/soc/intel/cannonlake/smmrelocate.c`.
Change-Id: Id4815836e93081b61f4c09b8b3ed81199d3ff409
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Once we support building stages for different architectures,
such CONFIG(ARCH_xx) tests do not evaluate correctly anymore.
Not strictly required for binaryPI boards, but do this for
consistency.
Change-Id: Id0bbbfb6f695c4bb920bc57a1e9362a23884efb3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Once we support building stages for different architectures,
such CONFIG(ARCH_xx) tests do not evaluate correctly anymore.
For x86 we define .id linking explicitly elsewhere.
Change-Id: I43f849465e985068cd0b8a1944213b7c26245b8d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Setting the default values for GPIO community power management, causes
issues in detecting TPM interrupts. So to avoid that GPIO PM has to be
disabled in devicetree. But for S0ix it is needed. This patch implements
a workaround in ASL code to enable GPIO PM on S0ix entry and disable it
on S0ix exit.
This patch adds the following three platform specific methods.
1. MS0X to enable power management features for GPIO communities on
low power mode entry and disables it on exit.
2. MPTS to enable power management features for GPIO communities when
preparing to sleep.
3. MWAK to disable power management features for GPIO communities on
waking up.
BUG=b:153847814
TEST=Verify S0ix is working. GPIO PM configuration is upadated on low
power mode entry and exit.
Change-Id: I7225b78ab2ac5bf17f93230cd85cd21e836d807d
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41502
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SPD sources for Dedede and Volteer are being auto-generated by SPD
tools now, and so we can remove SPD_SOURCES from Makefile.inc for
those templates. That makes Makefile.inc empty for those reference
boards, so remove Makefile.inc from the templates.
BUG=b:158492307
BRANCH=None
TEST=Create new variant of volteer, waddledee, and waddledoo, and
verify that we can still build the coreboot image.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Iba5264384302300cc8d2256a6b43f3353770154a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42204
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds Hot-Plug and power management event handers(_L61 &
_L69) respectively for Thunderbolt in the GPE scope. The _L61 method
invokes sub-method HPEV to support Hot-Plug wake event from Thunderbolt
PCIe root ports. This method intercepts Presence Detect Changed
interrupt and make sure the L0s is disabled on empty slots. The _L69
method checks and clears root port's PME SCI status.
BUG=b:156435065
TEST=Verified multiple hot plug successfully with Lenovo dock.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I022cf4aa3f2ee459b9dc87849494e10755d995c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ACP device sits behind a bridge. Despite the logs indicating
the bridge is likely hooked up, there's some unusual behavior of
writes not sticking. Aside from the speculation of what's causing
the issues the initialization of the device should occur at init()
because of these potential dependencies.
BUG=b:155882600
Change-Id: I8fa83d7d1d4f356c56971d4175a2ae6497a92fb8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42231
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Board devicetrees requests for drivers/pc80/tpm but that
was not included for the build. Note that there is actually
no on-board TPM, just an LPC header connector on these boards.
Change-Id: Ia959ae9072e3fc709b779b1fc778eb82e10c2ee3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The GCC 10 GNAT toolchain uses a new exception handler ABI, so older
GNAT cannot be built with GCC 10. This patch backports the new
exception handler in libgnat to make GNAT able to be built.
The libgnat patch doesn't remove the old exception handler, so it can
still be built with older compilers.
The cross toolchain can now be built with GCC 10.1.0 in Arch Linux
(with the latest IASL in CB:38907 that can be built in Arch), and the
toolchain can build a working coreboot image with libgfxinit for HP
EliteBook 2560p.
The original and patched crossgcc built with Debian 10.4 GCC 8.3.0,
and the patched crossgcc built with Arch GCC 10.1.0 generate identical
coreboot images with `make BUILD_TIMELESS=1`.
Change-Id: I757158056bf4698d3c68715e026c226615bc70a1
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42158
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the comments of
https://review.coreboot.org/c/coreboot/+/41719
, which is about Microcode patch for amd/picasso.
Change the code with the same way.
The changes include:
1. combine the microcode_xxx.c and update_microcode.c
into one source.
2. Redefine the microcode updating function to eliminate
the parameter. Get the revision ID in the black box.
Reduce the depth of function calls.
3. Get the revision ID by bitwise calculation instead of
lookup table.
4. Reduce the confusing type casts.
5. Squash some lines.
We do not change the way it used to be. The code assume
only one microcode is integrated in CBFS. If needed in future,
41719 is the example of integrating multiple binaries.
And, 41719 depends on the definition in this patch.
Change-Id: I8b0da99db0d3189058f75e199f05492c4e6c5881
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This MSR is used for detecting if the micro code is applied
successfully.
Change-Id: I060eb1a31f3358341ac0d5b9105e710c351f2ce8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42212
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Setting preferred_pm_profile under sb/ or soc/ overrides the
default determined from SYSTEM_TYPE_xx (or possibly
SMBIOS_ENCLOSURE_TYPE with followup work). This is not desireable.
With the overrides removed, AMD platforms will switch from
PM_UNSPECIFIED to PM_DESKTOP as their preferred profile.
Boards need to either select a pre-defined SYSTEM_TYPE_xx or provide
board-specific mainboard_fill_fadt() should they need to change this.
As they already select SYSTEM_TYPE_LAPTOP, following boards
will change to PM_MOBILE:
google/kahlee
hp/pavilion_m6_1035dx
lenovo/g505s
Change-Id: I45c4a495a4bf3422adae9e22a6e436adef252e77
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42032
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
The platform_cfg.h files under mainboard/ are a legacy configuration
mechanism used with AGESA family14 boards.
With this change following boards will have FADT preferred_pm_profile
changed from PM_UNSPECIFIED to PM_DESKTOP:
amd/inaqua
amd/south_station
amd/union_station
asrock/e350m1
Change-Id: Ic28761eb238dbbaf3e8f820a29ec64b89f12bf53
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Setting preferred_pm_profile under sb/ overrides the
default determined from SYSTEM_TYPE_xx (or possibly
SMBIOS_ENCLOSURE_TYPE with followup work). This is not desireable.
Boards need to either select a pre-defined SYSTEM_TYPE_xx or provide
board-specific mainboard_fill_fadt() should they need to change this.
As they already select SYSTEM_TYPE_LAPTOP, following boards
will maintain PM_MOBILE:
lenovo/t400
lenovo/x200
roda/rk9
Following will change to PM_DESKTOP:
aopen/dxplplusu
asus/p2b
emulation/qemu-i440fx
emulation/qemu-q35
Change-Id: I2986eb0a8abc94507e9797cc8b64611ae4bd888a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Angel Pons