The headers added are generated as per FSP v2081_02.
Previous FSP version was v2037.
Changes Include:
- Adjust UPD Offset in FspmUpd.h and FspsUpd.h
- Add DevIntConfigPtr and NumOfDevIntConfig UPDs in Fsps.h
BUG=b:180758116
BRANCH=None
TEST=Build and boot ADLRVP
Cq-Depend: chrome-internal:3669105
Change-Id: Ib99748a428709ffad27d47f600e00bd91b70d8f3
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51248
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mediatek has released the reference implementation for DRAM
initialization in vendorcode/mediatek/mt8192/dramc (CB:50294)
so we want to use it to replace the derived calibration code
in soc folder.
Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: I2b2f41d774c6b85f106867144fb0b29a4a1bdfcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This is the DRAM initialization code from the reference
implementation released by Mediatek for MT8192.
The DRAM calibration code can be taken as a standalone
library, used by different boot loaders for initializing
DRAM and following a different coding style (coreboot was
using Linux Kernel coding style), so we have to put it
in vendor code folder.
Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: I3853204578069c6abf52689ea6f5d88841414bd4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
CrashLog is a diagnostic feature for Intel TGL based platforms.
It is meant to capture the state of the platform before a crash.
The state of relevant registers is preserved across a warm reset.
BUG=None
TEST=CrashLog data generated, extracted, processed, decoded sucessfully on delbin.
Signed-off-by: Francois Toguo <francois.toguo.fotso@intel.com>
Change-Id: Ie3763cebcd1178709cc8597710bf062a30901809
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add support for MP services2 PPIs, which is slight modification
over MP services 1 PPIs. A new API StartupAllCPUs have been added
to allow running a task on BSP and all APs. Also the EFI_PEI_SERVICES
parameter has been removed from all MP PPI APIs.
This implementation also selects the respective MP services PPI version
supported for SoCs
BUG=b:169196864
Change-Id: Id74baf17fb90147d229c78be90268fdc3ec1badc
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
add UPD for RV2 USB3 phy setting adjust.
Note: it only for RV2 silicon and not available for RV/PCO.
Usb 3.1 PHY Parameters:
1. RX_EQ_DELTA_IQ_OVRD_VAL
-Override value for rx_eq_delta_iq. Range 0-0xF
2. RX_EQ_DELTA_IQ_OVRD_EN
-Enable override value for rx_eq_delta_iq. Range 0-0x1
3. Override value for rx_vref_ctrl. Range 0 - 0x1F
4. Enable override value for rx_vref_ctrl. Range 0 - 0x1
5. Override value for tx_vboost_lvl: 0 - 0x7.
6. Enable override value for tx_vboost_lvl. Range: 0 - 0x1
7. Override value for rx_vref_ctrl. Range 0 - 0x1F
8. Enable override value for rx_vref_ctrl. Range 0 - 0x1
9. Override value for tx_vboost_lvl: 0 - 0x7.
10. Enable override value for tx_vboost_lvl. Range: 0 - 0x1
BUG=b:175192931
TEST=Build/verify the valule will been apply on dirinboz
Change-Id: I1d5f69e840952cc5171af1ce8597628d1bede5cb
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50240
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new Kconfig symbols to mark FSP binary as x86_32.
Fix the FSP headers and replace void pointers by fixed sized integers
depending on the used mode to compile the FSP.
This issue has been reported here:
https://github.com/intel/FSP/issues/59
This is necessary to run on x86_64, as pointers have different size.
Add preprocessor error to warn that x86_64 FSP isn't supported by the
current code.
Tested on Intel Skylake. FSP-M no longer returns the error "Invalid
Parameter".
Change-Id: I6015005c4ee3fc2f361985cf8cff896bcefd04fb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
According to Tigerlake TDP specifications (doc #575683, table 4-2),
TGL supports different TDP levels depends on CPU segement/package,
IA Cores and graphics configuration. For example, UP3 4-Core GT2
suppots base TDP=28W, Configurable TDP-Down_1=15W and Configurable
TDP-Down_2=12W. This configurable value can be used to select
suitable TDP level
Change-Id: I4242575807caac172b6cbe667839bf6c9241f3c5
Signed-off-by: Derek Huang <derek.huang@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
For builds with MAINBOARD_HAS_CHROMEOS=y but CHROMEOS=n, there
is reduced dsdt.aml size and reduced GNVS allocation from cbmem.
More importantly, it's less error-prone when the OperationRegion
size is not hard-coded inside the .asl files.
Change-Id: I54b0d63a41561f9a5d9ebde77967e6d21ee014cd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49477
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a trimmed-down version of the Cezanne FSP integration code, so
for example the UPD definitions are empty, which will be addressed
later. Since coreboot just leaves the UPD values at their default, this
is not a problem during the initial platform bring-up.
Change-Id: Ie0fc30120c2455aa2160708251e9d2f229984305
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
CSE Firmware Sync is being performed in romstage currently. But the CSE
board reset is not included as part of romstage. This causes the CSE
firmware sync to use global reset instead of EC assisted AP reset with
the old Cr50 Firmware version. Include the board specific CSE reset in
romstage.
BUG=b:171731175,b:177795247
BRANCH=dedede,volteer,puff
TEST=Ensured that the Drawlat boots to OS with both old(0.0.22) and
new(0.6.7) Cr50 FW versions.
Change-Id: I5e362271ffb68ffd5884279acd1ab0a462195a8a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49850
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The layout of GNVS has expectation for a fixed size
array for chromeos_acpi_t. This allows us to reduce
the exposure of <chromeos/gnvs.h>.
If chromeos_acpi_t was the last entry in struct global_nvs
padding at the end is also removed.
If device_nvs_t exists, place a properly sized reserve for
chromeos_acpi_t in the middle.
Allocation from cbmem is adjusted such that it matches exactly
the OperationRegion size defined inside the ASL.
Change-Id: If234075e11335ce958ce136dd3fe162f7e5afdf7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
On Coffee Lake systems prog_locate_hook() is called with PROG_POSTCAR.
For this reason the early check is not executed.
Add check for prog->type == PROG_POSTCAR, but execute
verified_boot_early_check() once.
BUG = N/A
TEST = Build and boot on Facebook FBG1701 and Intel CoffeeLake system
Change-Id: Ia3bd36064bcc8176302834c1e46a225937d61c20
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48852
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the support for the Intel Cannon Lake SoC for various reasons:
* Most people can't use coreboot on Cannon Lake, since the required FSP
binaries aren't publicly available. Given that FSP binaries for several
newer platforms have been released, it's very unlikely that Cannon Lake
FSP will ever be released.
* It seems there is no interest in this, since the reference mainboard
is the only available mainboard in tree.
Also, remove the related reference mainboard intel/cannonlake_rvp and
its FSP headers in intel/fsp2_0/cannonlake.
Change-Id: I8f698e16099acb45444b2bc675642d161ff8c237
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48775
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With Intel CPX-SP FSP ww01 release, CidBitMap field is added to
DimmDevice struct in hob_memmap.h.
The copyright statements were updated to accomodate year 2021.
gpio_fsp.h is not needed any more as coreboot takes over GPIO
configuration.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I3242c8b50401757a28de8a9e9c71fb95bc0515dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
IASL version 20180927 and greater, detects Unnecessary/redundant uses of
the Offset() operator within a Field Unit list.
It then sends a remark "^ Unnecessary/redundant use of Offset"
example:
OperationRegion (OPR1, SystemMemory, 0x100, 0x100)
Field (OPR1)
{
Offset (0), // Never needed
FLD1, 32,
Offset (4), // Redundant, offset is already 4 (bytes)
FLD2, 8,
Offset (64), // OK use of Offset.
FLD3, 16,
}
We will have those remarks:
dsdt.asl 14: Offset (0),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
dsdt.asl 16: Offset (4),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
Change-Id: I260a79ef77025b4befbccc21f5999f89d90c1154
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43283
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ability to set up a custom memory profile is useful if you don't
like the XMP memory profiles (if they exist) of your RAM sticks, or
want to try some overclocking. Read SPD data will be overriden by your
custom values. Tested on Crucial BLT8G3D1869DT1TX0 (1866MHz 9-9-9-27).
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I1238ff00ef0efd11ea807794827476c30ac98065
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Add XMP memory profiles support that has been tested on f15tn (A88XM-E)
and f16kb (AM1I-A) with two Crucial BLT8G3D1869DT1TX0, XMP 1 profile.
Added using the datasheets from https://github.com/mikebdp2/ddr3spd :
JEDEC_DDR3_SPD_4_01_02_11R24.pdf and Intel_XMP_Spec_Rev1.1.pdf
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I584416e3376afdf377a11783e55c5e9ff41e6b0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40488
Reviewed-by: Lance Zhao
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
