In the current state of the tree we do not utilise the
mechanism of having per-device overrides for PCI bus
ops.
This change effectively inlines all PCI config accessors
for ramstage as well.
Change-Id: I11c37cadfcbef8fb5657dec6d620e6bccab311a4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For platforms that do not employ VBOOT_STARTS_IN_ROMSTAGE,
vboot verification occurs before CBMEM is brought online.
In order to make vboot data structures available downstream,
copy vb2_working_data from CAR/SRAM into CBMEM when CBMEM
comes online. Create VBOOT_MIGRATE_WORKING_DATA config
option to toggle this functionality.
BUG=b:124141368, b:124192753
TEST=Built and deployed on eve with STARTS_IN_BOOTBLOCK
TEST=Built and deployed on eve with STARTS_IN_ROMSTAGE
TEST=util/lint/checkpatch.pl -g origin/master..HEAD
TEST=util/abuild/abuild -B -e -y -c 50 -p none -x
BRANCH=none
Change-Id: I62c11268a83927bc00ae9bd93b1b31363b38e8cf
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The IS_ENABLED() macro is pretty long and unwieldy for something so
widely used, and often forces line breaks just for checking two Kconfigs
in a row. Let's replace it with something that takes up less space to
make our code more readable. From now on,
if (IS_ENABLED(CONFIG_XXX))
#if IS_ENABLED(CONFIG_XXX)
shall become
if (CONFIG(XXX))
#if CONFIG(XXX)
Change-Id: I2468427b569b974303084574125a9e1d9f6db596
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Until now the TCPA log wasn't working correctly.
* Refactor TCPA log code.
* Add TCPA log dump fucntion.
* Make TCPA log available in bootblock.
* Fix TCPA log formatting.
* Add x86 and Cavium memory for early log.
Change-Id: Ic93133531b84318f48940d34bded48cbae739c44
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29563
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
We want to be able to specify the firmware variant suffix
in the devicetree.cb configuration for particular firmware
builds. This driver allows us to specify the firmware_variant
property in the device tree and have it populate a _DST table
in the SSDT ACPI table for the ISH device, thus making the
suffix available to the kernel (See crrev.com/c/1433482 for kernel
change that uses the value)
BUG=b:122722008
TEST=decompile DDST table and verify that new firmware-variant value
is present. Also verfied that kernel can access this new field using
the shim loader kernel CLs
Change-Id: Id8be986185282521aee574027503eaf8968e1508
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
HDA support did not configure the codecs correclty.
Use Intel common block support to configure the codecs.
To use common Intel HDA support file hda.c file has been
removed and Braswell HDA device ID is added to list of
supported PCI devices in intel/common/block/hda/hda.c.
CONFIG_SOC_INTEL_COMMON_BLOCK and
CONFIG_SOC_INTEL_COMMON_BLOCK_HDA are enabled
to include hda.c in build.
When codec table is available at board level
SOC_INTEL_COMMON_BLOCK_HDA_VERB must be enabled
and a codec table must be supplied.
BUG=N/A
TEST=Facebook FBG-1701 ALC298 configuration
Change-Id: I5c23ec311e5b5a6dfd6f031aa19617407fe8ed63
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/29394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Each smbios entry should be followed with two null bytes. In other
structures it's done by adding `u8 eos[2]` extra bytes at the end, it
was omitted in type38 (IPMI) though. This change fixes this - tables
decodes nicely:
```
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA2 (I/O)
Register Spacing: 32-bit Boundaries
```
Signed-off-by: Lukasz Siudut <lsiudut@fb.com>
Change-Id: I8efea9612448f48e23e7b2226aea2a9f3bc21824
Reviewed-on: https://review.coreboot.org/c/31482
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Under some scenarios the key ladder on the Cr50 can get disabled. If
this state is detected, trigger a reboot of the Cr50 to restore full
TPM functionality.
BUG=b:121463033
BRANCH=none
TEST=Built coreboot on sarien and grunt platforms.
TEST=Ran 'gsctool -a -m disable' and reboot. Verified coreboot sends
VENDOR_CC_IMMEDIATE_RESET command to Cr50 and that the Cr50 resets and
then the platform boots normally.
TEST=Performed Cr50 rollback to 0.0.22 which does not support the
VENDOR_CC_TPM_MODE command, confirmed that platform boots normally and
the coreboot log captures the unsupported command.
Tested-by: Keith Short <keithshort@chromium.org>
Change-Id: I70e012efaf1079d43890e909bc6b5015bef6835a
Signed-off-by: Keith Short <keithshort@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31260
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This macro was unnecessarily complex. Trying to avoid an overflow
for unknown reasons, and instead shifted the result into the sign
bit in C. Using a plain number literal that forces C to use an
adequate integer type seems to be safe. We start with 0xffffffff,
subtract `x` and add 1 again. Turned out to be a common pattern
and can't overflow for any positive 32-bit `x`.
Change-Id: Ibb0c5b88a6e42d3ef2990196a5b99ace90ea8ee8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/31322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
