RW_LEGACY region needs to be 1 MiB to accommodate any alternate
firmware. Hence update the flash ROM layout as below:
* Grab ~512 KiB from each FW_MAIN_A/B regions and allocate them to
RW_LEGACY region so that it grows to 1 MiB.
* Remove VBLOCK_DEV region which is not used.
* Re-size the ELOG region to 4 KiB since that is the maximum size of the
ELOG mirror buffer.
* Resize RW_NVRAM, VBLOCK_A/B regions to 8 KiB since no more than that
size is used in those regions.
* Resize SHARED_DATA region to 4 KiB since no more than that size is
used in that region.
* Based on the resizing, allocate each FW_MAIN_A/B regions with 72 KiB.
BUG=b:167943992, b:167498108
TEST=Build and boot to OS in Drawlat. Ensure that the firmware test
setup and flash map test are successful. Ensure that the event logs are
synced properly between reboots. Ensure that the suspend/resume sequence
is working fine. Ensure that the ChromeOS firmware update completes
successfully for the boot image with updated flash map and the system
boots fine after the update.
Change-Id: I53ada5ac3bd73bea50f4dd4dd352556f1eda7838
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46569
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable caching of memory training data for recovery as well as normal
mode because memory training is taking too long in recovery as well.
This required creating a space in the fmap for RECOVERY_MRC_CACHE.
BUG=b:150502246
BRANCH=None
TEST=Run power_state:rec twice on lazor. Ensure that on first boot,
memory training occurs and on second boot, memory training is
skipped.
Change-Id: Id9059a8edd7527b0fe6cdc0447920d5ecbdf296e
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46651
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mediatek SoC uses part of the L2 cache as SRAM before DRAM is ready.
After DRAM is ready, we should invoke disable_l2c_sram to reconfigure
the L2C SRAM as L2 cache.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: Icaf80bd9da3e082405ba66ef05dd5ea9185784a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46387
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If necessary, SCLEAN needs to run in early romstage, where DRAM is not
working yet. In fact, that the DRAM isn't working is the reason to run
SCLEAN in the first place. Before running GETSEC, CAR needs to be torn
down, as MTRRs have to be reprogrammed to cache the BIOS ACM. Further,
running SCLEAN leaves the system in an undefined state, where the only
sane thing to do is reset the platform. Thus, invoking SCLEAN requires
specific assembly prologue and epilogue sections before and after MTRR
setup, and neither DRAM nor CAR may be relied upon for the MTRR setup.
In order to handle this without duplicating the MTRR setup code, place
it in a macro on a separate file. This needs to be a macro because the
call and return instructions rely on the stack being usable, and it is
not the case for SCLEAN. The MTRR code clobbers many registers, but no
other choice remains when the registers cannot be saved anywhere else.
Tested on Asrock B85M Pro4, BIOS ACM can still be launched.
Change-Id: I2f5e82f57b458ca1637790ddc1ddc14bba68ac49
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46603
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MRC will perform PCI enumeration, and if it detects a VGA device in
a PEG slot, it will disable the IGD and not reserve any memory for it.
Since the memory map is locked by the time MRC finishes, the IGD can not
be enabled afterwards. Changing this behavior requires patching the MRC.
Hiding the PEG devices from MRC allows the IGD to be used even when a
dedicated graphics card is present. However, MRC will not program the
PEG AFE settings as it should, which can cause stability problems at
higher PCIe link speeds. Thus, restrict this workaround to only run when
the HASWELL_HIDE_PEG_FROM_MRC option is enabled. This allows the IGD to
be disabled and the PEG AFE settings to be programmed when a dedicated
graphics card is to be enabled, which results in increased stability.
The most ideal way to fix this problem for good is to implement native
platform init. Native init is necessary to make Nvidia Optimus usable.
Tested on Asrock B85M Pro4, using the PEG slot with a dedicated graphics
card as well as without. Graphics in both situations function properly.
Change-Id: I4d825b1c41d8705bfafe28d8ecb0a511788901f0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45534
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
LockConfig only exists on Intel TXT for Servers. Check whether this is
supported using GETSEC[PARAMETERS]. This eliminates a spurious error for
Client TXT platforms such as Haswell, and is a no-op on TXT for Servers.
Change-Id: Ibb7b0eeba1489dc522d06ab27eafcaa0248b7083
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When Boot Guard is disabled or not available, the IBB might not even
exist. This is the case on traditional (non-ULT) Haswell, for example.
Leave the S3 resume check as-is for now. Skylake and newer may need to
run SCHECK on resume as well, but I lack the hardware to test this on.
Change-Id: I70231f60d4d4c5bc8ee0fcbb0651896256fdd391
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is merely used to test whether the BIOS ACM calling code is working
properly. There's no need to do this on production platforms. Testing on
Haswell showed that running this NOP function breaks S3 resume with TXT.
Add a Kconfig bool to control whether the NOP function is to be invoked.
Change-Id: Ibf461c18a96f1add7867e1320726fadec65b7184
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Heap initialization is self-contained, so place it into a separate
function. Also, do it after the MSEG registers have been written, so
that all register writes are grouped together. This has no impact.
Change-Id: Id108f4cfcd2896d881d9ba267888f7ed5dd984fa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The TXT_BIOSACM_ERRORCODE register is only valid if TXT_SPAD bit 62 is
set, or if CBnT is supported and bit 61 is set. Moreover, this is only
applicable to LT-SX (i.e. platforms supporting Intel TXT for Servers).
This allows TXT to work on client platforms, where these registers are
regular scratchpads and are not necessarily written to by the BIOS ACM.
Change-Id: If047ad79f12de5e0f34227198ee742b9e2b5eb54
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46492
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This config selects the necessary options to enable Intel TXT on the
Asrock B85M Pro4, and allows the code to be build-tested. Note that the
current TXT code will not work, as it was written for Broadwell-DE.
Subsequent commits will adapt the code as necessary to work on Haswell.
Compatible BIOS and SINIT ACMs can be retrieved from a firmware update
for the Supermicro X10SLH. As they are not in the blobs repository, use
the STM binary as a placeholder so as to allow build-testing the code.
Change-Id: Ibf8db5fdfac5b527520023277c6370f6efa71717
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46489
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SMMSTORE version 2 is a complete redesign of the current driver. It is
not backwards-compatible with version 1, and only one version can be
used at a time.
Key features:
* Uses a fixed communication buffer instead of writing to arbitrary
memory addresses provided by untrusted ring0 code.
* Gives the caller full control over the used data format.
* Splits the store into smaller chunks to allow fault tolerant updates.
* Doesn't provide feedback about the actual read/written bytes, just
returns error or success in registers.
* Returns an error if the requested operation would overflow the
communication buffer.
Separate the SMMSTORE into 64 KiB blocks that can individually be
read/written/erased. To be used by payloads that implement a
FaultTolerant Variable store like TianoCore.
The implementation has been tested against EDK2 master.
An example EDK2 implementation can be found here:
eb1127744a
Change-Id: I25e49d184135710f3e6dd1ad3bed95de950fe057
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Create the metaknight variant of the waddledee reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.2.0).
BUG=b:169813211
BRANCH=None
TEST=util/abuild/abuild -p none -t google/dedede -x -a
make sure the build includes GOOGLE_METAKNIGHT
Signed-off-by: Tim Chen <tim-chen@quanta.corp-partner.google.com>
Change-Id: Ia2e473eb1d0a2c819b874e497de0823fca75645a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since MRC_SAVE_HASH_IN_TPM depends on TPM2, we can now remove the tpm
1.2 versions of functions that deal with mrc hash in the tpm as it
will not be used by tpm 1.2 boards. Also move all antirollback
functions that deal with mrc hash in the tpm under CONFIG(TPM2).
BUG=b:150502246
BRANCH=None
TEST=make sure boards are still compiling on coreboot Jenkins
Change-Id: I446dde36ce2233fc40687892da1fb515ce35b82b
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
To enable DVFS, DRAM driver needs to access four different
regulators that SoC can't access directly and need board-specific
implementations.
To support that we need to define the getter and setter APIs for
those regulators.
BUG=b:147789962
BRANCH=none
TEST=verified with DRAM driver
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: I0c2d471a7f8628735af90c5b5a5ab3012831e442
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46405
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 'struct acpi_gpio' arguments passed to acpigen functions are
not modified so they can be made const, which allows drivers to
also use a const pointer.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I59e9c19e7bfdca275230776497767ddc7f6c52db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46257
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an option for unused/reserved bits in a Field definition,
allowing for declarations that do not start at bit 0:
Field (UART, AnyAcc, NoLock, Preserve)
{
, 7, /* RESERVED */
BITF, /* Used bit */
}
These just use byte 0 instead of a name.
Change-Id: I86b54685dbdebacb0834173857c9341ea9fa9a46
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46254
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With TGL FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Due to which cbfsf_decompression_info check failed
when trying to load vbt binary from cbfs because vbt
decompressed_size was greater than vbt_data size. This caused
Graphics init and fw screen issues. Increase the vbt_data to
9KiB to accommodate new vbt binary.
BUG=b:170656067
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: If6ffce028f9e8bc14596bbc0a3f1476843a9334e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This driver is for the root port device and needs to reference the
parent device for its ACPI scope. Similarly for the debug output it
needs to use the parent device, and fall back to the chip name if
config->desc is not provided in the devicetree.
The UID property is removed. This value is not the same as the port
number; according to some docs it should be unique but it is not fully
clear what it should be tied to. Regardless, it is not used by the
Thunderbolt driver in the kernel.
I also renamed some functions/structures to be clear that this is just
an ACPI driver for the PCIe root port and not a driver for the root port
itself. As part of this I removed the PCI based resource operations and
the scan bus function since this device does not have children itself.
Finally I added a detailed comment with an example describing what the
driver is for and what properties it generates.
TEST=boot on volteer and ensure the USB4 root port device and properties
are added to the SSDT as described by the comment in chip.h.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Id6069a0fb7a0fc6836ddff1dbeca5915e444ee18
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46544
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The USB4 host interface (DMA) devices need to use SA_DEVFN_*
instead of SA_DEV_* when determining the ACPI name.
The matching names are removed from the SOC-level ACPI name
handler since they are provided by this driver now.
TEST=boot on volteer and ensure TDM0 device is in the SSDT.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: If778bda82b80593452a590962dbffef6eff6484a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change allows a generic device to be described in the devicetree
under a PCI device, such as a root port.
Previously any device under a PCI device was expected to also be a PCI
device and that does not allow for a virtual/generic device to be
present, for example to provide ACPI properties for a root port.
The changes are:
- Ignore non-PCI devices found under a PCI device when scanning and do
not print an error for each devfn scanned.
- Don't treat non-PCI devices as leftover and remove them, instead
enable them as a static device.
- Don't attempt to configure a static device in the tree that is not a
PCIe device type.
With these changes it is now possible to have a generic device under a
PCI device, for example in a USB4/TBT root port (PCIe hotplug device)
this generic device will add ACPI properties for the PCIe tunnel routed
to the external port:
device pci 07.0 on
chip soc/intel/common/block/pcie
device generic 0 on end
end
end
TEST=boot on volteer with the USB4 root port devices in chipset.cb and
ensure they are enabled properly and there are no errors printed in the
coreboot log, and that the device properties are created in the SSDT.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I56a491808067dc862a7adfd46852f0bd6b41cd95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46542
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The work done by enable_static_devices() and scan_generic_bus()
is common and can be used by other device handlers to enable a
single static device.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ibfde9c4eb794714ebd9800e52b91169ceba15266
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The 0x30 register is eventually controlled by coreboot's
pnp_enable_resources() based on the on/off setting. Other
register settings were grouped with their respective "virtual"
LDN, where possible.
Note, this temporarily breaks LDN 8 settings, as coreboot will
ignore configuration for disabled devices.
Change-Id: I8585dd08eed407ab12258f2accaa63dab294e7d8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The `io` statement will prepare a 16-bit write, hence use `irq` for
miscellaneous 8-bit registers and fix actual `io` settings (i.e. merge
0x61 writes into 0x60). Note, using `irq` is still just a hack as these
are neither I/O nor IRQs, but it's common practice in coreboot.
Change-Id: I2e1c2286be726d126598cc4a97bb15a57faef42f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The mainboard has a PS/2 port, so enable the keyboard controller in the
devicetree.
The PS/2 keyboard now works in SeaBIOS payload, but not in GNU/Linux,
probably as ACPI code still needs to be added.
Change-Id: I7846633bc1a3bdf6bffae628e0542bb8fb684804
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
