Currently, the payload cannot create new CBMEM entries as there is
no such infrastructure available. The Intel CSE driver in the payload
needs below CBMEM entries -
1. CBMEM_ID_CSE_INFO to -
a. Avoid reading ISH firmware version on consecutive boots.
b. Track state of PSR data during CSE downgrade operation.
2. CBMEM_ID_CSE_BP_INFO to avoid reading CSE boot partition
information on consecutive boots.
The idea here is to create required CBMEM entries in coreboot so
that later they can be consumed by the payload.
BUG=b:305898363
TEST=Store CSE version info in CBMEM area in depthcharge on Screebo
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I9561884f7b9f24d9533d2c433b4f6d062c9b1585
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83103
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates the Northbridge ASL to conditionally include a
QWordMemory resource for `SM01` when the `CONFIG_PCR_BASE_ADDRESS`
is above 4 GiB.
If `CONFIG_PCR_BASE_ADDRESS` is below 4 GiB, or falls within the
PCH reserved range, the existing handling of `SM01` remains unchanged
(as a DWordMemory resource).
TEST=Built with CONFIG_PCR_BASE_ADDRESS both above and below 4 GiB,
verified ASL output.
Change-Id: I9547377cdea6cb4334ab59b3bc837059fbb22e3b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83112
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since BL31_MAKEARGS is already handled in arm64/Makefile.mk, remove the
duplication from mt8188/Makefile.mk. In addition, reserve the memory
range for running OP-TEE only if ARM64_BL31_OPTEE_WITH_SMC is enabled.
BUG=b:347851571
TEST=emerge-geralt coreboot
BRANCH=geralt
Change-Id: I88a9a07a685a6c9fe9739b6101ccb8a5ce23fd8b
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add a new Kconfig option ARM64_BL31_OPTEE_WITH_SMC to control whether to
build the OP-TEE dispatcher for BL31. This config also enables the BL31
build option OPTEE_ALLOW_SMC_LOAD, which allows loading the OP-TEE image
after boot via a Secure Monitor Call (SMC). For ChromeOS devices,
CROS_WIDEVINE_SMC is also enabled to allow passing secrets from firmware
to OP-TEE.
BUG=b:347851571
TEST=emerge-geralt coreboot
BRANCH=geralt
Change-Id: I4dcf82d47b537146d71ce3cd2050ec597ed0734f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add AMD SOC Family 17h Renoir CPUIDs per PPR doc #55922
Renoir is similar to Cezanne with only differences in CCX count.
Cezanne has one Zen3 CCX with 8 cores per CCX compared to
the two Zen2 CCX with 4 cores per CCX. Hence, coreboot side
Cezanne SOC code should be mostly compatible with Renoir and
can be leveraged.
Change-Id: I6b43eb782527351c79b835d094a5b61103cd6642
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83099
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit fixes an incorrect variable name in the page table setup
for 1 GiB pages.
The label PDE_table was used when it should have been PDPT, as it
represents a "Page Directory Pointer Table (PDPT)", not a "Page
Directory Table (PDT) or PDE_Table".
This change ensures correct nomenclature and consistency in the code.
PML4 -> PDPT --------> 1GB Physical Page
As per x86-64 specification, 1GB pages bypass the Page Directory Table
(PDT) level of the page table hierarchy, mapping directly from the
Page Directory Pointer (PDPT) Table to the physical page.
Change-Id: I1e1064653a265215054f31f0e4e46bf8200ca471
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83100
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Disable devices in variant.c instead of adding probe statements to
devicetree because storage devices need to be enabled when fw_config is
unprovisioned, and devicetree does not currently support this (it
disables all probed devices when fw_config is unprovisioned).
BUG=b:337169542
TEST=Local build successfully.
Change-Id: I3d71a35e9c0a33b72720b093b5a05eb69d5bb9f8
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83060
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Elan touchpad driver in newer linux kernels (>= 5.15) no longer
explicitly configures the touchpad as a wakeup source for devices
not using device tree. It is now assumed this information should be
extracted from ACPI, therefore we need to update drallion's devicetree
so that the device regains its lost capability.
TEST=update drallion FW and verify touchpad can cause wake up from
suspend
Change-Id: Iff21afda144cc11a013cb72816064df1c9eb21ae
Signed-off-by: Angela Czubak <aczubak@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83070
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Under Windows ACPI, GpioInt and _PRW must be mututally exclusive within
the scope of a device, otherwise a BSOD occurs with an ACPI_BIOS_ERROR.
To enforce this, only use _PRW when EC_ENABLE_SYNC_IRQ_GPIO is not set.
If both EC_ENABLE_WAKE_PIN and EC_ENABLE_SYNC_IRQ_GPIO are set, then
ensure that the GpioInt is flagged as ExclusiveAndWake (vs just
Exclusive) so that the CREC device is still able to wake the device
as needed.
TEST=Build/boot google/{nocturne,frostflow} to Win11 w/ sync_irq_gpio
and wake_pin both enabled.
Change-Id: Ia59cce2ee12bfc8d3ac0173a7a4ec88d7079a958
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82233
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enables ACPI brightness controls to be generated, and display
brightness controls to be functional under Windows.
TEST=build/boot Win11 on google/brya (craaskin), verify display
brightness controls present and functional.
Change-Id: I821b912cf52b5b89c5c9d831a5a15566b1b31639
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Boards using the brya baseboard already generate ACPI brightness
controls via their use of the gfx/generic driver, but need the
default brightness steps in order for display brightness control
to be functional under Windows.
TEST= build/boot Windows 11 on banshee, verify brightness controls
functional.
Change-Id: I03bb7a7309476839c49d2e862a036d9e89800605
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70372
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If both CONFIG_SEPARATE_ROMSTAGE and CONFIG_BOOTBLOCK_CONSOLE are not
set, compilation will fail with errors indicating redefinitions of
various console methods.
When BOOTBLOCK_CONSOLE is not set, the __CONSOLE_ENABLE__ macro in
include/console/console.h evaluates to zero when compiling the
bootblock, resulting in various console methods being defined as stubs
in the header. In a typical build with a separate bootblock and
romstage, this will not cause a conflict as the non-stub definitions
found in the console/*.c files are added conditionally to the bootblock
depending on CONFIG_BOOTBLOCK_CONSOLE.
When SEPARATE_ROMSTAGE is not set, the list of romstage objects gets
added to the bootblock. Since the console sources were unconditionally
added to romstage, the non-stub definitions were able to slip into the
bootblock, causing a redefinition of the stubs.
Avoid this by conditionally adding these sources to romstage depending
on CONFIG_SEPARATE_ROMSTAGE. If SEPARATE_ROMSTAGE is set, the non-stub
definitions are handled in the same way as they were before. If it is
not set, the union of bootblock and romstage objects will only include
the non-stub definitions based on CONFIG_BOOTBLOCK_CONSOLE, which uses
existing console/Makefile.mk rules for the bootblock.
TEST=qemu-i440fx builds successfully with all possible settings of
CONFIG_SEPARATE_ROMSTAGE and CONFIG_BOOTBLOCK_CONSOLE.
Change-Id: I59b3f0c52a4338b1573e0a647bc16cec4943fd7f
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83088
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As of commit ee12634872 (nb/sandybridge,sb/bd82x6x: Configure USB from
southbridge devicetree) and earlier commits, the USB port configuration
should be located in the devicetree instead of the mainboard_usb_ports
array, typically located in the boards early_init.c.
TEST=USB ports still function; and the USBIRx, USBPDO, USBOCM1, and
USBOCM2 RCBA registers in the inteltool dump did not change between
an E6430 build before and after the sb/intel/bd82x6x that moved the
usb config to the devicetree.
Change-Id: Ia5aa03a5894a8ef29e863470925a223f52e0ab70
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83006
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of using a relative path for the submodules, specify the sub-
module URLs as pointing at coreboot.org, using https.
While the relative path works well for coreboot itself, when the repo
is forked and fetched from from anywhere other than review.coreboot.org,
this file either needs to be modified, or all the submodules need to be
checked out as well.
Change-Id: Ie4f95c70a7f194d1073dc561c9f33dcc108060cc
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80552
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The host bridge PCI device ID can be changed by the firmware. There
is no documentation about it, though. There's 'official' IDs, which
appear in spec updates and Windows drivers, and 'mysterious' IDs,
which Intel doesn't want OSes to know about and thus are not listed.
For the sake of completeness, add the PCI device IDs for Clarkdale.
Though coreboot only supports Arrandale, both of them are Ironlake.
It is possible that the Management Engine handles changing the PCI
device ID, which would not happen when using a broken ME firmware.
Change-Id: I85a48fcf0e0e62f42fe147a5d4e2d557b2143e5b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
