Fix the warning below when building GA-945GCM-S2L with 64-bit:
src/arch/x86/idt.S:216: Warning: no instruction mnemonic suffix given and no register operands; using default for `iret'
Change-Id: Ibbc106714e25293951a71d84fea0a660f41f9c02
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61336
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
skiboot's Makefile always executes $(CC) to determine whether its clang
or GCC and not setting CROSS for clean target results in this annoying
output (assuming `powerpc64-linux-gcc` isn't available):
make[2]: powerpc64-linux-gcc: No such file or directory
Change-Id: I242b2d7c1bdf1bbd70fd4e4e0605341fe8301ca5
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67053
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
This patch adds ACPI configurations of 8MP YHUX and 2MP CJFKF28-1
as world- and user-facing cameras of Rex.
BUG=b:246413264
TEST=Verified world- and user-facing cameras using Chrome Camera App on
Google/rex device.
Signed-off-by: Daniel Kang <daniel.h.kang@intel.com>
Change-Id: Iaaa16e491a66500606b3a9eb1d87f396641778e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Add support for the following two new memory parts to support a new
SKU that has two memory options that brya0 does not have:
MT53E2G32D4NQ-046 WT:C
MT53E512M32D1NP-046 WT:B
BUG=b:248126749
TEST="emerge-brya coreboot chromeos-bootimage", flash a skolas with
an image-brya0.serial.bin and verify it boots successfully to kernel.
Change-Id: I28667918e5a183339febdc054465effeac8bddbe
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67879
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having to use a runtime configurable option backend like CMOS just to
specify the value of the "fn_ctrl_swap" option is annoying. Introduce
a new Kconfig option to allow specifying the fallback value, which is
only used when the option backend cannot provide a value.
Change-Id: I00bb3cd60c443fc0c8adb82e8e0c436dfc5de24b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67836
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use just one function to get the chipset powerstate and add an argument
to specify the powerstate claimer {RTC,ELOG,WAKE} and adjust the
failure log accordingly.
TEST: compile tested and qemu emulation successfully run
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: I8addc0b05f9e360afc52091c4bb731341d7213cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The current IPU ES entry value is always set to true for ADL-N and
kernel picks the ES version of the main IPU FW even for the production
bootloader but loading is not successful due to the authentication
failure.
Alderlake-N silicon has the same CPU id for all the SKU's and
also the production binaries are backward compatible with ES parts.
This change removes the IPU ES support ACPI entry since the
kernel needs to load the production IPU main firmware on both the
ES/QS parts.
BUG=b:248249032
TEST=Verify the Camera functionality by enabling the IPU secure mode
on ADL-N variants with both ES/QS silicon.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I75b222e6f2b1ccdc5b6c448eb60afff3c1da3a8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
In order that GPP_H13 not use the GPIO override programming from its
baseboard (brya), explicitly program GPP_H13 to a output HIGH instead
of relying on the 20K pullup from the baseboard.
BUG=b:240617195
TEST=SSD still functional
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Iddedebe2d5cfc0123932b14980d1268bcb147703
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The next rev of this board will move the dGPU PEXVDD enable pin from
GPP_E10 to GPP_F12. This patch handles both the old and newer revisions
by using an ACPI Name to hold the GPIO # for PEXVDD enable. It also
cleans up the GPIO handling a little bit between board revs.
BUG=b:242752623
TEST=dGPU is functional and power sequencing tests still pass on board
rev 2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Icc7968777f86ab07561b0a861b7d22ec714d1c34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
On Banshee, when the privacy switch is toggled the camera is
disconnected. Which means that we will never be able to tell the user
that the privacy switch is enabled when the camera is on, making the
virtual control unusable.
Remove the description.
BUG=b:248219472
BRANCH=firmware-brya-14505.B
TEST=none
Change-Id: I1a241bd889c0c1aae039510a0620748b2f7a6806
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The headers added are generated as per FSP v3361.03
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:247855492
BRANCH=firmware-brya-14505.B
TEST=Boot to OS
Signed-off-by: Selma Bensaid <selma.bensaid@intel.com>
Change-Id: I267a0aefca18492bcbcfbf7acbe271887f0a39cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Instead of defining NUM_FIXED_MTRRS in both cpu/x86/mp_init.h and
cpu/x86/mtrr/mtrr.c in two different ways that will evaluate to the same
value, define it once in include/cpu/x86/mtrr.h which is included in
both C files.
TEST=Timeless build for amd/mandolin results in identical firmware image
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71cec61e22f5ce76baef21344c7427be29f193f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The current MRC cache update process is slow (28 ms on nissa), because
cbmem is not cached in romstage. Specifically, the new MRC data returned
by the FSP is stored in the FSP reserved memory in cbmem, so operations
on the new data (computing the checksum, comparing to the old data) are
slow.
Replace the data checksum in the MRC header with a hash, and compare
hashes instead of comparing the full data. This has two benefits:
1. The xxhash function is faster than computing an IP checksum (4 ms vs
14 ms on uncached data on nissa).
2. There's no need to memcmp() the full MRC data, which takes 14 ms on
nissa.
Before:
550:starting to load ChromeOS VPD 867,930 (4,664)
3:after RAM initialization 896,020 (28,090)
4:end of romstage 906,274 (10,254)
After:
550:starting to load ChromeOS VPD 864,820 (4,649)
3:after RAM initialization 869,652 (4,831)
4:end of romstage 879,909 (10,257)
BUG=b:242667207
TEST=Check that MRC caching still works as expected on nissa. Corrupt
the MRC cache and check that memory is retrained.
Change-Id: I1b7848d1d05e555b61e0f1cb605550dfe3449c6d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67670
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Recently published Intel CedarIslandFSP binary contains PE images in
FSP-M and FSP-S. This causes coreboot boot hang on DeltaLake servers.
PI spec PI_Spec_1_7_final_Jan_2019 on uefi.org talks about FV files
requiring to support SECTION_PE32 sections and FSP specification
states that FSP images are created in alignment with PI specification.
FSP images are relocated at build time and run time using the func
fsp_component_relocate. That code only supported TE image relocation
so far.
The change required to add support for pe_relocate in fsp-relocate.c
I had to move a few functions to top of file as they need to be used
by pe_relocate but were placed below the te_relocate function. I chose
to place pe_relocate function next to te_relocate.
The code supports PE32 format, not PE32+, at this time.
Links for PE and FSP specs are provided below for reference.
Link= https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf
Link= https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
TESTED=
This code is tested with FSP version 33A for DeltaLake boot which has
FSP-M and FSP-S as PE32 sections. This FSP version does not boot on
DeltaLake without this change.
Change-Id: I01e2c123d74f735a647b994aa66419c9796f193e
Signed-off-by: Eddie Sharma <aeddiesharma@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nathaniel L Desimone <nathaniel.l.desimone@intel.com>
Instead of redefining the register address in smihandler.c, use the
existing definitions from include/cpu/x86/lapic_def.h.
TEST=Timeless build for lenovo/g505s which includes this file in the
build results in identical firmware image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id22f9b5ce53c7bced6bbcc3f5026d4c793b34f78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67776
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
'Mendocino' was an embargoed name and could previously not be used.
Update references for consistency with the correct naming convention.
BUG=b:245727030
TEST=builds and boots to kernel
Cq-Depend: chrome-internal:4878294
Cq-Depend: chromium:3763392
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: Ic0248a872dfc92486658aa9bd92bed755dbf59d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67750
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add new PSP svc call to pass psp firmware hash table to the PSP.
psp_verstage will verify hash table and then pass them to the PSP.
The PSP will check if signed firmware contents match these hashes.
This will prevent anyone replacing signed firmware in the RW region.
BUG=b:203597980
TEST=Build and boot to OS in Skyrim.
Change-Id: I512d359967eae925098973e90250111d6f59dd39
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67259
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the devicetree driver example into a separate page under the
drivers category, and link to it from both the devicetree page and
the drivers index page. This makes more sense from a grouping
perspective and makes the info easier to find.
Change-Id: Ic3ca80b93a0020737c7ccb5313a0877172022e1a
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add SOC_INTEL_COMMON_PCH_CLIENT which is specific to Apollo
Lake. This is used to select the options that Apollo Lake
requires, without the ones specific to a PCH as Apollo Lake
doesn't have a PCH.
This change also enables SOC_INTEL_COMMON_PCH_LOCKDOWN for
Apollo Lake.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I084a05f904a19f3b7e9a071636659670aa45bf3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>