This patch drops explicit usage of the address-of operator ('&') while
passing the function pointer (argument 0) to the
`mp_run_on_all_cpus` API.
Note: It's just cosmetic change without any real difference in the operation.
TEST=Able to build and boot Google/Kano where CPU feature programming
is successful on all logical processors.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c77959a76d2240ad1bfb7a9d7b9db7e8aee42f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66685
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
If we already encountered the last extended capability in the
list, we'd call pciexp_get_ext_cap_offset() with `offset == 0`.
So it also needs to check if the passed offset is valid.
As there were no callers of pciexp_find_next_extended_cap()
yet, pciexp_get_ext_cap_offset() was only ever called with
`PCIE_EXT_CAP_OFFSET`.
Change-Id: I155c4691a34ff16661919913a3446fa915ac535e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The PSP currently uses a hard coded GPIO for the TPM IRQ. Not all board
versions use the same GPIO. This method allows the mainboard to pass
in the correct GPIO.
BUG=b:241824257
TEST=Boot guybrush and verify PSP message prints
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ie05d095d7f141d6a526d08fbf25eb2652e96aa49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Since bootblock_soc_early_init gets called before
bootblock_mainboard_early_init which does the early GPIO setup, external
I2C level shifters that are controlled by GPIOs might not be enabled yet.
Moving the reset_i2c_peripherals call to bootblock_soc_init makes sure
that the early GPIO setup is already done when reset_i2c_peripherals is
called.
Haven't probed any SCL signal on the non-SoC side of the I2C level
shifters yet, but the waveform on the SCL pin of I2C3 on the SoC of a
barla/careena Chromebook doesn't have the longer than expected SCL
pulses any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If02140aef56ed6db7ecee24811724b5b24e54a91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add support for SocInfo in coreboot. The API socinfo_modem_supported is
added to help to differentiate between LTE and WiFi SKUs.
BUG=b:232302324
TEST=Validate boards are detected correctly on LTE and Wifi SKUs
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Change-Id: I61047ad49772c3796ba403cafde311ad184a4093
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Add a new driver for NXP UWB SR1xx (e.g., SR150) device.
The driver was originally written by Tim Wawrzynczak as a WIP in
CL:3503703, and was based on drivers/spi/acpi.
BUG=b:240607130
BRANCH=firmware-brya-14505.B
TEST=On ghost (with follow-up CL), patch linux with NXP's pending
drivers
-> UWB device is probed and can respond to a simple hello
packet
Co-authored-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I5b1b0a5c1b48d0b09e7ab5f2ea6b6bc2fba2a7d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66466
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce the `BROADWELL_LPDDR3` Kconfig option along with some wrapper
code to allow mainboards using LPDDR3 DRAM to supply the DQ/DQS maps to
chipset code without having to use `pei_data`. The only mainboard using
LPDDR3 is Google Samus.
Change-Id: I0aaf0ace243c03600430c2a7ab6389a7b20cb432
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55812
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboards do not need to know about `pei_data` to tell northbridge code
where to find the SPD data. As done on Haswell, add the `mb_get_spd_map`
function and the `struct spd_info` type to retrieve SPD information from
mainboard code without having to use `pei_data` in said mainboard code.
Unlike Haswell MRC, Broadwell MRC uses all positions of the `spd_data`
array, not just the first. The placeholder SPD address for memory-down
seems to be different as well. Adapt the existing code to handle these
variations. Once complete, the abstraction layer for both MRC binaries
will have the same API.
Change-Id: I92a05003a319c354675368cae8e34980bd2f9e10
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
There's no generic way to tell whether a mainboard has an EC or not.
Making Kconfig symbols for these options seems overkill, too. So, just
put them on the devicetree. Also, drop unnecessary assignments when the
board's current value is zero, as the struct defaults to zero already.
Change-Id: I8d3b352333bea7ea6f7b0f96d73e6c2d7d1a2cfb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55809
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>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Introduce the `SPD_MEMORY_DOWN` macro to indicate that a slot is used
with memory-down. This enables computing the channel disable masks as
the bits for slots where the SPD address is zero. To preserve current
behavior, zero the SPD addresses for memory-down slots afterwards.
Change-Id: I75b7be7c72062d1a26cfc7b09b79de62de0a9cea
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55807
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To generate a complete _CPC ACPI object, coreboot needs the minimal and
nominal core speed values which are specific to the CPU and not only the
CPU family. Since this is done by an undocumented mechanism, FSP has to
do this and puts the information we need into a HOB. This adds the HOB
GUID and the structure of the HOB data.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Change-Id: Ibf338c32de367a3fd57695873da1625338fa196d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66549
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These files contain no creative content, and therefore have no
copyright. This effectively means that they are in the public
domain.
This commit updates the unlicensable empty (and effectively empty)
files with the CC-PDDX identifier for license compliance scanning.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I0b76921a32e482b6aed154dddaba368f29ac2207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66497
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A 32-bit long storing microseconds will rollover every ~1.19 hours.
This can cause stopwatch to misbehave, causing unexpected failures.
If the current field in stopwatch is near 2^31, the expires field may
rollover when initialized. If this occurs, stopwatch_expired() will
instantly return true.
If current and expires fields are near 2^31, the current field could
rollover before being checked. In this case, stopwatch_expired() will
not return true for over an hour. Also stopwatch_duration_usecs() will
return a large negative duration.
This issue has only been observed in SMM since it never takes more
than 35 minutes to boot.
Switching to uint64_t mitigates this issue since it will not rollover
for over 500K+ years. The raw TSC would rollover sooner than this,
~200 years, depending on the tick frequency.
BUG=b:237082996
BRANCH=All
TEST=Boot Nipperkin
Change-Id: I4c24894718f093ac7cd1e434410bc64e6436869a
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65403
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
DFD (Design for Debug) is a debugging tool, which scans flip-flops
and dumps to internal RAM on the WDT reset. After system reboots,
those values can be shown for debugging using MTK internal parsing
tools.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I6d19dc6f4e47ed69ba2ea87c79984020a413aee9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66586
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tracker is a debugging tool. When bus timeout occurs, the system will
reboot and latch some values of tracker registers which could be used
for debugging.
This function will be triggered only when it encounters the bus
hanging issue.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I78f676c08ea44e9bb10bd99bbfed70e3e8ece993
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66584
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This replaces 'SPDX-License-Identifier' tags in all the files under
soc/mediatek/mt8188 for better code re-use in other open source
software stack.
These files were originally from MediaTek and follow coreboot's main
license: "GPL-2.0-only". Now MediaTek replaces these files to
"GPL-2.0-only OR MIT" license.
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Change-Id: If61e8b252400e8e5ecd185b6806b1ca279065f15
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66628
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
Similar results are observed on Raptor Lake.
BRANCH=firmware-brya-14505.B
BUG=b:240669428
TEST=verify that EPP is back to the by default 50% setting
`iotools rdmsr 0 0x774'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I735ad9d88c7bf54def7a23b75abc4e89a213fb61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit 938f33e9f7.
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
BRANCH=firmware-brya-14505.B
BUG=b:240669428
TEST=verify that EPP is back to the by default 50% setting
`iotools rdmsr 0 0x774'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Icacc555e62533ced30db83e0a036db1c85c0bfa6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit 844dcb3725.
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
BRANCH=firmware-brya-14505.B
BUG=b:240669428
TEST=verify that ETT is disabled
`iotools rdmsr 0 0x1fc'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I96a72009aaf96d4237d57f4d5c8b1f41f87174d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66281
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
It's possible that some BARs are not got their resource successfully
mapped, e.g. when these BARs are too large to fit into the available
MMIO window.
Not assigned resources might be with base address as 0x0. During
global resource search, these not assigned resources should not be
picked up.
One example is MTRR calculation. MTRR calculation is based on global
memory ranges. An unmapped BAR whose base is left as 0x0 will be
mistakenly picked up and recognized as an UC range starting from 0x0.
Change-Id: I9c3ea302058914f38a13a7739fc28d7f94527704
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66347
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
coreboot uses TianoCore interchangeably with EDK II, and whilst the
meaning is generally clear, it's not the payload it uses. EDK II is
commonly written as edk2.
coreboot builds edk2 directly from the edk2 repository. Whilst it
can build some components from edk2-platforms, the target is still
edk2.
[1] tianocore.org - "Welcome to TianoCore, the community supporting"
[2] tianocore.org - "EDK II is a modern, feature-rich, cross-platform
firmware development environment for the UEFI and UEFI Platform
Initialization (PI) specifications."
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4de125d92ae38ff8dfd0c4c06806c2d2921945ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65820
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We want to extend the vb2ex_hwcrypto APIs on the vboot side to allow
passing 0 for the data_size parameter to vb2ex_hwcrypto_digest_init()
(see CL:3825558). This is because not all use cases allow knowing the
amount of data to be hashed beforehand (most notable the metadata hash
for CBFS verification), and some HW crypto engines do not need this
information, so we don't want to preclude them from optimizing these use
cases just because others do.
The new API requirement is that data_size may be 0, which indicates that
the amount of data to be hashed is unknown. If a HW crypto engine cannot
support this case, it should return VB2_ERROR_EX_HWCRYPTO_UNSUPPORTED to
those calls (this patch adds the code to do that to existing HW crypto
implementations). If the passed-in data_size value is non-zero, the HW
crypto implementation can trust that it is accurate.
Also reduce a bit of the console spew for existing HW crypto
implementations, since vboot already logs the same information anyway.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ieb7597080254b31ef2bdbc0defc91b119c618380
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
When powering down SSUSB, the system needs to wait the ACK from SSUSB.
We found that the setting of USB PAD top macro is not correct and
it will cause timeout waiting for the ACK from SSUSB.
To resolve this, we add mt_pll_set_usb_clock() in pll.c to enable usb
macro control for powering down SSUSB.
TEST=timeout of ssusb powerdown ack does not occur.
BUG=b:239634625
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.corp-partner.google.com>
Change-Id: I58ba86e0467284e9947bfda1005c151a3e0c8881
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66600
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This change provides access to IOE through P2SB Sideband interface for
Meteor Lake TCSS functions of pad configuration and Thunderbolt
authentication. There is a policy of locking the P2SB access at the end
of platform initialization. The tbt_authentication is read from IOM
register through IOE P2SB at early silicon initialization phase and its
usage is deferred to usb4 driver.
BUG=b:213574324
TEST=Built coreboot and validated booting to OS successfully on MTLRVP
board. No boot hung was observed.
Change-Id: Icd644c945bd293a8b9c4a364aaed99ec4a7c12f9
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Delete the Thunderbolt authentication function ioe_tcss_valid_tbt_auth
from the common block. Meteor Lake Platform will implement it.
BUG=b:213574324
TEST=Built coreboot image successfully.
Change-Id: I97a289faa6351fe562f91d8478b72c9403ce88cb
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
DDR5 memory modules have two separate 32-bit channels (40-bit on ECC
memory modules), and the SPD info refers to one channel: the primary
bus width is 32 (or 40) bits and the "DIMM size" is halved. On Alder
Lake, there are 2 memory controllers with 4 32-bit channels each for
DDR5. FSP has 16 positions to store SPD data, some of which are only
used with LPDDR4/LPDDR5.
To try to make things less confusing, FSP abstracts the DDR5 channels
so that the configuration works like on DDR4. This is done by copying
each DIMM's SPD data to the other half-channel. Thus, fix the wrapper
parameters for DDR5 accordingly.
Tested on AlderLake-P DDR5 RVP (board ID 0x12), both DIMM slots now
function properly. Without this patch, only the top slot would work.
Change-Id: I5f01cd77388b89ba34d91c2dc5fb843fe9db9826
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66608
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
