Chause doesn't get to x86 bootblock without the SPL table binary in the
PSP directory table, so I assume that Majolica won't get to x86
bootblock either, since the Cezanne SoC default is not to include any
SPL table binary. This was caused by a combination of
commit 6c5ec8e31c (amdfwtool: Add options
to support mainboard specific SPL table) that caused a regression in
amdfwtool and commit c5b912f788
(soc/amd/cezanne: Allow to specify SPL table path in Kconfig) that
removed the default for the Cezanne SoC. Fix this by adding the default
SPL table file back to the fw.cfg file which will get ignored by
amdfwtool when a mainboard selects SPL_TABLE_FILE and specifies another
SPL table binary.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ica960e5422da50899a2d9c192863188174e0bcff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Use the SPL table binary from the config file if no override is
specified via the spl-table command line argument. This fixes a
regression caused by commit 6c5ec8e31c
(amdfwtool: Add options to support mainboard specific SPL table).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I93419a878b41b1dfcbf58d930740aaae553120f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch removes different implementation to cache the SPI ROM between
early and later boot stage where SPI ROM caching doesn't need even
advanced implementation like `mtrr_use_temp_range()` as SPI ROM ranage
is always mapped to below 4GB hence, simple `set_var_mtrr()` function
can be sufficient without any additional complexity.
BUG=b:225766934
TEST=Calling into `fast_spi_cache_bios_region()` from ramstage is able
to update the temporary variable range MTRRs and showed ~44ms of boot
time savings as below:
Before:
90:starting to load payload 1,084,052 (14)
15:starting LZMA decompress (ignore for x86) 1,084,121 (68)
16:finished LZMA decompress (ignore for x86) 1,140,742 (56,620)
After:
90:starting to load payload 1,090,433 (14)
15:starting LZMA decompress (ignore for x86) 1,090,650 (217)
16:finished LZMA decompress (ignore for x86) 1,102,896 (12,245)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I43973b45dc6d032cfcc920eeb36b37fe027e6e8e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63221
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch delays removing `temporary` MTRR snapshots to avoid conflicts
with other operations attached with same `BS_PAYLOAD_BOOT/BS_ON_EXIT`
boot state.
BUG=b:225766934
TEST=Having variable MTRR snapshot using display_mtrrs() is able to
list only the permanent MTRRs and all temporary MTRRs are removed
prior to boot to payload.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I602dca989745159d013d6573191861b296f5d3ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch migrates a few useful MTRR functions as below from
`earlymtrr.c` file to newly created common stage file `mtrrlib.c`.
1. get_free_var_mtrr
2. set_var_mtrr
3. clear_all_var_mtrr
These functions can be used to perform the MTRR programming from IA
common code SPI driver as `fast_spi.c` without requiring two separate
implementations for early boot stage (till romstage) and for ramstage
onwards.
BUG=b:225766934
TEST=Able to build and boot google/redrix board to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c62a04a36d3169545c3128b4231992ad9b3699d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch enriches coreboot FSP2.0 driver to extract the FSP timestamp
from FPDT (Firmware Performance Data Table) and display right after
FSP-S exits (from `fsp_silicon_init()` function), based on SoC user
selects the required `DISPLAY_FSP_TIMESTAMPS` config.
The prerequisite to this implementation is to have FSP binary built with
`PcdFspPerformanceEnable` PCD set to `TRUE` to allow FSP to populate
the FPDT HOB.
BUG=b:216635831
TEST=Able to dump FSP performance data with DISPLAY_FSP_TIMESTAMPS
Kconfig selected and met the FSP prerequisites.
+--------------------------------------------------+
|------ FSP Performance Timestamp Table Dump ------|
+--------------------------------------------------+
| Perf-ID Timestamp(ms) String/GUID |
+--------------------------------------------------+
0 460253 SEC/52c05b14-0b98-496c-bc3b04b50211d680
50 460263 PEI/52c05b14-0b98-496c-bc3b04b50211d680
40 460274 PreMem/52c05b14-0b98-496c-bc3b04b50211d680
1 495803 9b3ada4f-ae56-4c24-8deaf03b7558ae50
2 508959 9b3ada4f-ae56-4c24-8deaf03b7558ae50
1 515253 6141e486-7543-4f1a-a579ff532ed78e75
2 525453 6141e486-7543-4f1a-a579ff532ed78e75
1 532059 baeb5bee-5b33-480a-8ab7b29c85e7ceab
2 546806 baeb5bee-5b33-480a-8ab7b29c85e7ceab
1 553302 1b04374d-fa9c-420f-ac62fee6d45e8443
2 563859 1b04374d-fa9c-420f-ac62fee6d45e8443
1 569955 88c17e54-ebfe-4531-a992581029f58126
2 575753 88c17e54-ebfe-4531-a992581029f58126
1 582099 a8499e65-a6f6-48b0-96db45c266030d83
50f0 599599 unknown name/3112356f-cc77-4e82-86d53e25ee8192a4
50f1 716649 unknown name/3112356f-cc77-4e82-86d53e25ee8192a4
2 728507 a8499e65-a6f6-48b0-96db45c266030d83
1 734755 9e1cc850-6731-4848-87526673c7005eee
....
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia1b7f6b98bafeec0afe843f0f78c99c2f34f50b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
* Use dedicated ALERT pin to resolve NO_RESPONSE error/status while
getting target configuration.
* Configure the ESPI to operate at 16 MHZ since operating at 33 MHz
causes boot stall.
BUG=b:226635441
TEST=Build and Boot to OS in Skyrim. Ensure that EC <-> AP communication
is working fine through Host Command debug logs in EC console, ectool
version command.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I951afdada8ee4f917cdeba8e287e5a2ae77c97ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63286
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Found an issue where emmc and sd clocks were being misconfigured due
to using incorrect integer values when called instead of the defined
enums. Fixing by splitting the clock_configure_sdcc() function into
two (sdcc1 and sdcc2) as there was no commonality between the two
cases anyway. As a result, we can also get rid of the clk_sdcc enum.
BUG=b:198627043
BRANCH=None
TEST=build herobrine image and test in conjunction with CB:63289
make sure assert is not thrown.
Change-Id: I68f9167499ede057922135623a4b04202f4da9b5
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
elog_gsmi_cb_mainboard_log_wake_source is called from SMI and causes
eSPI transactions. If the SMI interrupts an ongoing eSPI transaction
from the OS it will conflict and cause failures. Removing this call to
avoid conflicts. This can be re-enabled after refactoring
google_chromeec_get_mask to use ACPI MMIO.
BUG=b:227163985
BRANCH=gubyrush
TEST=No 164 errors detected during suspend_stress_test
/sys/firmware/log output after resume before change:
SMI# #1
ELOG: Event(B0) added with size 9 at 2022-03-31 19:52:51 UTC
GPIO Control Switch: 0xcf000000, Wake Stat 0: 0x00000000, Wake Stat 1: 0x00000000
ELOG: Event(9F) added with size 14 at 2022-03-31 19:52:51 UTC
Chrome EC: clear events_b mask to 0x0000000000000000
after change:
SMI# #6
ELOG: Event(B0) added with size 9 at 2022-03-31 19:50:19 UTC
GPIO Control Switch: 0xcf000000, Wake Stat 0: 0x00000000, Wake Stat 1: 0x00000000
ELOG: Event(9F) added with size 14 at 2022-03-31 19:50:19 UTC
Change-Id: I3320e3fb8bd9e9e0db84332e1d147a0af25f7601
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63280
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since Sabrina uses the image slot header (ISH) that depends on the AMD
A/B recovery scheme that depends on the multi-level PSP directory
support, the multi-level support gets automatically selected by passing
Sabrina as SoC name to amdfwtool, so passing the --multilevel command
line switch to amdfwtool isn't needed.
TEST=Timeless build results in identical binary for chausie
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I98154d5b47daca6ae7952ffd3175d98ea3e01845
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The fch_i23c_pad_init implementation was written without looking at any
reference code and turned out to not work properly on hardware. Before
this function writes to the MISC_I23C_PAD_CTRL registers, the value read
back is 0x3000003c which results in the I2C bus communication to work
while the 0x300003fc the code writes to the register breaks the I2C
communication. Removing the code that sets bits 6..9 fixes the I2C bus
communication.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: Ie6758b3d13c59b20ce810225fca8a365713b7a2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63234
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Contradicting the PPR #57243 version 1.56, the I2C3 pad control register
in the MISC ACPIMMIO region is the same new I23C pad type as the
corresponding registers for I2C0..2 and not the older I2C pad control
register type used on Picasso and Cezanne. All I2C pads being of the new
I23C type is in line with the GPIOMUX settings for the pins used by
I2C0..3 that can alternatively connect the pins to an I3C controller.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I51b0ddf8ba2ccfee823e3d4d26a77b11825b1029
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63233
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We set T3 as 300ms to meet Elan's spec, but the resume/suspend times
are greater than 500ms, which is the spec for Chromebooks.
The actual kernel timing has been measured, and given the ACPI delay
after deasserting reset in addition to the delay until the kernel
driver accesses the device, delaying only 200ms in the ACPI method is
also sufficient to meet the 300ms requirement.
BUG=b:223936777
BRANCH=none
TEST=build and test touchscreen function on DUT.
TEST=suspend, wake DUT and check touchscreen function.
Change-Id: I6b04cf6392d924aed01ca36b720f889b88d92311
Signed-off-by: Casper Chang <casper_chang@wistron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
C0 has no redriver, so enable SBU muxing in the SoC.
C1 has a redriver which does SBU muxing, so disable SBU muxing in the
SoC. However, this also disables AUX biasing when the pins are
configured as NF6. So instead configure the C1 AUX bias pins as GPO.
BUG=b:227259673
TEST=Voltages are correct on the C0 and C1 AUX bias pins
Change-Id: Ic0af662ecc1c6cee15b4ae98cb02deeefc93a71e
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Add new board Clevo L14xMU (TGL).
GPIOs were configured based on schematics.
Tested and working:
- On-board RAM (M471A1G44AB0-CWE)
- DIMM slot (tested Crucial CT16G4SFD8266.16FJ1 / MTA16ATF2G64HZ-2G6J1)
- Graphics (GOP driver), including HDMI
- Keyboard
- I2C touchpad (including interrupt)
- TPM (with interrupt on Windows, only polling on Linux [1])
- microSD Card reader
- both NVME ports
- Speakers
- Microphone
- Camera
- WLAN/BT (CNVi)
- All USB2/3 ports including Type-C
- Thunderbolt detects my work laptop in TB Control Center
(I couldn't test anything more due to security policy.)
- TianoCore
- internal flashing with flashrom on vendor firmware
Note on TPM:
The vendor sets Intel PTT to default-on in newer CSME images, which
conflicts with the dTPM. Currently, there are two ways to make it work:
1) Boot vendor firmware once to let it disable PTT via CSME firmware
feature override.
2) Use Intel Flash Image Tool (FIT) to set "initial power-up state" to
disabled.
Boots fine:
- Debian testing, unstable (Linux 5.16.14, 5.17.0-rc6)
- Windows 10 21H2 (Build 19044.1586)
Untested:
- Thunderbolt (see above)
- Type-C DisplayPort
- S-ATA
Doesn't work:
- TPM interrupt on Linux [1]
- All EC related functions - EC driver is WIP
- WLAN/BT (PCIe) - gets detected but can't be enabled
- 3G/LTE (not powered without EC driver)
- Fn-Keys
- S0ix
- UCSI
- Fan control
- Battery info
[1] https://lkml.org/lkml/2021/5/1/103
Change-Id: I4c4bef3827da10241e9b01e12ecc4276e131a620
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When rebuilding coreboot the empty fit table added to added to CBFS
stays the same so the build process sees no reason to update the file.
In the meantime ifittool did update that file for instance to add
microcode update entries. So each time coreboot is rebuilt the entries
are appended to the FIT table which runs out of space at some point.
One way to deal with this is to clear the fit table when setting the
pointer inside the bootblock.
TESTED: Now running 'make' again on prodrive/hermes does not report an
error with a filled FIT table.
Change-Id: Ia20a489dc90a4ae704e9ee6d532766899f83ffcc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63036
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Flame graphs are used to visualize hierarchical data, like call stacks.
Timestamps collected by coreboot can be processed to resemble
profiler-like output, and thus can be feed to flame graph generation
tools.
Generating flame graph using https://github.com/brendangregg/FlameGraph:
cbmem -S > trace.txt
FlameGraph/flamegraph.pl --flamechart trace.txt > output.svg
TEST=Run on coreboot-enabled device and extract timestamps using
-t/-T/-S options
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I3a4e20a267e9e0fbc6b3a4d6a2409b32ce8fca33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
