Do not discard the const qualifier in `GnbRegisterWriteTNDump()` to fix
the compiler warning below.
CC libagesa/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.o
In file included from src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.c:53:
src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.c: In function 'GnbRegisterWriteTN':
src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.c:836:57: error: passing argument 3 of 'GnbRegisterWriteTNDump' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
836 | GnbRegisterWriteTNDump (RegisterSpaceType, Address, Value);
| ^~~~~
src/vendorcode/amd/agesa/f15tn/Proc/GNB/Common/Gnb.h:68:35: note: in definition of macro 'GNB_DEBUG_CODE'
68 | #define GNB_DEBUG_CODE(Code) Code
| ^~~~
src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.c:86:33: note: expected 'VOID *' {aka 'void *'} but argument is of type 'const VOID *' {aka 'const void *'}
86 | IN VOID *Value
| ~~~~~~~~~~~~~~~~~~~~~^~~~~
CC libagesa/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieComplexDataTN.o
CC libagesa/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieConfigTN.o
CC libagesa/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieEarlyInitTN.o
CC libagesa/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieEnvInitTN.o
CC libagesa/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/PcieLibTN.o
src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.c: At top level:
cc1: note: unrecognized command-line option '-Wno-pragma-pack' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
Found-by: gcc (Debian 11.3.0-3) 11.3.0
Change-Id: I2039cf66030030458bd247a31adc0621b9d033e6
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With Cr50, the GPIO EC_IN_RW_ODL is used to determine whether EC is
trusted. However, with Ti50 where corsola has been switched to, it is
determined by Ti50's boot mode. If the boot mode is TRUSTED_RO, the
VB2_CONTEXT_EC_TRUSTED flag will be set in check_boot_mode(). Therefore
in the Ti50 case get_ec_is_trusted() can just return 0.
The current code of get_ec_is_trusted() only checks the GPIO, which
causes the EC to be always considered "trusted". Therefore, correct the
return value to 0 for TPM_GOOGLE_TI50.
BUG=b:235053870
TEST=emerge-corsola coreboot
TEST=firmware-DevMode passed in kingler (with Ti50)
BRANCH=none
Change-Id: I59b16238bfb487832ef618668c0f9addc1ee7937
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64998
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on latest schematic to update the gpio table.
BUG=b:232419765
TEST=FW_NAME=kuldax emerge-brask coreboot
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Change-Id: If30d872af5d729c0ebd468ebfb099192ec682309
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Remove EEPROM power source interconnect with camera power on/off
and keep it always on.
There appears to be a rare case where the camera EEPROM is not
able to be read from. As a workaround, this patch leaves the
EEPROM power rail on in S0.
BUG=b:229049914
TEST=tested the changes with redrix 5MP(ov5675/hi556) camera.
Change-Id: I9efab9bb65632a73c1c2635729c38a2aa14c69b2
Signed-off-by: Arec Kao <arec.kao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andy Yeh <andy.yeh@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The _DSM subfunction for the Nvidia GN20 supports 1 additional
subfunction, known as GPS, which is required to support GPU Boost. This
implementation is minimal, essentially letting the GPU manage its own
temperature.
BUG=b:214581372
TEST=abuild
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I21331bd811a13212f3825bda44be44d1b5ae7c74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Now that the power sequencing for the GPU is in a better shape, ensure
that the ACPI code that performs power sequencing matches the C code
that does the same.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I797ee99f22a7a6aaacfe54862595674d4ada06ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
During the GPU power down sequence, each power rail should reach below
at least 10% before the next rail is sequenced down; based on scope
shots for a board, conservative delays between each rail are added;
they will likely be more fine-tuned later on.
BUG=b:233959099
TEST=sequence verified by EE
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I28ada3a01b86996e9c7802f8bd18b9acda6bb343
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Currently, the display does not work in steelix. Steelix uses ps8640
eDP bridge IC, which is different from its reference board kingler.
So we should enable ps8640 for steelix.
BUG=b:232195941
TEST=firmware bootsplash is shown on eDP panel of steelix.
Change-Id: I8c6310794c89fc8aa0e69e114c1f7ebd5479c549
Signed-off-by: Zanxi Chen <chenzanxi@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64790
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: wen zhang <zhangwen6@huaqin.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The current 10ms timeout for SPI TPM IRQ is not enough for platforms
using ti50 (such as corsola). Therefore, introduce a new Kconfig option
'GOOGLE_TPM_IRQ_TIMEOUT_MS'.
For platforms using cr50, we need to support legacy pre-ready-IRQ cr50
factory images during the initial boot, so the timeout remains 100ms for
I2C TPM and 10ms for SPI TPM. For all the other platforms using ti50,
the default timeout is increased to 750ms, as suggested by the ti50 team
(apronin@google.com).
BUG=b:232327704
TEST=emerge-corsola coreboot
BRANCH=none
Change-Id: I8dbb919e4a421a99a994913613a33738a49f5956
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add OVTI8856 information for craask
BUG=b:232656913
TEST=Build and boot on craask
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Change-Id: Ice490f31e9ab8fffff6a7a5d24f769efea91188d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Add a note to the top of the util.md document saying not to edit it.
The Documentation/util.md file had been updated to contain additional
information at the bottom. This copies that information into the file
after it's been created.
Change-Id: I4b08439420ceb706df62e3949406585ea34c1514
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch adds a new line to `cbfstool print -v` output that records
the overall CBFS verification health of the image. While this info was
already visible from individual fields before, it's nice to have a
one-stop location to see "this is a good image" without having to
carefully parse a lot of output manually.
Also add a few lines to the Makefile that check whether this field is
valid for the final image (it always should be, but hopefully this check
will allow us to catch regressions like the one fixed by CB:64547 sooner
in the future).
BUG=b:233263447
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1b74b01a55b22294556007aaee835d0fdb9e1c63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The sentence about "to bypass the secure mechanism implemented in
the GRUB runtime config" sounded confusing, so reword it.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I9c6f40d6d11d459fe4be40a624921c2632a89564
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The sentence about using SeaBIOS as secondary payload sounded
confusing, so reword it. While at it, improve and extend on SeaBIOS
features.
Change-Id: Ic06b9f56ab8082f2e6eff5fd8d31525429fd948d
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64958
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add the support LP5 RAM parts for vell:
DRAM Part Name ID to assign Vendor
H58G56AK6BX069 2 (0010) Hynix
BUG=b:227595062
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot
Change-Id: Ibe09285c15b28ceeb6ab0d6c94f90e00584ac07d
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
It might be possible to have this used for more than x86, but that
will be for a later commit.
Change-Id: I4968364a95b5c69c21d3915d302d23e6f1ca182f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch provides an option to reload the microcode patch a.k.a
second microcode patch if SoC selects the required
RELOAD_MICROCODE_PATCH config.
There is a new feature requirement starting with ADL to re-load the
microcode patch as per new Mcheck initialization flow.
BUG=b:233199592
TEST=Build and boot google/taeko to ChromeOS. Able to re-load
microcode patch as below:
[INFO ] microcode: Re-load microcode patch
[INFO ] microcode: updated to revision 0x41b date=2022-03-08
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0a3c29b3c25fccd31280a2a5a8d4fb22a6cf53bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64833
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch creates a helper function named `initialize_microcode()`
to load microcode and ease for all function to peform loading
microcode using this helper function.
BUG=b:233199592
TEST=Build and boot google/taeko to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I7155fc2da7383629930ce147a90ac582782fa5ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
As per Intel Processor EDS, BIOS_DONE bit needs to be set on
all CPUs via MSR.
Also, implement a function to perform any SoC recommended CPU
programming prior to post CPUs init. At present calling
`cpu_soc_bios_done()` for all CPUs from `before_post_cpus_init()`.
Note: It is expected that `before_post_cpus_init()` will be
extended with other CPU programming recommendations in follow up
patches, for example: reload microcode patch etc.
BUG=b:233199592
TEST=Build and boot google/taeko to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8066cd724c9f15d259aeb23f3aa71a2d224d5340
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch implements heci_init() API that perform initialization of
all HECI devices as per MAX_HECI_DEVICES config.
BUG=none
TEST=Able to build and boot google/taeko with this change. No CSE
error observed with `heci_init()` called from romstage.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia25e18a20cc749fc7eee39b0b591d41540fc14c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Board id is same so use cpuid to decide to use ADL or RPL VBT.
BUG=b:229134437
BRANCH=firmware-brya-14505.B
TEST=build adlrvp_rpl_ext_ec
Change-Id: I954c228f82110c3e7c8474e47cabab8220ff19b9
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64672
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Jeremy Compostella <jeremy.compostella@intel.corp-partner.google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Take adlrvp_p as a baseline code and add a new variant of ADL RVP
with Raptor Lake silicon.
BUG=b:229134437
BRANCH=firmware-brya-14505.B
TEST=build adlrvp_rpl_ext_ec
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I880abe0f300118f461523173cc0d50a2fbc99e72
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The headers added are generated as per FSP v3172
In the future, when Alder Lake and Raptor Lake fsp align, Raptor Lake
fsp headers can be deleted and Raptor Lake soc will also use headers
from alderlake/ folder.
BUG=b:229134437
BRANCH=firmware-brya-14505.B
TEST=Boot to OS
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I5aa0611b19bb4f6667a95d2539cc2d17de6dcf07
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The headers added are generated as per FSP v3127_05_8.
In the future, when Alder Lake and Raptor Lake fsp align, Raptor Lake
fsp headers can be deleted and Raptor Lake soc will also use headers
from alderlake/ folder.
BUG=b:229134437
BRANCH=firmware-brya-14505.B
TEST=none
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I9dd14468ec09bfe1a0904686e66d37a7389efdd4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64529
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Use the equivalent cpuid in the microcode header to name the update file
in cbfs. This allows the SOC to directly locate its microcode file when
there are multiple processor revisions.
TEST: Loaded a chausie with sabrina, cezanne, and picasso microcode
files and booted. Verified that only the sabrina microcode file was
successfully loaded
Change-Id: I84a2480cf8274d53ffdab7864135c1bf001241e6
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since many vboot settings are heavily tuned for Chrome OS support,
use these vboot kconfigs for the non Chrome OS use case and tune for EHL
CRB vboot support.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Ie1ffd4973fb18bbca5c5b9c888a4dd0e662b1574
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Praveen HP <praveen.hodagatta.pranesh@intel.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Remove TODO's for dummy DXIO descriptors, update comment
to reflect what they are. These devices are needed for the
platform to function properly. Also remove the TODO for
DDI descriptors as they are functioning correctly.
BUG=b:232952508
TEST=Builds
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: I1535c08cac3f0bcb30061aba2aa593eb22109387
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Felix Singer