Intel CBnT (and Boot Guard) makes the chain of trust TOCTOU safe by
setting up NEM (non eviction mode) in the ACM. The CBnT IBB (Initial
BootBlock) therefore should not disable caching.
Sidenote: the MSR macros are taken from the slimbootloader project.
TESTED: ocp/Deltalake boot with and without CBnT and also a broken
CBnT setup.
Change-Id: Id2031e4e406655e14198e45f137ba152f8b6f567
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
These PCIe and DMA ports are not available for adlrvp_m.
BUG=none
TEST=Boot device
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: Ic568c692fbb82fb3fc70c0cafc2328f8fa2cd74d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Enabling AC connect/disconnect wake events in brya to meet Chrome OS
wake requirements.
These changes are similar to Volteer and Shadowmountain.
BUG=none
BRANCH=None
TEST=manual tested DUT wakes for AC connect/disconnect in S0ix
Change-Id: I14b3efd429e3aa701af534f150baf35fcdeb9f35
Signed-off-by: madhusudanarao amara <madhusudanarao.amara@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54855
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Sooraj Govindan <sooraj.govindan@intel.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Initial upload of the GPIO configs for EHL CRB.
This CL also includes the UART GPIO configs in early GPIO table.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ied4cbb34149b0b837597c0fc17dc5956f3ca409e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54891
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We would like to have an easy way to completely disable TPM support on a
board. For boards that don't pre-select a TPM protocol via the
MAINBOARD_HAS_TPMx options, this is already possible with the
USER_NO_TPM option. In order to make this available for all boards, this
patch just removes the whole USER_TPMx option group and directly makes
the TPM1 and TPM2 options visible to menuconfig. The MAINBOARD_HAS_TPMx
options can still be used to select defaults and to prevent selection of
a protocol that the TPM is known to not support, but the NO_TPM option
always remains available.
Also fix some mainboards that selected TPM2 directly, which they're not
supposed to do (that's what MAINBOARD_HAS_TPM2 is for), and add a
missing dependency to TPM_CR50 so it is set correctly for a NO_TPM
scenario.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib0a73da3c42fa4e8deffecb53f29ee38cbb51a93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54641
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This fixes the following error from the Linux kernel:
ccp 0000:03:00.2: ioremap failed
ccp 0000:03:00.2: initialization failed
ccp: probe of 0000:03:00.2 failed with error -12
BUG=b:186575712,b:189202985
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id1c6a6cbbdda2cb22e81e2b52b364617d6765e09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54963
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes the following error from the Linux kernel:
ccp 0000:03:00.2: ioremap failed
ccp 0000:03:00.2: initialization failed
ccp: probe of 0000:03:00.2 failed with error -12
BUG=b:186575712,b:189202985
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5cbc620001d3c21c538b62ab2811b6e07269feb2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54962
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We were missing the stdint.h header, and the header was sorted
incorrectly in chip.h
BUG=non
TEST=build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I209d3c9c48e5b06b2a56759af51cf2858eb99f51
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The firmware config field in CBI lets us control initialization
parameters based on the OEM design.
BUG=b:188713024
TEST=Build
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I56ddc7218688919f20f41e0f143419c39d83849d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54732
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the default for the corresponding UPD of the Picasso FSP is
DXIO_PSPP_POWERSAVE and the devicetree default is DXIO_PSPP_PERFORMANCE,
add a deviectree setting for each board that's using the Picasso SoC
code to not change the setting for the existing boards.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0008ebb0c0f339ed3bdf24ab95a20aa83d5be2c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The only FSP 1.1 platform is Braswell. Drop unnecessary functions which
only have a weak stub definition.
Change-Id: Ie60213e5a6ae67bd8b982ee505f4b512253577c6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
hexdump and hexdump32 do similar things, but hexdump32 is mostly a
reimplementation that has additional support to configure the console
log level, but has a very unexpected len parameter that isn't in bytes,
but in DWORDs.
With the move to hexdump() the console log level for the hexdump is
changed to BIOS_DEBUG.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6138d17f0ce8e4a14f22d132bf5c64d0c343b80d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54925
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The only FSP 1.1 platform is Braswell, which has a non-weak definition
for the `soc_silicon_init_params` function. This changes the resulting
BUILD_TIMELESS=1 coreboot image for Facebook fbg1701, for some reason.
Change-Id: I2a1b51cda9eb21d7af8372c16a43195a4bdd9543
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The only FSP 1.1 platform is Braswell. Drop unused weak definitions for
functions where a non-weak definition always exists.
Tested with BUILD_TIMELESS=1, Facebook fbg1701 remains identical.
Change-Id: Ifaf40a1cd661b123911fbeaafeb2b7002559a435
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Commit 736a1028fb (drivers/intel/fsp1_1:
Drop dead MMA code) dropped FSP 1.1 MMA code, but missed a few things.
Change-Id: I556e7125eff21c49609bb1e5e1f23e99e692756f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Not sure which policy we should select here or if that should be done in
the board-specific devicetree overrides instead of the baseboard.
BUG=b:188793754
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I792d909ce75cb73571c9fec58c18f749ea3ae029
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54933
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows boards to specify which PSPP policy (basically a dynamic
trade-off between power consumption and PCIe link speed) should be used
and also makes sure that the boards are using the expected PSPP policy
and not just the UPD default from the FSP binary that has already
changed once during the development.
BUG=b:188793754
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1b6459b2984711e72b79f5d4d90e04cb4b78d512
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54930
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TBT PowerResource _ON/_OFF methods are currently invoked by _PS0 and
_PS3 respectively. It is defined for ACPI driver to call _ON and _OFF
methods. This change drops the _PS0 and _PS3 call for _ON/_OFF and
returns TBT PowerResource declaration in the _PR0 and _PR3, then ACPI
driver will call the TBT PowerResource _ON and _OFF methods.
BUG=b:188891878
TEST=Traced both of TBT _ON and _OFF methods invocation and execution
at run time. Verified TBT's power_state to be D3Cold.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I398b3f58ec89f98673cbbe633149d31188ec3351
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Generic Initiator Affinity structure is introdcued in ACPI spec 6.3.
This structure is used to define NUMA affinity domain which is
established by generic initiator (such as by CXL device).
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ic6ef01c59e02f30dc290f27e741027e16f5d8359
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
No board currently uses AMD PI 00630F01 so remove it.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: If270c2a979346029748230952caba78a5e763d75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
No board uses AMD PI 00630F01, so drop it. And drop a single reference
to the now-removed `NORTHBRIDGE_AMD_PI_00630F01` Kconfig option inside
the `drivers/amd/agesa/acpi_tables.c` file.
Change-Id: Ibc45a4a6041220ed22273c1d41f9b796e1acb901
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54897
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Microcode header supports advertising support for only one CPU
signature and processor flags. If there are multiple processor
families supported by this microcode blob, they are mentioned in
the extended signature table.
Add support to parse the extended processor signature table to
determine if the microcode blob supports the currently running CPU.
BUG=b:182234962
TEST=Booted ADL brya system with a processor whose signature/pf are
in the extended signature table of a microcode patch. Was able to
match and load the patch appropriately.
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Change-Id: I1466caf4a4ba1f9a0214bdde19cce57dd65dacbd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch also adds the additional 10 MCAX registers to the BERT MSR
error record.
BUG=b:186038401
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I31912d3b3e77e905f64b6143042f5e7f73db7407
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This patch includes changes to update the soundwire master count.
Change-Id: Iffaf90569c19fb5ca3ce4775cc6dc6f8093f7c52
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
After Thunderbolt firmware is downloaded to IMR, its authentication
validity needs to be checked. This change implements the valid_tbt_auth
function. Thunderbolt DSD and its corresponding IMR_VAID will be
present to kernel only if its authentication is successful.
BUG=b:188695995
TEST=Validated TGL TBT firmware authentication and its IMR_VALID
into SSDT which is properly present to kernel.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I3c9dda341ae6f19a2a8c85f92edda3dfa08c917a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
After Thunderbolt firmware is downloaded to IMR, its authentication
validity needs to be checked. This change adds the TBT firmware IMR
status register offset and its authentication valid bit for
valid_tbt_auth function usage.
BUG=b:188695995
TEST=Built coreboot image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I742a00b6b58c45c1261f06b06a94346ad0a74829
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54888
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After Thunderbolt firmware is downloaded to IMR, its authentication
validity needs to be checked. This change adds the TBT firmware IMR
status register offset and its authentication valid bit for
valid_tbt_auth function usage.
BUG=b:188695995
TEST=Built Voxel coreboot image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ia25827f18a10bf4d2dcabfe81565ac326851af3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54709
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All relevant USB phy settings can now be controlled via devicetree.
The given values are the AMD default ones.
For proper tuning procedure and values contact AMD.
Signed-off-by: Julian Schroeder <julianmarcusschroeder@gmail.com>
Change-Id: Ie8d08bde54f8c0cb8202ba111b9c7a9bd33fa03e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The AMD FSP is using a new structure for USB and USB C phy settings.
This patch removes old, unused structures, adds the new one and
enables the devicetree interface for it.
Signed-off-by: Julian Schroeder <julianmarcusschroeder@gmail.com>
Change-Id: I011ca40a334e4fd26778ca7f18b653298b14019b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Building google/sarien with a 64-bit compiler (x86_64-linux-gnu) fails
with the error below.
src/ec/google/wilco/mailbox.c: In function 'wilco_ec_transfer':
src/ec/google/wilco/mailbox.c:184:43: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
184 | printk(BIOS_ERR, "%s: data too short (%lu bytes, expected %zu)",
| ~~^
| |
| long unsigned int
| %u
185 | __func__, rs.data_size - skip_size, msg->response_size);
| ~~~~~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
`data_size` has type `uint16_t`, and `skip_size` has type `size_t`,
whose size differs in 32-bit (unsigned int) and 64-bit (unsigned long).
So use the length modifier `z` for a `size_t` argument.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Change-Id: Ida27323daeed9b8ff487302d0f3d6fcce0bbb705
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie
The FSP-M/S/T related headers added are generated as per FSP v3162.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ie6e6db704bcf86034fc9a3423101f0391ba2327e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54869
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Remove the extra UAB devices in xhci.asl
2. Update SD controller ADR in scs.asl
3. Remove the unused SCS PID
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I1906fb4e6893dc5e2b0bc8d85f4a7b2efc85c3a4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54867
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update SA & IGD DIDs table as per latest EDS (Doc no: 601458).
Add extra SKUs and fix the mismatched SKU numbers accordingly.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I62fd9e6a7cf0fc6f541f3d6d9edd31d41db7279f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Configure GPIO CAM_PDN5 (AP_XHCI_INIT_DONE) as output, so that
payloads (for example depthcharge) can assert it to notify EC to enable
USB VBUS.
BUG=b:187149602
TEST=emerge-asurada coreboot
BRANCH=asurada
Change-Id: I3bf63f91b8057e35be2780024a8b398c3044729b
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54902
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Incorrect size of the einj structure was being used, which created an
invalid checksum message by the OS. This patch fixes the issue.
Test=Booted to Linux on Deltalake mainboard and verified invalid checksum
message is not logged in syslog. Exact message -> 'ACPI BIOS Warning
(bug): Incorrect checksum in table [EINJ] - 0xDA, should be 0xD9'
Change-Id: I2b1722d6960d4a62d14fb02ac5e8838397e12f92
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54787
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prepare to allow using other backends to store options.
Change-Id: I3f838d27bf476207c6dc8f2c1f15c3fa9ae47d87
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Commit 88dcb3179b (src: Retype option API to use unsigned integers)
changed the option API to use unsigned integers, but missed this.
Change-Id: I5deb17157db41c40cc72078e2af9cf65bdbe0581
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
scan-build found a dead assignment, that the value stored to `res` is
never read. Use `pci_dev_read_resources()` instead, as done in
`sb/intel/common/smbus_ops.c` since commit 5f734327
(sb/intel/common/smbus_ops.c: Clean up read resources) avoiding the
assignment.
Change-Id: Ic59063b05a45dca411bf5b56c1abf3dd66ff0437
Found-by: scan-build (coreboot toolchain v0ad5fbd48d 2020-12-24 - clang version 11.0.0)
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Build of the entire smm-class is skipped if we have
HAVE_SMI_HANDLER=n.
Change-Id: I64bdcb28a996609111861ebafe172493b0650354
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54852
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Rocky Phagura
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
haboki/habokay is the same design as drawlat/drawcia, and differs only
in replacing Cr50 with discrete TPM.
BUG=b:187094464
TEST=FW_NAME=haboki emerge-keeby coreboot
Cq-Depend: chrome-internal:3850094
Change-Id: Id866927b7041c5bf1c73fb4f0c03798eb61efa79
Signed-off-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54755
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ESPI_SLAVE_CHANNEL_READY is a read-only bit from the host perspective.
It is set when the eSPI peripheral has configured the channel.
We actually want to set the ESPI_SLAVE_CHANNEL_ENABLE flag. This never
caused an issue before because the peripheral channel is enabled by
default after PLTRST# is deasserted. This does fix the case where
periph_ch_en == 0. It now properly clears the enable flag.
BUG=b:188188172, b:188935533
TEST=Boot guybrush to OS, perform warm reset
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I24e0734d5652601ae9c967da528fec5e3f780991
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add new memory MT53E512M32D1NP-046 WT:B in the mem_parts_used.txt and
generate the SPD ID for the parts.
BUG=b:183057749
BRANCH=dedede
TEST=Build the cret board.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: Ib797af858e8f7ea275291e552102db74f4724aad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54747
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ChromeEC might take longer than 1ms for the peripheral channel to be
enabled. The PLTRST# interrupt handler takes about ~539us.
This doesn't account for the time it takes for the interrupt handler
to be scheduled. Increasing the timeout to 10ms gives ample time.
BUG=b:188188172, b:188935533
TEST=Boot guybrush and no longer see channel enable errors
Suggested-by: Rob Barnes <robbarnes@google.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib6db577bf06175ceb17b446af706ad8c9f891481
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54788
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The set_ts_fit_ptr makefile target was never a dependency of another
target and therefore not used.
Change-Id: Ie6b20164fce0dc406a28b4c1b9f41a79c68c27d7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
'-t' is not needed when setting the FIT pointer and breaks
it as '-t' needs an argument so the $(TS_OPTIONS) is not properly
decoded.
Change-Id: I61a3ac1eda42e04152a7d10953bfb8407813d0f3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54679
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Make sure the fit pointer is set up before entries are added.
Change-Id: I285fbb830a52e43cde5e8db9569a64dafb4408df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Meera Ravindranath <meera.ravindranath@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
This reverts commit 2f8a7046bb.
Reason for revert: CB:54752 makes this unnecessary
Change-Id: I3ad0bcafe50e3eafb9a106720c6c9ea5cb0efc4f
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54789
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the introduction of fw_config support in coreboot, it is possible
for mainboards to control the state of a device (on/off) in ramstage
using fw_config probe conditions. However, the device tree in
immutable in all other stages and hence `is_dev_enabled()` does not
really reflect the true state as in ramstage.
This change adds a call to `fw_config_probe_dev()` in
`is_dev_enabled()` when device tree is immutable (by checking
DEVTREE_EARLY) to first check if device is disabled because of device
probe conditions. If so, then it reports device as being
disabled. Else, dev->enabled is used to report the device state.
This allows early stages (bootblock, romstage) to use
`is_dev_enabled()` to get the true state of the device by taking probe
conditions into account and eliminates the need for each caller to
perform their own separate probing.
Change-Id: Ifede6775bda245cba199d3419aebd782dc690f2c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54752
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a helper function `fw_config_probe_dev()` that allows
the caller to check if any of the probe conditions are true for any
given device. If device has no probe conditions or a matching probe
condition, then it returns true and provides the matching probe
condition back to caller (if provided with a valid pointer). Else, it
returns false. When fw_config support is disabled, this function
always returns true.
Change-Id: Ic2dae338e6fbd7755feb23ca86c50c42103f349b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54751
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
fw_config is unprovisioned in the factory for the first boot. This is
the only case where fw_config is left unprovisioned. On first boot in
factory, fw_config gets correctly provisioned by the factory
toolkit. When fw_config is unprovisioned, it is not always possible to
make a guess which device to enable/disable since there can be certain
conflicting devices which can never be enabled at the same time. That
is the reason the original implementation of fw_config library kept
fw_config as 0 when it was unprovisioned.
CB:47956 ("fw_config: Use UNDEFINED_FW_CONFIG to mean unprovisioned")
added support for a special unprovisioned value to allow any callers
to identify this factory boot condition and take any appropriate
action required for this boot (Ideally, this would just involve
configuring any boot devices essential to getting to OS. All other
non-essential devices can be kept disabled until fw_config is properly
provisioned). However, CB:47956 missed handling the
`fw_config_probe()` function and resulted in silent change in behavior.
This change fixes the regression introduced by CB:47956 and returns
`false` in `fw_config_probe()` if fw_config is not provisioned yet.
Change-Id: Ic22cd650d3eb3a6016fa2e2775ea8272405ee23b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54750
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The default of CBFS_MCACHE_SIZE is increased to 0x4000 in CB:54146 but
we have limited space on the PSP thus cannot afford it.
BUG=b:177091575
BRANCH=none
Signed-off-by: Kangheui Won <khwon@chrmoium.org>
Change-Id: I94dd782ae00d0b18ad6dd2fc061e4318bda88579
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This new definition is for MT53E512M32D1NP-046 WT:B used on Cret.
BUG=b:183057749
TEST=Generate SPDs
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: Ica5df61d96d2c4cbe62a560a53bd3bd08eb121f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Update ACPI HID to 10025682 for Machine driver probe
BUG=b:187912480
TEST=Build and boot to OS in Mancomb. Ensure that the sound card probed.
Signed-off-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Change-Id: I5dc87c7a8fb876adc26165655f8f2d4157aa68c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54749
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
NCP_ERR is a 1 byte register in I/O-space, so use inb and not inw. The
variable the result gets assigned to is also a uint8_t.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9fd8c139004111d6227c0316ba2a8b0281541654
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54736
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
BUG=b:188446049
TEST=Build and boot to OS in mancomb. Ensure that the system can suspend
and resume successfully. Ensure that the sleep state GPIOs are
reflecting the state as expected.
Change-Id: I43e86a07075fe66f89c2c5665adc209e985e4f04
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
commit ce0e2a0140 (drivers/intel/fsp2_0:
use FSP to allocate APEI BERT memory region) adds a mechanism to reserve
the BERT region inside the coreboot code, so we can get rid of the
workaround to reserve it in the FSP and return the location in a HOB.
mcfg->bert_size defaults to 0 which makes the FSP not generate the
corresponding HOB, but that field is planned to be removed at least on
Cezanne, so don't explicitly set it to 0.
BUG=b:169934025
TEST=BERT table that gets generated in a follow-up patch for Picasso
points to expected BERT region and Linux is able to access, decode and
display it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaca89b47793bf9982181560f026459a18e7db134
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52584
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most of the time when INIT_BOOTBLOCK is selected, the cache should be
empty here anyway, so this is a no-op. But when it's not empty that
means the bootblock loaded some other file before it got to the TPM
init part (which is possible, for example, if hooks like
bootblock_soc_init() load something).
Change-Id: I4aea86c094abc951d7670838f12371fddaffaa90
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In order to fill out static entries for a _PRT table for
soc/intel/common, the PIRQ<->IRQ mapping is required. This patch adds
a function lpc_get_pch_pirq_routing() which returns this mapping.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib215fba54573c50a88aa4584442bd8d27ae017be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Drawper support LTE+HDMI,
so use DB_PORTS_1A_HDMI_LTE to select HDMI VBT output for it.
BUG=b:186393848
BRANCH=dedede
TEST=Build and boot to OS check HDMI output works.
Change-Id: Ibf34cce1e3cbfce8a71dce880c50f85db9295b1e
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
TPM_RUNTIME_DATA_PCR is for "for measuring data which changes during
runtime e.g. CMOS, NVRAM..." according to comments. FMAP does not
change during runtime.
Change-Id: I23e61a2dc25cd1c1343fb438febaf8771d1c0621
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Enable ASPM, Common Clock and Clock Power Managment. Accomplish this
by adding the options in the platform Kconfig as well as dxio
descriptors.
BUG=b:187743927
TEST=Boot to ChromeOS and see ASPM, CC and Clock PM enabled with lspci
Change-Id: I9d6e606763798afc6b797d7d24ee7cae09f9e33f
Signed-off-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54681
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable ASPM, Common Clock and Clock Power Managment. Accomplish this
by adding the options in the platform Kconfig as well as dxio
descriptors.
BUG=b:187743927
TEST=Boot to ChromeOS and see ASPM, CC and Clock PM enabled with lspci
Change-Id: Iefc4b5b489cb8caf59f21dd4333d7af66ba47c32
Signed-off-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54282
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
UI monitors this input event and sends global mic mute command to CRAS
when the physical switch is toggled.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on DUT.
Apply crrev.com/c/2870806 with chrome cmdline flag and verify global
mute is triggered.
Verify sequences of switch toggle and suspend/resume.
Change-Id: Id89947885fdd96c5b5d598bda6db127daf298dc3
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Added SW_MUTE_DEVICE event type for mic mute switch.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on puff:
/dev/input/event3: mic_mute_switch
UI event_device_info receives the proper name.
Change-Id: I09c52dc3df63e266c73741b102a22f8a2b896791
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Added the label field to the gpio_keys _DSD so that the kernel driver
can use a meaningful name instead of the generic _HID PRP0001.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on puff:
/dev/input/event3: mic_mute_switch
UI event_device_info receives the proper name.
Change-Id: I0377851b9cf23bab31930aed6e7de91b4ac3505b
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
MAINBOARD_HAS_TPM1 should not be selected, since the module is
replaceable.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: Ia3790154476b0db54f37e1f3abb91ba5ee891c31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8Z77-M PRO
remains identical when not adding the .config file in it.
Change-Id: I7f1d93e500153a9821e7ddb693d77c864c879f0d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8Z77-V LX2
remains identical when not adding the .config file in it.
Change-Id: Ia84b07f5fec3c2969134b0d0bc39248d50ac04ff
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The mainboard.c guard was only added to preserve reproducibility when
unifying the boards. The `install_intel_vga_int15_handler` function does
nothing when `VGA_ROM_RUN` is not selected. Remove the guard and always
select `INTEL_INT15` for simplicity.
Change-Id: If38ca49dba81921a3e7abe22542ae74d8914a38d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To preserve reproducibility, temporarily guard mainboard.c contents.
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8Z77-M PRO
remains identical when not adding the .config file in it.
Change-Id: I05e272690ca78f6b9e22b1db1c36cb9e5a7afe3c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Done to preserve reproducibility when switching to a variant setup.
Change-Id: I4f3663d3b58c6245c9b73d370a48b8745ea5b95b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Get ready to squash all Asus Z77 boards together, so as to factor out
some redundant code.
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8Z77-V LX2
remains identical when not adding the .config file in it.
Change-Id: I701ec4adbc65732ffc0a60d311bf07bf7f414ebf
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8H61-M LX
remains identical when not adding the .config file in it.
Change-Id: I3142773e8c8f11f27f7926933097ffde8ba241e2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54390
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus H61M-CS
remains identical when not adding the .config file in it.
Change-Id: I34eb5387fddcb3505c9218b20b706b773e979b0e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54389
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8H61-M PRO
remains identical when not adding the .config file in it.
Change-Id: I443d3823e32a246a89ff12e52a0301b2c252e23b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54388
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8H61-M LX3 R2.0
remains identical when not adding the .config file in it.
Change-Id: I989f69d000a38a7b1f4e0832341aa347cc0bfe98
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54387
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Done to preserve reproducibility when switching to overridetrees.
The H61 PCH only supports 6 PCIe root ports anyway.
Change-Id: I926d62dda512e435d44c0646083c7722427dc80b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54386
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The mainboard.c guard was only added to preserve reproducibility when
unifying the boards. The `install_intel_vga_int15_handler` function does
nothing when `VGA_ROM_RUN` is not selected. Remove the guard and always
select `INTEL_INT15` for simplicity.
Change-Id: If51a0ab1c57b0856018a62cf669e5d1b53e5333c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The H61 PCH only supports 4 SATA ports, and does not support Gen3.
Change-Id: I3e060ca6904fd6c773c322988a17bbca28333a3d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
I added these devicetrees in commit 65ddbb720b (mb/asus/p8h61-m_pro:
Add new mainboard) and commit fe7c2b996b (mb/asus/p8h61-m_lx3_r2_0:
Add new mainboard). To ease licensing matters when transforming these
boards to use overridetrees, relicense the devicetrees so that all of
them use the GPL-2.0-or-later license.
Change-Id: Id26d0d9dd6cbb81d6a6a263feab7f36ddb4ff6e6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Handle some differences in the DSDT code using preprocessor.
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8H61-M LX
remains identical when not adding the .config file in it.
Change-Id: I2a02f32dfd9fa9c1adce3baf0d279ea19db5883f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
When locking down TXT is skipped, e.g. to do error injection, locking
down DMI3 and IIO DFX related TXT registers should also be skipped.
Change-Id: Ieef25c02ec103eaef65d8b44467ccb9e6917bb6c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50238
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Rocky Phagura
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
RAS error injection requires TXT and other related lockdown steps to
be skipped.
Change-Id: If9193a03be7e1345740ddc705f20dd4d05f3af26
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Taken from Broadwell. A follow-up will make Broadwell use the IOBP code
from Lynx Point.
Change-Id: Iacc90930ad4c34777c8f1af8b69c060c51a123b5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52514
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Do it in the same place as Broadwell.
Tested on out-of-tree Compal LA-A992P, SATA still works.
Change-Id: I50bd951af52d03ad986dbf4bf70bdae348fa994b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47034
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The time constant values were taken from the zork thermal.asl.
BUG=b:186166365
TEST=Boot guybrush to OS and verify logs look correct
thermal-0294 thermal_trips_update : Found critical threshold [3641]
thermal-0321 thermal_trips_update : No hot threshold
thermal-0200 thermal_get_temperatur: Temperature is 3060 dK
thermal-0219 thermal_get_polling_fr: Polling frequency is 100 dS
thermal-0200 thermal_get_temperatur: Temperature is 3060 dK
thermal LNXTHERM:00: registered as thermal_zone0
ACPI: Thermal Zone [TM00] (33 C)
thermal-0200 thermal_get_temperatur: Temperature is 3070 dK
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iaeed75bdaa16b117d0fa7144ede98db1388f74f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54134
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This adds the required method to access temperature data from the
ChromeEC.
BUG=b:186166365
TEST=Boot guybrush to the OS and verify temperatures
$ tail /sys/devices/virtual/thermal/thermal_zone*/temp
==> /sys/devices/virtual/thermal/thermal_zone0/temp <==
31900
==> /sys/devices/virtual/thermal/thermal_zone1/temp <==
34900
==> /sys/devices/virtual/thermal/thermal_zone2/temp <==
31900
==> /sys/devices/virtual/thermal/thermal_zone3/temp <==
33900
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I418b6691a7d00a4c2d89c9c1fe8f9416602be0f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54133
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify the value of "SPEAKER_GPIO_NAME" in katsu as rt1015p sdb
BUG=None
BRANCH=kukui
TEST=Speaker can work normally in katsu during firmware stage
Signed-off-by: Sunway <lisunwei@huaqin.corp-partner.google.com>
Change-Id: Ib3672383ab34bb07b4e5eb7f7e8b4549e13c67b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54642
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Correct the Realtek ALC3254 codec name in the comment. The name is used
in the original commit message, and is also present in the Linux kernel
(`sound/pci/hda/patch_realtek.c`).
The file was an exact copy of
`src/mainboard/google/sarien/variants/arcada/include/variant/hda_verb.h`
added in commit 95370e1f (mb/google/sarien: Add HD Audio verb table).
Change-Id: I43cd73a14e07eb4518e3d44b6f81dff5016da721
Fixes: e3443d87 ("mb/google/drallion: Add new mainboard")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Correct the Realtek ALC3254 codec name in the comment. The name is used
in the original commit message, and is also present in the Linux kernel
(`sound/pci/hda/patch_realtek.c`).
Change-Id: Id8a099297bd8bcebf9734e1beee2449fdcca75c5
Fixes: 95370e1f ("mb/google/sarien: Add HD Audio verb table")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This debug output is not very useful. If CONFIG_BOOTBLOCK_CONSOLE is
enabled there will already be something else printed on the console
before this.
Change-Id: I7c6013805497604bb6a42ed4f9fdc594a73c28f1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Rocky Phagura
Enable AMD I2S machine driver and configure the devicetree with HID
information so that the machine driver ACPI objects can be passed to the
kernel. Also configure Audio Co-processor(ACP) to operate in I2S TDM mode.
BUG=b:187860242
TEST=Build and boot to OS in Guybrush. Ensure that the ACPD device is
enabled in the appropriate scope in SSDT.
Signed-off-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Change-Id: I528f90d81a418236e512a1e0840ff44c3a3a983e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54549
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The handler is the same on all Bay Trail mainboards. Factor it out.
Change-Id: Ia1b6faaca4792cda5f14948d23498182bf4bb2c3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54415
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Máté Kukri <kukri.mate@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move discrete TPM in the devicetree to avoid emitting the following
message: "Using default TPM ACPI path: '\_SB_.PCI0.LPCB'"
There is no corresonding ACPI device for 1f.5 PCI device. Therefore,
move the discrete TPM to a device that has the corresponding ACPI
device node. Functionality should remain the same.
BUG=b:187518267
Change-Id: Ie9ec70336d5651c87f06f8b357abd1bfdb1cc06b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Aseda Aboagye <aaboagye@google.com>
When performing an in-band reset the host controller and the
peripheral can have mismatched IO configs.
i.e., The eSPI peripheral can be in IO-4 mode while, the
eSPI host will be in IO-1. This results in the peripheral
getting invalid packets and thus not responding. This causes the
NO_RESPONSE status bit to be set and cause eSPI init to fail.
If the peripheral is alerting when we perform an in-band
reset, there is a race condition in espi_send_command.
1) espi_send_command clears the interrupt status.
2) eSPI host controller hardware notices the alert and sends
a GET_STATUS.
3) espi_send_command writes the in-band reset command.
4) eSPI hardware enqueues the in-band reset until GET_STATUS
is complete.
5) GET_STATUS fails with NO_RESPONSE and sets the interrupt
status.
6) eSPI hardware performs in-band reset.
7) espi_send_command checks the status and sees a
NO_RESPONSE bit.
As a workaround we allow the NO_RESPONSE status code when
we perform an in-band reset.
BUG=b:186135022
TEST=suspend_stress_test and S5->S0 tests on guybrush and zork.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I71271377f20eaf29032214be98794e1645d9b70a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Rob Barnes <robbarnes@google.com>
I'm not 100% sure if this should rather be duplicated from Picasso or
commonized. Checked with the docs and this won't be compatible with
Stoneyridge and one future product's PPR lacked the corresponding
register. Some other chip has a compatible register layout, but a
different number of PCIe GPP clock outputs, so the common code would
need to use some SoC-dependent defines and possibly a SoC-specific
lookup table for the mapping which is also not that great.
TEST=Checked Cezanne PPR
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6b6d0cb8d7eb0288d8a18fcb975dc377b2c6846a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54685
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since this enum is only used for the devicetree settings and not for the
hardware itself, move it from the southbridge header to the chip one.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0907fc5cba9315fec5fabff67d279c6d95d1c9f0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54684
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to use the USB WWAN module in USB mode (as opposed to PCIe),
the PCIe RP must be turned off at the FSP level. The `probe` statement
in the devicetree unfortunately takes effect too late, because the UPDs
for disabling/enabling PCIE RP belong to FSP-M (romstage), whereas
fw_config probing for devicetree is done in ramstage.
Add a new variant-specific file which will handle manually setting the
UPD based on FW_CONFIG instead.
BUG=b:180166408
TEST=set CBI FW_CONFIG field to LTE_USB, see message in console,
set field to LTE_PCIE, do not see message in console.
Change-Id: Ica2f64ec99fa547e233012dc201577a14f6aa7d7
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54633
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot needs to access EC RFWU entry in order to suspend and resume PD
and modes setting. This change adds ec_retimer_fw_update implementation
for retimer firmware upgrade.
BUG=b:186521258
TEST=Build image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ib937d8bd72fc39487854773573b435bf2add672a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52713
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This changes updates mainboard properties by adding DFP number and
power_gpio for each DFP.
BUG=b:186521258
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I29480bf77f7df9890bef64a5f9f02074a34dc131
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This changes updates mainboard properties by adding DFP number, PLD
and power_gpio for each DFP.
BUG=b:186521258
TEST=Validated Retimer firmware upgrade along with upstream kernel under
no device attached scenario.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I18f29ce5f8450a8b0f8208a60b8b607f9f0d8817
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52714
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Along with upstream kernel for Retimer firmware upgrade, coreboot
provides DFPx under host router where each DFP has its PLD and DSM. The
DFPx's functions encapsulates power control through GPIO, PD
suspend/resume and modes setting for Retimer firmware update under NDA
scenario.
BUG=b:186521258
TEST=Booted to kernel and validated host router's DFPx properties after
decomposing SSDT table.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I81bef80729f6df57119f5523358620cb015e5406
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52712
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Along with upstream kernel for Retimer firmware update, coreboot defines
power control for each DFP respectively under host router. This change
removes the power_gpio from the baseboard. Individual DFPx power_gpio
will be added once the dependent definition is complete.
BUG=b:186521258
TEST=Build image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I819d2900afabbfdb2713fa8eee35d3c90cb904fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Along with upstream kernel for Retimer firmware update, coreboot defines
power control for each DFP respectively under host router. This change
removes the power_gpio from baseboard. Individual DFPx power_gpio will
be added once the dependent definition is complete.
BUG=b:186521258
TEST=Build image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Iec2437ab20d283d080752a80aa4514aa9af6897e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52711
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Along with upstream kernel for Retimer firmware update, coreboot changes
the ec_retimer_fw_update format. This change removes this API and will
add implementation later once the dependent definition is complete.
BUG=b:186521258
TEST=Build image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I2d074b84fb3cb87b443871104b72b6c316af5279
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
We were not adding power management handling of GPIO_COM3 in gpio.asl
This can affect s0ix flow where platform won't go into s0ix since
GPIO_COM3 is not power gated.
BUG=b:188392183
BRANCH=None
TEST=Platform should enter to s0ix and GPIO COMM3 should not block an
entry to s0ix.
Change-Id: I3f269c66bdd6337adb0d2bd29d0b7d72ced19ec4
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
We recently added GPIO definition for PCIE vGPIO for Alder Lake.
We also need to disable GPIO dynamic PM for this community which is
already done for other communities as well.
BUG=b:188392183
BRANCH=None
TEST=Code compiles and Check if dynamic PM for GPIO COMM3 is also
disabled
Change-Id: I2f8645b8f4a9995e727a7623af97531c5de52892
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54383
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This removes the need to include this code separately on each
platform.
Change-Id: I3d848b1adca4921d7ffa2203348073f0a11d090e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The new kernel secdata v1 stores the last read EC hash, and reboots the
device during EC software sync when that hash didn't match the currently
active hash on the EC (this is used with TPM_CR50 to support EC-EFS2 and
pretty much a no-op for other devices). Generally, of course the whole
point of secdata is always that it persists across reboots, but with
MOCK_SECDATA we can't do that. Previously we always happened to somewhat
get away with presenting freshly-reinitialized data for MOCK_SECDATA on
every boot, but with the EC hash feature in secdata v1, that would cause
a reboot loop. The simplest solution is to just pretend we're a secdata
v0 device when using MOCK_SECDATA.
This was encountered on using a firmware built with MOCK_SECDATA but had
EC software sync enabled.
BUG=b:187843114
BRANCH=None
TEST=`USE=mocktpm cros build-ap -b keeby`; Flash keeby device, verify
that DUT does not continuously reboot with EC software sync enabled.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Id8e81afcddadf27d9eec274f7f85ff1520315aaa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
To preserve reproducibility, temporarily guard mainboard.c contents.
This will be removed once all boards have become variants.
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus H61M-CS
remains identical when not adding the .config file in it.
Change-Id: I1ffb41470d24713a4a7f0689958b733d4b1bdf52
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8H61-M PRO
remains identical when not adding the .config file in it.
Change-Id: Iaa53a8a1b75f4c7359e32c6cd8c8a488c5763bbe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Get ready to squash all Asus H61 boards together, so as to factor out
lots of redundant code.
Tested with BUILD_TIMELESS=1, coreboot.rom for the Asus P8H61-M LX3 R2.0
remains identical when not adding the .config file in it.
Change-Id: I738197bf4d5ea8b879ae26ecbcb0cf3714316662
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In preparation to switch the Asus H61 boards to a variant setup, sort
the `select` lines in Kconfig alphabetically.
Change-Id: I91ee7dc601f1fc52a7d68f66555143156b91ebf9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54365
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In preparation to switch the Asus H61 boards to a variant setup, sort
the `select` lines in Kconfig alphabetically.
Change-Id: Ia5a8d36f78db2262b4c8d48cbb4dd16718d01475
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54364
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In preparation to switch the Asus H61 boards to a variant setup, sort
the `select` lines in Kconfig alphabetically.
Change-Id: I96486d57250e901d872e4ef12967c2aadd9791ea
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54363
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 65ddbb720b (mb/asus/p8h61-m_pro: Add new mainboard) added this
file, and I authored this commit. Since most gma-mainboard.ads files are
licensed as GPL-2.0-or-later, relicense this one for consistency.
Change-Id: I2d28150f4c97ba600cb46fead7bb29cdc65c5baf
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54362
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These boards have a socketed CPU, and the PCI device ID for the iGPU
depends on the installed CPU. Specifying a default doesn't make sense.
Change-Id: Iee6749e4fb691f09664cc6ffb3cbf66e4230fa9c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54361
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboards with variants may not always use the same cmos.layout file.
Turn the hardcoded path into a Kconfig symbol to allow changing it.
Tested with BUILD_TIMELESS=1: Without including the config file in the
coreboot.rom and with `USE_OPTION_TABLE` selected, building for the Asus
P8H61-M PRO produces an identical coreboot image.
Change-Id: I4cc622dcb70855c06cb8a816c34406f8421180df
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54366
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most boards use `device lapic 0 on` with zero written in decimal.
For the sake of consistency, update the remaining boards to follow suit.
Change-Id: I1d3b1ac107e33aae11189cdd5e719b8e48b10f08
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Most boards use `device domain 0 on` with zero written in decimal.
For the sake of consistency, update the remaining boards to follow suit.
Change-Id: I6e2f0a19d57cfe6fc4e4ac4d14310133ad6b01d8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Most boards use `device cpu_cluster 0 on` with zero written in decimal.
For the sake of consistency, update the remaining boards to follow suit.
Change-Id: I083c8f8e9b38ddcc217dc8bf17ae3c9473ba77e9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Definition for NAV_FWE BIT was added in commit e6e8b3d
Even if try to set this BIT it was not getting set since PAD_CFG_DW0
mask will make it 0 since this bit was not part of mask.
Adding NAV_FWE to mask will resolve this issue and BIT will be set/unset
as per programming in mainboard.
TEST=Check GPIO register dump and see if BIT is getting set properly.
Change-Id: I970ae81ed36da45c3acc61814980b2e6ff889445
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54350
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable/disable LTE function based on LTE bit of FW_CONFIG.
The LTE function settings are included GPIO settings, USB port settings and
power off sequence.
BUG=b:187797408
BRANCH=dedede
TEST=Build and test the change on cret.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: Ib926e99aaf9df433a7cff71180ee55431d69f718
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Since we have TPM disabled on ADLRVP, if we enable EC sync, it keeps
rebooting with hash error.
Change-Id: I62a4fceb83dc6b20f699b4662e8f421aadafdee5
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
The `tcrt` and `tpsv` values in GNVS can be used to implement thermal
management in ACPI. However, not all mainboards use these values.
On mainboards where `tcrt` and `tpsv` are not used in ACPI tables and
are the only values set in the `mainboard_fill_gnvs` function, remove
them as well as the entire `acpi_tables.c` file. Most files come from
autoport, which unconditionally generates this file.
Change-Id: If2315ddd9700e2da0a24ffecc20acb5c1a1d688e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54353
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I07bdf7f85f8411e04da8a94da7de1e7b93c9e921
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
To support gpio reset SoC, we need to pass the reset gpio parameter to
BL31.
TEST=execute `echo b > /proc/sysrq-trigger` to reboot system
Change-Id: I1a55216c0d5a00bbdb373d931bd50ebe7ca5694f
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
PSP_SOFTFUSE_BITS used to be like this:
15 0 29 "28 6"
It causes internal shell report error:
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
Change-Id: I716f19d37fb57b9ef3fc7259c6dcca7d21022d32
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
DisableDimmMc0Ch0 upds changed to DisableMc0Ch0 in new FSP releases. The definition
of the upd also changed. Changed FSP meminit code to work based on new definition of the UPDs.
Before:
0:Enable both DIMMs, 1:Disable DIMM0, 2:Disable DIMM1, 3:Disable both DIMMs
After:
0:Enable, 1:Disable
TEST=Boot to OS
Cq-Depend: chrome-internal:3831865, chrome-internal:3831864, chrome-internal:3831913
Cq-Depend: chromium:TODO
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I5af11ae99db3bbe3373a9bd4ce36453b58d62fec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54036
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The headers added are generated as per FSP v2162_00.
Previous FSP version was v2117_00.
Changes Include:
- Adjust UPD Offset in FspmUpd.h and FspsUpd.h
- Remove DisableDimmMc*Ch* Upds in FspmUpd.h
- Add DisableMc*Ch* Upds in FspmUpd.h
- Few UPDs description update in FspmUpd.h and FspsUpd.h
Change DisableDimmMc*Ch* to DisableMc*Ch* in meminit.c to avoid
compilation failure other change related to UPDs name change will be
part of next patch in relation chain.
BUG=b:187189546
BRANCH=None
TEST=Build and boot ADLRVP using all the patch in relation chain.
Change-Id: Ic8d7980146f1bfc96472ef504cf9f16eee63a13e
Cq-Depend: chrome-internal:3831865, chrome-internal:3831864, chrome-internal:3831913
Cq-Depend: chromium:TODO
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54083
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMBus I/O bar is not relocated because it's reported to the
allocator as a fixed resource. Drop these out-of-date comments.
Change-Id: I0149764fd231b3a4e56a5a9b7f4ae61f7954cf7a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This commit has coreboot create the Chrome OS Firmware Management
Parameters (FWMP) space in the TPM. The space will be defined and the
contents initialized to the defaults.
BUG=b:184677625
BRANCH=None
TEST=emerge-keeby coreboot
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I1f566e00f11046ff9a9891c65660af50fbb83675
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
The name `set_space()` seems to imply that it's writing to a TPM space
when actually, the function can create a space and write to it. This
commit attempts to make that a bit more clear. Additionally, in order
to use the correct sizes when creating the space, this commit also
refactors the functions slightly to incorporate the vboot context object
such that the correct sizes are used. The various vboot APIs will
return the size of the created object that we can then create the space
with.
BUG=b:184677625
BRANCH=None
TEST=`emerge-keeby coreboot`
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I80a8342c51d7bfaa0cb2eb3fd37240425d5901be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54308
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure DDI-0 connector type to DP.
BUG=b:187856682
TEST=Build and boot into OS
Signed-off-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Change-Id: Ic8af14509b0d246c5c2da6e1a48991384471e69f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
TCSS OC pins have not been correctly configured for volteer.
This patch fills the value from devicetree to correct the OC pins
mapping.
BUG=b:184660529
BRANCH=None
TEST="emerge-volteer coreboot chromeos-bootimage", flash volteer2 and
verify CpuUsb3OverCurrentPin UPDs get set correctly.
Change-Id: I12da755a1d3b9ec3ed0a2dbfb0782313dd49c7e9
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
We need to change OC pin for type C USB3 ports and it depends
on the board design. Allowing it to be filled by devicetree will
make it easier to change the mapping based on the board design.
BUG=b:184660529
TEST="emerge-volteer coreboot" compiles without error.
Change-Id: I5058a18b1f4d11701cebbba85734fbc279539e52
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Initialize and calibrate DRAM in romstage.
Signed-off-by: Ryan Chuang <ryan.chuang@mediatek.com>
Change-Id: Ib7677baef126ee60bf35da3a4eaf720eaa118a27
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Updated CPU ID and IGD ID for Alder Lake as per EDS.
TEST=Code compilation works and coreboot is able to boot and identify
new device Ids.
Change-Id: I2759a41a0db1eba5d159edfc89460992914fcc3c
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
I suspect there is additional initialization required to enable the
8042 keyboard controller on the EC. By removing the range we no longer
encounter long 20 second delays when reading the IO ports. Since
depthcharge polls the IO ports it makes it seem like depthcharge locked
up.
BUG=b:182100027
TEST=Boot majolica with depthcharge to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I56a7eb4200e4615e1b4d9f14594d64f93e031a54
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Switch to device alias names in devicetree. Remove unnecessary comments
since the names are self-explanatory.
Change-Id: Id486d9bd44bd7ba6a93a5f757af487b211e58efa
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
GPIO communities 0, 1, and 4 have virtual wire indexes & bits for at
least some of their groups; add the known information into the community
definitions. This patch is ported form tigerlake.
Change-Id: I2f1e2413d06e8afe4233d7111763cb45b78f845b
Signed-off-by: Deepti Deshatty <deepti.deshatty@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
volta will use different wifi SAR from voxel.
Using clamshell mode of fw config to decide to load volta wifi sar.
BUG=b:184820057
TEST=build and verify wifi power as expect.
Cq-Depend: chrome-internal:3824093
Signed-off-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Change-Id: I000aefca63346c70556688f232ca54360b3badef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54051
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add initial HMAT (Heterogeneous Memory Attribute Table) support based
on ACPI spec 6.4 section 5.2.27.
Add functions to create HMAT table (revision 2) and create HMAT Memory
Proximity Domain Attribute (MPDA) Structure.
TESTED=Simulated HMAT table creation on OCP DeltaLake server, dumped
the HMAT table and exmained the content. HMAT table and one MPDA
structure are added.
OCP Delatake server is based on Intel CooperLake Scalable Processor
which does not support CXL (Compute Express Link). Therefore solution
level testing is not done.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I5ee60ff990c3cea799c5cbdf7eead818b1bb4f9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
PCIE6 only needed when use the PCIE LTE.
BUG=b:180166408
BRANCH=none
TEST=FM350 can/can't be detected when enable/disable this config.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I9dce05fdb6eb956a054d3815ff706b94f0d3fc37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Configure USB HUB_RESET_L gpio to high.
BUG=b:187485847
TEST=Build and boot from USB to OS, check the USB function.
Signed-off-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Change-Id: I94e4806c7463030df31f8d819510f9533a622f2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This is the DRAM initialization code from the reference
implementation released by Mediatek for MT8195.
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: Ryan Chuang <ryan.chuang@mediatek.com>
Change-Id: Iada3ec5ae8a39a8e9253caba550c834d486dddcd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Initialize DRAM in romstage and configure to support fast calibration.
Change-Id: I89b87be62c8e88ae4a620d56aa7a35e47f97952d
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Signed-off-by: Ryan Chuang <ryan.chuang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54229
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default, FSP disables the GFX HDA. Enable it to support HDMI Audio
functionality.
BUG=b:186479763
TEST=Build and boot to OS in guybrush. Ensure that the GFX HDA is
enumerated in lspci output.
04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637
Change-Id: I42cb26c44bbca3d937c5d52736c42468139f7b07
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54100
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CBFS mcache size default was eyeballed to what should be "hopefully
enough" for most users, but some recent Chrome OS devices have already
hit the limit. Since most current (and probably all future) x86 chipsets
likely have the CAR space to spare, let's just double the size default
for all supporting chipsets right now so that we hopefully won't run
into these issues again any time soon.
The CBFS_MCACHE_RW_PERCENTAGE default for CHROMEOS was set to 25 under
the assumption that Chrome OS images have historically always had a lot
more files in their RO CBFS than the RW (because l10n assets were only
in RO). Unfortunately, this has recently changed with the introduction
of updateable assets. While hopefully not that many boards will need
these, the whole idea is that you won't know whether you need them yet
at the time the RO image is frozen, and mcache layout parameters cannot
be changed in an RW update. So better to use the normal 50/50 split on
Chrome OS devices going forward so we are prepared for the eventuality
of needing RW assets again.
The RW percentage should really also be menuconfig-controllable, because
this is something the user may want to change on the fly depending on
their payload requirements. Move the option to the vboot Kconfigs
because it also kinda belongs there anyway and this makes it fit in
better in menuconfig. (I haven't made the mcache size
menuconfig-controllable because if anyone needs to increase this, they
can just override the default in the chipset Kconfig for everyone using
that chipset, under the assumption that all boards of that chipset have
the same amount of available CAR space and there's no reason not to use
up the available space. This seems more in line with how this would work
on non-x86 platforms that define this directly in their memlayout.ld.)
Also add explicit warnings to both options that they mustn't be changed
in an RW update to an older RO image.
BUG=b:187561710
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I046ae18c9db9a5d682384edde303c07e0be9d790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable DPTF functionality for Alder Lake based brya
BRANCH=None
BUG=b:188028732
TEST=Built and tested on brya board
Change-Id: I33266c85aa30869466034ccbab04a3c7820ae2b0
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
gcc 11 suspects missing braces here, but it seems the line should be
executed in all cases, so unindent it.
Change-Id: I7b8cacd48e86284c5145c4e8ffb6add75a743108
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
While memcpy(foo, bar, 0) should be a no-op, that's hard to prove for a
compiler and so gcc 11.1 complains about the use of an uninitialized
"bar" even though it's harmless in this case.
Change-Id: Idbffa508c2cd68790efbc0b4ab97ae1b4d85ad51
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54095
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
gcc 11.1 complains when we're passing a type* into a function that was
declared to get a type[], even if the ABI has identical parameter
passing for both.
To prepare for newer compilers, adapt to this added constraint.
Change-Id: I5a1b3824a85a178431177620c4c0d5fddc993b4f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
