RAMOOPS memory region was being overwritten by coreboot bmp_load_logo()
function. The CBMEM_ID_FSP_LOGO region created during bmp_load_logo()
was overlapping with RAMOOPS space created earlier. This resulted in
memory corruption of RAMOOPS buffer.
To prevent this, the RAMOOPS region allocation is moved to
BS_DEV_INIT_CHIPS phase from earlier BS_WRITE_TABLES phase of boot.
BUG=b:332910298
TEST=build and boot coreboot image on google/rex HW. Check RAMOOPS
CBMEM region creation using cbmem -l command
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ibae06362cd80eacb16f6cf0eed8c9aa1fbfb2535
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82042
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This prepares the code for enabling both CONFIG_TPM1 and CONFIG_TPM2
during compilation, in which case actual TPM family in use can be
determined at runtime.
In some places both compile-time and runtime checks are necessary.
Yet in places like probe functions runtime state checks don't make sense
as runtime state is defined by results of probing.
Change-Id: Id9cc25aad8d1d7bfad12b7a92059b1b3641bbfa9
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69161
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No functional changes. Refactor code such that there won't be any
compiler or linker errors if TSS 1.2 and TSS 2.0 were both compiled
in.
One might want to support both TPM families for example if TPM is
pluggable, while currently one has to reflash firmware along with
switching TPM device.
Change-Id: Ia0ea5a917c46ada9fc3274f17240e12bca98db6a
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
* Introduces logic to display context-specific boot splash logos.
* Logo selection considers:
* Chromebook-Plus hardware compliance (using factory_config).
* VPD-based product segmentation (soft-branded vs. regular
chromebook).
* Default Chromebook logo as fallback for regular Chromebook.
This patch fixes the problem where existing logic was unable to pick
correct ChromeOS boot splash logo based on the product segmentation.
Relation between product segment and boot splash screen:
1. Chromebook-Plus Hard-branded device: Renders "cb_plus_logo.bmp" logo
2. Chromebook-Plus Soft-branded device: Renders "cb_plus_logo.bmp" logo
3. Regular Chromebook device: Renders "cb_logo.bmp"
BUG=b:324107408
TEST=Verified logo selection based on compliance and product
requirements.
Change-Id: I9bb1e868764738333977bd8c990bea4253c9d37b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I80559b7c86a8fd2583cb0335279f676e0aa0209e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80067
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
This commit adds support for showing different logos on the ChromeOS
firmware splash screen based on the device model (between
Chromebook-Plus and regular ChromeOS devices like Chromebook and
Chromebox). This allows OEMs to customize the branding on their
devices.
This patch also introduces three new Kconfigs:
- CHROMEOS_FW_SPLASH_SCREEN
- CHROMEOS_LOGO_PATH
- CHROMEBOOK_PLUS_LOGO_PATH
which allow users to enable the fw splash screen feature in the
vendorcode. Previously, we were using the BMP_LOGO Kconfig in
drivers/intel/fsp2_0, but we didn't want the top level Kconfigs to be
located inside the architecture specific files.
BUG=b:317880956
BRANCH=None
TEST=emerge-rex coreboot chromeos-bootimage
verify that FW splash screen appears
Change-Id: I56613d1e7e81e25b31ad034edae0f716c94c4960
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79775
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch ensures `chromeos_get_factory_config()` returns an
unsigned integer value because factory config represents
bit-fields to determine the Chromebook Plus branding.
Additionally, introduced safety measures to catch future
"factory_config" bit-field exhaustion.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: I3021b8646de4750b4c8e2a2981f42500894fa2d0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79769
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch implements an API which relies on the
chromeos_get_factory_config() function to retrieve the factory
config value.
This information is useful to determine whether a ChromeOS device
is branded as a Chromebook Plus based on specific bit flags:
- Bit 4 (0x10): Indicates whether the device chassis has the
"chromebook-plus" branding.
- Bits 3-0 (0x1): Must be 0x1 to signify compliance with
Chromebook Plus hardware specifications.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: Iebaed1c60e34af4cc36316f1f87a89df778b0857
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This code leverages the TPM vendor-specific function
tlcl_cr50_get_factory_config() to fetch the device's factory
configuration.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: I34f47c9a94972534cda656ef624ef12ed5ddeb06
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Convert TPM functions to return TPM error codes(referred to as
tpm_result_t) values to match the TCG standard.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adopt TCG standard naming and definitions for TPM Return codes.
BUG=b:296439237
TEST=Build and boot to OS on skyrim
BRANCH=None
Change-Id: I60755723262ec205a4c134948b0250aac4974d35
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77665
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make naming convention consistent across all functions return values.
BUG=b:296439237
TEST=Boot to OS on Skyrim
BRANCH=None
Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
When CSE jumps between RO and RW, it triggers global reset so the
AP goes down to S5 and back to S0. For Chromebox, when AP goes
down to S5 EC set AP_IDLE flag. This cause an issue to warm reset
the Chromebox device when it is in recovery mode and powered by
USB-C adapter. This patch allows AP to direct EC to clear AP_IDLE
flag before trigger reset.
BUG=b:296173534
BRANCH=firmware-dedede-136-6.B
TEST=Chromebox DUT which is powered by USB-C adapter boots up
after warm reset in recovery mode
Change-Id: Ib0002c1b8313c6f25d2b8767c60639aed8a4f904
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77632
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Previously the clear_ec_ap_idle() is implemented in
cr50_enable_update.c and be called in the file. Move it to
common code so that it can be called in cse_board_reset.c
TEST=emerge-brask coreboot
Change-Id: I2dbe41b01e70f7259f75d967e6df694a3e0fac23
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77631
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I81ae8acb0365af102e513b3d7cfa1a824636eb06
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76812
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
DSM (Dynamic Speaker Management) uses calibration parameters stored in
a VPD (Vital Product Data) FMAP region to configure the audio output
via an ACPI _DSD table. This has no dependency on a ChromeOS, and can
be used by Linux/Windows drivers if appropriately configured.
Remove the dependency of DSM_CALIB (and the calibration file) on
CHROMEOS and replace it with VPD, so that non-CHROMEOS builds
can utilize this feature as well. Move files from underneath
vc/google/chromeos to underscore the point.
TEST=build/boot google/nightfury, dump ACPI, verify DSM calibraton
parameters present in _DSD table.
Change-Id: I643b3581bcc662befc9e30736dae806f94b055af
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
When a mainboard selects ACPI_SOC_NVS and CHROMEOS, CHROMEOS_NVS will be
selected. This causes vc/google/chromeec/acpi/chromeos.asl to be
included in the DSDT and chromeos_acpi_gpio_generate to be called when
generating the coreboot SSDT. When a mainboard also uses
DECLARE_NO_CROS_GPIOS(), this will cause variant_cros_gpio.count to be 0
and variant_cros_gpio.gpios to be NULL. chromeos_acpi_gpio_generate only
checked if the GPIO table was non-NULL, which caused the function to
exit early and not generate the OIPG package which causes the kernel to
complain about referencing the non-existing OIPG package. To avoid this,
only exit in the GPIO table pointer being NULL case if the number of
GPIOs is non-0.
TEST=Error about missing OIPG ACPI object in dmesg disappears on birman.
Before:
[ 0.241339] chromeos_acpi: registering CHSW 0
[ 0.241468] ACPI BIOS Error (bug): Could not resolve symbol [\CRHW.GPIO.OIPG], AE_NOT_FOUND (20220331/psargs-330)
[ 0.241703] ACPI Error: Aborting method \CRHW.GPIO due to previous error (AE_NOT_FOUND) (20220331/psparse-531)
[ 0.241933] chromeos_acpi: failed to retrieve GPIO (5)
[ 0.242011] chromeos_acpi: registering VBNV 0
[ 0.242113] chromeos_acpi: registering VBNV 1
[ 0.242284] chromeos_acpi: truncating buffer from 3072 to 1336
[ 0.242462] chromeos_acpi: installed
With the patch applied:
[ 0.242580] chromeos_acpi: registering CHSW 0
[ 0.242714] chromeos_acpi: registering VBNV 0
[ 0.242817] chromeos_acpi: registering VBNV 1
[ 0.242990] chromeos_acpi: truncating buffer from 3072 to 1336
[ 0.243249] chromeos_acpi: installed
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ie340003afb718b1454c2da4a479882b71714c3c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74375
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When AP boots up after Cr50 firmware update and reboot, AP finds
that Cr50 reset is required for Cr50 to pick the new firmware so
it trigger Cr50 reset and power off the system, AP expects system
will power on automatically after Cr50 reset. However this is not
the case for Chromebox, Chromebox EC set AP_IDLE flag when system
is shutting down, when AP_IDLE flag is set in EC, the system stays
at S5/G3 and wait for power button presssend. It cause an issue in
factory that the operator needs to press power button to power on
the DUT after Cr50 firmware update.
This patch sends EC command to direct EC to clear AP_IDLE flag
after AP shutdown so AP can boot up when Cr50 reset.
BUG=b:261119366
BRANCH=firmware-brya-14505.B
TEST=DUT boots up after Cr50 firmware update in factory test flow
Change-Id: If97ffbe65f4783f17f4747a87b0bf89a2b021a3b
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70773
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CR50 code clears the post code value. Add this as a #define.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If3b73a3159ac8ac9ab08c6ff705b0ca289ab453c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Use fw_config field to return sar filename instead of fw_config probe.
Return filename unconditionly because the sar_id must be valid in
CBI. If invalid sar_id, the file won't exist in CBFS by design.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I7b75c5d4fd3c459ad7232bb16c6218a6218f1f77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch calls into vboot API (vb2api_get_fw_boot_info) to retrieve
FW slot boot information like (tries count, current boot slot, previous
boot slot, previous boot status and boot mode).
Upon retrieval of the vboot information, elog callback from ramstage
records the info into the eventlog.
Additionally, this patch refactors the existing event logging mechanism
to add newer APIs to record vboot firmware boot related information.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS and run below command to
check the cbmem log:
Scenario 1:
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot:
0x0 / 0x0
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Developer boot`
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Success`.
....
Scenario 2:
localhost ~ # crossystem recovery_request=1
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Manual recovery boot`
VB2:vb2api_fill_boot_config() recovery_reason=0x13 / 0x00
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Unknown`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6882cd1c4dbe5e24f6460388cd1af4e4a05fc4da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65561
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Branding changes to unify and update Chrome OS to ChromeOS (removing the
space).
This CL also includes changing Chromium OS to ChromiumOS as well.
BUG=None
TEST=N/A
Change-Id: I39af9f1069b62747dbfeebdd62d85fabfa655dcd
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65479
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
hardwaremain.c is the common ramstage entry to all platforms so move
out ACPI code generation (x86 specific) to boot state hooks.
Another reason to do this is the following:
On some platforms that start in dram it makes little sense to have
separate stages. To reduce the complexity we want to call the ramstage
main function instead of loading a full stage. To make this scheme
more maintainable it makes sense to move out as much functionality
from the 'main' function as possible.
Change-Id: I613b927b9a193fc076ffb1b2a40c617965ce2645
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63414
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Break TPM related Kconfig into the following dimensions:
TPM transport support:
config CRB_TPM
config I2C_TPM
config SPI_TPM
config MEMORY_MAPPED_TPM (new)
TPM brand, not defining any of these is valid, and result in "generic" support:
config TPM_ATMEL (new)
config TPM_GOOGLE (new)
config TPM_GOOGLE_CR50 (new, implies TPM_GOOGLE)
config TPM_GOOGLE_TI50 (new to be used later, implies TPM_GOOGLE)
What protocol the TPM chip supports:
config MAINBOARD_HAS_TPM1
config MAINBOARD_HAS_TPM2
What the user chooses to compile (restricted by the above):
config NO_TPM
config TPM1
config TPM2
The following Kconfigs will be replaced as indicated:
config TPM_CR50 -> TPM_GOOGLE
config MAINBOARD_HAS_CRB_TPM -> CRB_TPM
config MAINBOARD_HAS_I2C_TPM_ATMEL -> I2C_TPM && TPM_ATMEL
config MAINBOARD_HAS_I2C_TPM_CR50 -> I2C_TPM && TPM_GOOGLE
config MAINBOARD_HAS_I2C_TPM_GENERIC -> I2C_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_LPC_TPM -> MEMORY_MAPPED_TPM
config MAINBOARD_HAS_SPI_TPM -> SPI_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_SPI_TPM_CR50 -> SPI_TPM && TPM_GOOGLE
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Change-Id: I4656b2b90363b8dfd008dc281ad591862fe2cc9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The symbol watchdog_tombstone is not really about ChromeOS
but ELOG instead. This prepares for furher move of the
watchdog_tombstone implementation.
Change-Id: I8446fa1a395b2d17912a23b87b83277c80828874
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The only purpose of mainboard_chromeos_acpi_generate()
was to pass cros_gpio array for ACPI \\OIPG package
generation.
Promote variant_cros_gpio() from baseboards to ChromeOS
declaration.
Change-Id: I5c2ac1dcea35f1f00dea401528404bc6ca0ab53c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This field was never meant to be filled out by coreboot, because it
can't know what the right value for this will be by the time the OS
is running, so anything coreboot could fill in here is premature.
This field is only read by the chromeos-specific `crossystem` utility,
not by kernel code, so if one does not run through depthcharge there'll
be many more broken assumptions in CNVS anyway.
Change-Id: Ia56b3a3fc82f1b8247a6ee512fe960e9d3d87585
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Motivation is to have mainboard_chromeos_acpi_generate()
do nothing else than fill ACPI \OIPG package.
Change-Id: I3cb95268424dc27f8c1e26b3d34eff1a7b8eab7f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For platforms without EC_GOOGLE_CHROMEEC S3 resume path
always reported ACTIVE_ECFW_RO because acpi_fill_cnvs()
and mainboard_chromeos_acpi_generate() were not called.
Change-Id: Iea71a51aba7ab1b6966389c17a1e06ccc96ae0e9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Add an elog type 0xb6 for Chrome OS diagnostics related events and
log the message while booting the diagnostic tool:
__func__: Logged diagnostic boot
BRANCH=none
BUG=b:185551931, b:177196147
TEST=emerge-volteer coreboot vboot_reference
Change-Id: Icb675fc431d4c45e4f432b2d12cac6dcfb2d5e3a
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Remove chromeos_dsdt_generator() calls under mainboard, it
is possible to make the single call to fill \CNVS and
\OIPG without leveraging device operations.
Change-Id: Id79af96bb6c038d273ac9c4afc723437fc1f3fc9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add support for DSM methods as per the connectivity document
559910_Intel_Connectivity_Platforms_BIOS_Guidelines_Rev6_4.pdf
BUG=b:191720858
TEST=Check the generated SSDT tables for DSM methods
Change-Id: Ie154edf188531fe6c260274edaa694cf3b3605d3
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add support for the WTAS ACPI BIOS configuration table as per the
connectivity document:
559910_Intel_Connectivity_Platforms_BIOS_Guidelines_Rev6_4.pdf
BUG=b:193665559
TEST=Generated SAR file with the WTAS related configuration values and
verified that the SSDT has the WTAS ACPI table.
Change-Id: I42cf3cba7974e6db0e05de30846ef103a15fd584
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57061
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add support for the PPAG ACPI BIOS configuration table as per the
connectivity document:
559910_Intel_Connectivity_Platforms_BIOS_Guidelines_Rev6_4.pdf
BUG=b:193665559
TEST=Generated SAR file with the PPAG related configuration values and
verified that the SSDT has the PPAG ACPI table.
Change-Id: Ie8d25113feeeb4a4242cfd7d72a5091d2d5fb389
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Existing SAR infrastructure supports only revision 0 of the SAR tables.
This patch modifies it to extend support for intel wifi 6 and wifi 6e
configurations as per the connectivity document:
559910_Intel_Connectivity_Platforms_BIOS_Guidelines_Rev6_4.pdf
The SAR table and WGDS configuration block sizes were static in the
legacy SAR file format. Following is the format of the new binary file.
+------------------------------------------------------------+
| Field | Size | Description |
+------------------------------------------------------------+
| Marker | 4 bytes | "$SAR" |
+------------------------------------------------------------+
| Version | 1 byte | Current version = 1 |
+------------------------------------------------------------+
| SAR table | 2 bytes | Offset of SAR table from start of |
| offset | | the header |
+------------------------------------------------------------+
| WGDS | 2 bytes | Offset of WGDS table from start of |
| offset | | the header |
+------------------------------------------------------------+
| Data | n bytes | Data for the different tables |
+------------------------------------------------------------+
This change supports both the legacy and the new format of SAR file
BUG=b:193665559
TEST=Checked the SSDT entries for WRDS, EWRD and WGDS with different
binaries generated by setting different versions in the config.star
Change-Id: I08c3f321938eba04e8bcff4d87cb215422715bb2
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
After ChromeOS NVS was moved to a separate allocation and the use
of multiple OperationRegions, maintaining the fixed offsets is not
necessary.
Use actual structure size for OperationRegions, but align the
allocations to 8 bytes or sizeof(uint64_t).
Change-Id: I9c73b7c44d234af42c571b23187b924ca2c3894a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>