This change adds type-c port information for USB type-c ports to cbmem.
BUG=b:149830546
TEST='emerge-volteer coreboot chromeos-bootimage', flash and boot
volteer2 to kernel, log in and check cbmem for type-c info exported to
the payload:
localhost ~ # cbmem -c | grep type-c
added type-c port0 info to cbmem: usb2:9 usb3:1 sbu:0 data:0
added type-c port1 info to cbmem: usb2:4 usb3:2 sbu:1 data:0
Change-Id: Ic56a1ad1b617e3af000664147d21165e6ea3a742
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Move the locally declared typec_orientation enum from chip.h to
coreboot_tables.h.
Change enum typec_orientation name to type_c_orientation for consistency
with contents of coreboot_tables.h.
Rename TYPEC_ORIENTATION_FOLLOW_CC to TYPEC_ORIENTATION_NONE.
BUG=b:149830546
TEST="emerge-volteer coreboot" and make sure it compiles successfully.
Change-Id: I24c9177be72b0c9831791aa7d1f7b1236309c9cd
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
When the entry delay of L0s is less than the entry delay of L1, GL9755
will enter L0s state first. When it exits from L0s state, the time of L1
entry will be reset. Therefore, the conditions for entering L1 state
cannot be met. In order to enter L1 state, L0s needs to be disabled.
BUG=b:195611000
TEST=Verify GL9755 enters L1 by observing CLKREQ# de-asserts.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: If121b5cb534eb32bac8992683c3f0eee8946acec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add mipi panel support for wormdingler
- Add the following panel for wormdingler:
INX P110ZZD-DF0
BOE TV110C9M-LL0
- Use panel_id to distinguish which mipi panel to use.
- Setup panel orientation
BUG=b:195898400,b:198548221
BRANCH=none
TEST=emerge-strongbad coreboot
Change-Id: I8cd28e024ecbfdcd473bc39efb529eb4aca1b5d0
Signed-off-by: Zanxi Chen <chenzanxi@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57642
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
FspMultiPhaseSiInit API was introduced with FSP 2.2 specification
onwards. EnableMultiPhaseSiliconInit is an arch UPD also introduced
as part of FSP 2.2 specification to allow calling FspMultiPhaseSiInit
API.
However, some platforms adhere to the FSP specification but
don't have arch UPD structure, for example : JSL, TGL and Xeon-SP.
Out of these platforms, TGL supports calling of FspMultiPhaseSiInit
API and considered EnableMultiPhaseSiliconInit as a platform-specific
UPD rather than an arch UPD to allow calling into FspMultiPhaseSiInit
API.
It is important to ensure that the UPD setting and the callback for
MultiPhaseInit are kept in sync, else it could result in broken
behavior e.g. a hang is seen in FSP if EnableMultiPhaseSiliconInit
UPD is set to 1 but the FspMultiPhaseSiInit API call is skipped.
This patch provides an option for users to choose to bypass calling
into MultiPhaseSiInit API and ensures the EnableMultiPhaseSiliconInit
UPD is set to its default state as `disable` so that FSP-S don't
consider MultiPhaseSiInit API is a mandatory entry point prior to
calling other FSP API entry points.
List of changes:
1. Add `FSPS_HAS_ARCH_UPD` Kconfig for SoC to select if
`FSPS_ARCH_UPD` structure is part of `FSPS_UPD` structure.
2. Drop `soc_fsp_multi_phase_init_is_enable()` from JSL and Xeon-SP
SoCs, a SoC override to callout that SoC doesn't support calling
MultiPhase Si Init is no longer required.
3. Add `FSPS_USE_MULTI_PHASE_INIT` Kconfig for SoC to specify if
SoC users want to enable `EnableMultiPhaseSiliconInit` arch UPD (using
`fsp_fill_common_arch_params()`) and execute FspMultiPhaseSiInit() API.
4. Presently selects `FSPS_USE_MULTI_PHASE_INIT` from IA TCSS common
code.
5. Add `fsp_is_multi_phase_init_enabled()` that check applicability of
MultiPhase Si Init prior calling FspMultiPhaseSiInit() API to
honor SoC users' decision.
6. Drop `arch_silicon_init_params()` from SoC as FSP driver (FSP 2.2)
would check the applicability of MultiPhase Si Init prior calling
FspMultiPhaseSiInit() API.
Additionally, selects FSPS_HAS_ARCH_UPD for Alder Lake as Alder Lake
FSPS_UPD structure has `FSPS_ARCH_UPD` structure and drops
`arch_silicon_init_params()` from SoC
`platform_fsp_silicon_init_params_cb()`.
Skip EnableMultiPhaseSiliconInit hardcoding for Tiger Lake and uses
the fsp_is_multi_phase_init_enabled() function to override
EnableMultiPhaseSiliconInit UPD prior calling MultiPhaseSiInit FSP API.
TEST=EnableMultiPhaseSiliconInit UPD is getting set or reset based on
SoC user selects FSPS_USE_MULTI_PHASE_INIT Kconfig.
Change-Id: I019fa8364605f5061d56e2d80b20e1a91857c423
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The call to the `get_smbios_data` device operation is followed by
calls to unconditional default functions, which lacks flexibility.
Instead, have devices that implement `get_smbios_data` call these
default functions as needed.
Most `get_smbios_data` implementations are in mainboard code, and are
bound to the root device. The default functions only operate with PCI
devices because of the `dev->path.type != DEVICE_PATH_PCI` checks, so
calling these functions for non-PCI devices is unnecessary. QEMU also
implements `get_smbios_data` but binds it to the domain device, which
isn't PCI either.
Change-Id: Iefbf072b1203d04a98c9d26a30f22cfebe769eb4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The MIPI source video data has a large variation (e.g. 59Hz ~ 61Hz),
anx7625 defines K ratio for matching MIPI input video clock and
DP output video clock. A bigger k value can match a bigger video data
variation. IVO panel has smaller variation than DP CTS spec, so decrease
k value to 0x3b.
BUG=b:194659777
BRANCH=none
TEST=Display is normal on Asurada
Change-Id: If3a09811999babda45e9a9a559dd447920109204
Signed-off-by: Xin Ji <xji@analogixsemi.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57439
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Our MIPI panel initialization framework differentiates between DCS and
GENERIC commands, but the exact interpretation of those terms is left to
the platform drivers. In practice, the MIPI DSI transaction codes for
these are standardized and platforms always need to do the same
operation of combining the command length and transfer type into a
correct DSI protocol code. This patch factors out the various
platform-specific DSI protocol definitions into a single global one and
moves the transaction type calculation into the common panel framework.
The Qualcomm SC7180 implementation which previously only supported DCS
commands is enhanced to (hopefully? untested for now...) also support
GENERIC commands. While we're rewriting that whole section also fix some
other issues about how exactly long and short commands need to be passed
to that hardware which we identified in the meantime.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I09ade7857ca04e89d286cf538b1a5ebb1eeb8c04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Moves MAX_EVENT_SIZE to commonlib/bsd/include, and renames it
ELOG_MAX_EVENT_SIZE to give it an "scoped" name.
The moving is needed because this defined will be used from
util/cbfstool (see next CL in the chain).
BUG=b:172210863
TEST=compiles Ok
Change-Id: I86b06d257dda5b325a8478a044045b2a63fb1a84
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add new thermal control mechanism for pch device under dptf driver.
This provides support of different control knobs for FIVR.
BUG=b:198582766
BRANCH=None
TEST=Build FW and test on brya0 board
Change-Id: I035d2844b9ba6a9532ae006fc1c43e34cb94328a
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Make adding the FSP-T file to CBFS depend on both ADD_FSP_BINARIES and
FSP_CAR Kconfig options being set. The FSP_T_FILE Kconfig option depends
on both, so also check if both are selected in the Makefile where it
tries to add the FSP-T to the CBFS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id347336f2751c6d871f31d89c30a1222037c2d69
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
It doesn't make sense to store the orientation field directly in the
panel information structure, which is supposed to be reuseable between
different boards. The thing that determines orientation is how that
panel is built into the board in question, which only the board itself
can know. The same portrait panel could be rotated left to be used as
landscape in one board and rotated right to be used as landscape in
another. This patch moves the orientation field out of the panel
structure back into the mainboards to reflect this.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2b716aa4dae036515730c12961fdd8a9ac34753
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57324
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This CL indroduces the ELOG_RW_REGION_NAME. This constant replaced the
hardcoded "RW_ELOG" value. This constant will be used also by elogtool
(see CL in the commit chain).
BUG=b:172210863
Change-Id: Ie8d31204e65fd67d52b0f8ced7b8c1ffdcf5b539
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56986
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit moves some drivers/elog/ functionality to commonlib/bsd
since they will be called from util/cbfstool/.
In particular:
* elog_fill_timestamp(), elog_update_checksum(), elog_checksum_event()
were moved to commonlib/bsd/elog
* elog_fill_timestamp() receives the time parameters and updates the
event based on the "time" arguments.
The original elog_*() functions were written by Duncan Laurie
(see CB:1311) and he gave permission to re-license the code to BSD.
BUG=b:172210863
Change-Id: I67d5ad6e7c4d486b3d4ebb25be77998173cee5a9
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Rename soc_validate_fsp_version to soc_validate_fspm_header, since it
can not only be used to check the version info in the FSP-M binary's
header, but also to check every other field in the binary's header. This
is a preparation for a follow-up patch that implements this function to
check the FSP-M binary's size.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ifadcfd1869bea0774dc17b69c5d1e1c241a45de1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to support wake from D3cold, most devices require extra
circuitry and possibly out-of-band communications to the host.
Therefore, assume that most UARTs that do have wake capabilities support
wake from D3hot rather than D3cold.
BUG=b:187228954
TEST=compile
Change-Id: I24d6d0e81d980fc9c910d8f47f557c88990b6400
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to support wake from D3cold, most devices require extra
circuitry and possibly out-of-band communications to the host.
Therefore, assume that most SPI peripherals that do have wake
capabilities support wake from D3hot rather than D3cold.
This also allows coreboot to expose a power resource to perform power
sequencing for a SPI peripheral that is intended to retain power in
S3/S0ix.
If support for a device with d3cold wake support is needed, it could be
added in later as an option.
BUG=b:187228954
TEST=compile
Change-Id: I1d739b49c1a43007eb0199fe39b3b7d7375e6577
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Move elog_internal.h to commonlib/bsd/include/bsd/.
And rename it from elog_internal.h to elog.h.
Since this file will be included from util/ it also converts the "uNN"
types into "uintNN_t" types.
The two defines that are not used by util/ are moved to
drivers/elog/elog.c, the only file that includes them.
Move also the function elog_verify_header() from drivers/elog/, to
commonlib/bsd/elog.c since this function will be called from util/
as well.
The rationale behind moving elog's defines & structs to
commonlib/bsd/include is to make them available to util/ tools and/or
payloads (should it be needed in the future).
The files that are being relicensed to BSD were coded by Duncan Laurie,
and he is Ok with the relicense.
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ia1aefea705ddd417a1d9e978bb18ab6d9a60cad6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This is in preparation for migrating EDK2 to more recent version(s). In
EDK2 repo commit f2cdb268ef appended an additional field to FSP 2.0
header (FspMultiPhaseSiInitEntryOffset). This increases the length of
the header from 72 to 76. Instead of checking for exact length check
reported header length against known minimum length for a given FSP
version.
BUG=b:180186886
TEST=build/boot with both header flavors
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Change-Id: Ie8422447b2cff0a6c536e13014905ffa15c70586
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56190
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set the bus master bit only if the global Kconfig switch
PCI_ALLOW_BUS_MASTER_ANY_DEVICE is enabled. For now the bus master bit
is needed for i210 because of some old OS drivers that do not set it
and won't work properly without it.
Change-Id: I6f727e7f513f4320740fbf49e741cea86edb3247
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56441
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This legacy alt-century byte sits amidst CMOS and conflicts many option
tables. It usually has no meaning to the hardware and needs to be main-
tained manually. Let's disable its usage by default if the CMOS option
table is enabled.
Change-Id: Ifba3d77120c2474393ac5e64faac1baeeb58c893
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The Fast Read Dual Output and Fast Read Dual I/O commands are
practically identical, the only difference being how the read address is
transferred (saving a whooping 2 bytes which is totally irrelevant for
the amounts of data coreboot tends to read). We originally implemented
Fast Read Dual Output since it's the older command and some older
Winbond chips only supported that one... but it seems that some older
Macronix parts for whatever reason chose to only support Fast Read Dual
I/O instead. So in order to make this work for as many parts as
possible, I guess we'll have to implement both. (Also, the Macronix
device ID situation is utter madness with different chips with different
capabilities often having the same ID, so we basically have to make a
best-effort guess to strike a trade-off between fast speeds and best
chance at supporting all chips. If this turns out to be a problem later,
we may have to add Kconfig overrides for this or resort to SFDP parsing,
although that would defeat the whole point of trying to be fast.)
BUG=b:193486682
TEST=Booted CoachZ (with Dual I/O)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia1a20581f251615127f132eadea367b7b66c4709
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
A regular assignment works just as well and also allows type-checking.
It also avoids a common mistake where `sizeof` is applied to a pointer
to obtain the size of the data it points to, without dereferencing it.
Found-by: Coverity CID 1458231
Change-Id: I7ed05322c3c911f3da4145f81e4d9760a275fec2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56265
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
