Use the common code to save data for fast boot or S3 resume.
An notable improvement that comes with this, is that the same 4K page
is not rewritten all the time. This prolongs the hardware's life.
TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine.
Change-Id: I0f4f36dcead52a6c550fb5e606772e0a99029872
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44295
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Save the regular boot MTRRs that are restored on the S3 path during
the CPU init in cbmem instead of storing them to the SPI flash.
This was probably done because historically this code run with late
cbmem init (in ramstage).
TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine.
Change-Id: Ia58e7cd1afb785ba0c379ba75ef6090b56cb9dc6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44294
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The size of the data used is fixed in this function so there is no
need for this aritmetic.
The function signature will be changed in a followup commit.
The cache_disable call is dropped as all the codepaths calling the
restore_mtrr function do this already.
TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine.
Change-Id: I3c6df8951d39695cddd4635360d6407d4d001b0a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44293
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
This patch removes the MTL CNVi DIDs macros from IA common code and is
added into the generic wifi driver.
As per Intel Connectivity Platform BIOS Guide, Connectivity Controller
IP for MTL-P is `Magnetar` and supported CRF is `Typhoon Peak 2`.
Previously Garfield Peak DIDs for Alder Lake SoC also added similarly
to generic wifi drivers.
BUG=b:224325352
TEST=Able to build and boot on MTL emulator.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib98762749c71f63df3e8d03be910539469359c68
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Add 'detect' flag which can be attached to devices which may or may not
be present at runtime, and for which coreboot should probe the i2c bus
to confirm device presence prior to adding an entry for it in the SSDT.
This is useful for boards which may utilize touchpads/touchscreens from
multiple vendors, so that only the device(s) present are added to the
SSDT. This relieves the burden from the OS to detect/probe if a device
is actually present and allows the OS to trust the ACPI _STA value.
Change-Id: I1a4169ed6416d544773a37d29cdcc154d3c28519
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
0-byte writes can be used as a way to probe/check presence of an i2c
device, so adjust _dw_i2c_transfer() to immediately set the STOP bit
and raise logger level for TX abort messages when the segment length
is zero. Adjust dw_i2c_transfer() to allow zero-segment-length
messages to be passed thru to _dw_i2c_transfer().
Tested as part of entire i2c-detect patch train.
Change-Id: I518e849f4c476c264a1464886b1853af66c0b29d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
There are efforts to have bootflows that do not follow a traditional
bootblock-romstage-postcar-ramstage model. As part of that CBMEM
initialisation hooks will need to move from romstage to bootblock.
The interface towards platforms and drivers will change to use one of
CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called
in the first stage with CBMEM available.
Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch fixes a potential corner case scenario where the value of
CONFIG_DEFAULT_CONSOLE_LOGLEVEL is less than `BIOS_SPEW` hence, coreboot
is unable to redirect FSP serial messages over UART.
Rather than passing hard coded `BIOS_SPEW` for the FSP debug handler,
this patch now calls get_log_level() function to pass the supported log
level while printing FSP serial msg.
BUG=b:225544587
TEST=Able to build and boot taeko. Also, able to see FSP debug log with
CONFIG_DEFAULT_CONSOLE_LOGLEVEL=7.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8a18101f5c3004252205387bde28590c72e05b9d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64460
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AGESA.h has a '#pragma pack' nested somewhere. The pack pragma packs all
structs which is not what is expected in the structs inside the headers
included below AGESA.h.
Change-Id: Ia70f68ea0ece7c097a37517206d75b71d695561f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
New device id 0x51f1 is added.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I695309d529a117bad68fc89a7f136e69cecb95d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
CPUID_RAPTORLAKE_P_J0 is ES. Add it to generate is_es = 1 in ACPI
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ib8d57f7fb0b3d15bc4bcdeae47bfbdde17e13118
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The postcar frame can now be a local variable to that function.
Change-Id: I873298970fff76b9ee1cae7da156613eb557ffbc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This removes some of the postcar setup boilerplate.
Change-Id: I4f8f92b88ac16dd70ff4878dfc14e676386d4703
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Setting up postcar MTRRs is done when invd is already called so there
is no reason to do this in assembly anymore.
This also drops the custom code for Quark to set up MTRRs.
TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set
in postcar & ramstage.
Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ti50 firmware versions below 0.0.15 don't support the firmware_version
register and trying to access it causes I2C errors. Some nissa boards
are still using Ti50 0.0.12, so add a workaround Kconfig to skip reading
the firmware version and select it for nissa. The firmware version is
only read to print it to the console, so it's fine to skip this. This
workaround will be removed once all ODM stocks are updated to 0.0.15 or
higher.
A similar workaround Kconfig was added in CB:63011 then removed in
CB:63158 which added support for separate handling of Cr50 and Ti50.
But we actually still need this workaround until all Ti50 stocks are
upgraded to 0.0.15 or higher.
BUG=b:224650720
TEST=Boot to OS on nereid with Ti50 0.0.14
Change-Id: Ia30d44ac231c42eba3ffb1cb1e6d83bb6593f926
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64202
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add chip driver for soldered down external USB hub. This driver adds
ACPI objects for the hub and any downstream facing ports.
BUG=b:227761300
TEST=Build and boot to OS in Skyrim. Ensure that the hub and any
configured ports have ACPI devices defined in SSDT.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I11d7ccc42d3dce8e136eb771f120825980e5c027
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63968
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When fwupd Retimer firmware update is enabled, it needs to
differentiate the Type-C port NDA and USB/DP/TBT/USB4 DA scenarios.
This change adds support to query devices attachment. If DA, it
deasserts the Retimer power and promptly returns -1 accordingly without
impacting the flow of Retimer firmware update under NDA. Additionally,
this patch deasserts the Retimer power during error conditions.
BUG=b:212235056, 224923449, 211790542
TEST=Validated Retimer firmware update under NDA and TBT3 docks
enumeration on Type-C ports under DA.
Change-Id: I5392d0d3a947dbf172cadfe03fc708f6e2e87210
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
It's useful to know how many attempts were made at polling the status
bit.
BUG=b:228289365
TEST=Boot guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcc79a339707fbaab33e128807d4c0b26aa90108
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63959
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
The previous code required a bit too much effort to read. It also didn't
print out the actual duration.
BUG=b:228289365
TEST=Boot guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia620e789c5186f2e1d3cf3c548bda00a294d23bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
A new iteration of Google's TPM implementation will advertize a new
DID:VID, but otherwise follow the same protocol as the earlier design.
This change makes use of Kconfigs TPM_GOOGLE_CR50 and TPM_GOOGLE_TI50
to be able to take slightly different code paths, when e.g. evaluating
whether TPM firmware is new enough to support certain features.
Change-Id: I1e1f8eb9b94fc2d5689656335dc1135b47880986
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Break TPM related Kconfig into the following dimensions:
TPM transport support:
config CRB_TPM
config I2C_TPM
config SPI_TPM
config MEMORY_MAPPED_TPM (new)
TPM brand, not defining any of these is valid, and result in "generic" support:
config TPM_ATMEL (new)
config TPM_GOOGLE (new)
config TPM_GOOGLE_CR50 (new, implies TPM_GOOGLE)
config TPM_GOOGLE_TI50 (new to be used later, implies TPM_GOOGLE)
What protocol the TPM chip supports:
config MAINBOARD_HAS_TPM1
config MAINBOARD_HAS_TPM2
What the user chooses to compile (restricted by the above):
config NO_TPM
config TPM1
config TPM2
The following Kconfigs will be replaced as indicated:
config TPM_CR50 -> TPM_GOOGLE
config MAINBOARD_HAS_CRB_TPM -> CRB_TPM
config MAINBOARD_HAS_I2C_TPM_ATMEL -> I2C_TPM && TPM_ATMEL
config MAINBOARD_HAS_I2C_TPM_CR50 -> I2C_TPM && TPM_GOOGLE
config MAINBOARD_HAS_I2C_TPM_GENERIC -> I2C_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_LPC_TPM -> MEMORY_MAPPED_TPM
config MAINBOARD_HAS_SPI_TPM -> SPI_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_SPI_TPM_CR50 -> SPI_TPM && TPM_GOOGLE
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Change-Id: I4656b2b90363b8dfd008dc281ad591862fe2cc9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add PROP method under \_SB.DPTF.TPWR scope which will return static
worst case rest of platform power in miliWatts.
This value is static, which has to configured from devicetree of
overridetree for each platform
BUG=b:205928013
TEST=Build, boot brya0 and dump SSDT to check PROP method
Scope (\_SB)
{
Device (DPTF)
{
Device (TPWR)
{
Method (PROP, 0, Serialized)
{
Return (XXXX)
}
}
}
}
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I1415d2a9eb55cfadc3a7b41b53ecbec657002759
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
BUG=None
TEST=Build and boot to OS in Skyrim. Ensure that the XHCI controllers
are enumerated successfully and ACPI device objects are added in SSDT.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I7ad4555212ed38ea0f9029275345e4945855a8c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63641
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add the member `use_gpio_for_status` to the structure
`drivers_usb_acpi_config`, so the `devicetree.cb` can specify it.
This field is then used to initialize the corresponding field in the
structure `acpi_power_res_params` in `usb_acpi_fill_ssdt_generator()`.
The member `acpi_power_res_params::use_gpio_for_status()` is already
being used by `acpi_device_add_power_res()` to determine which version
of the `_STA()` method to output.
BRANCH=None
BUG=b:225022810
TEST=Dump SSDT table for guybrush
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: I69eb5f1ad79f3b2980f43dcf4a36585fca198ec9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Commit 3ba6f8cdf (drivers/intel/fsp2_0: Add native implementation for
FSP Debug Handler) implements a native FSP debug handler.
However, coreboot still can't control when to redirect FSP debug
output to the serial console, i.e., at present, integrating a FSP debug
binary is enough to output FSP serial messages irrespective of whether
user is intended to see FSP debug log.
coreboot needs additional mechanism to control FSP debug binary to
redirect debug messages over serial port. This patch introduces a
config `FSP_ENABLE_SERIAL_DEBUG` to control the FSP debug output, user
to enable this config from site-local config file in case like to override
the default FSP serial redirection behaviour in more controlled way from
coreboot.
There could be scenarios as below:
Scenario 1: coreboot release image integrated with the FSP debug
binaries, is capable of redirecting to the serial console, but coreboot
decides to override the config as below to skip FSP debug output
redirection to the serial port.
`#`FSP Serial console disabled by default (do not remove)
`#`CONFIG_FSP_ENABLE_SERIAL_DEBUG is not set
Scenario 2: For coreboot serial image with FSP debug binaries integrated
but coreboot decides to skip FSP debug output redirection to the serial
port.
`#`FSP Serial console disabled by default (do not remove)
`#`CONFIG_FSP_ENABLE_SERIAL_DEBUG is not set
CONFIG_CONSOLE_SERIAL=y
CONFIG_CONSOLE_SERIAL_115200=y
CONFIG_UART_DEBUG=y
CONFIG_UART_FOR_CONSOLE=0
Scenario 3: The final image could be a coreboot serial image with FSP
serial redirection enabled to output to the serial port.
CONFIG_FSP_ENABLE_SERIAL_DEBUG=y
CONFIG_CONSOLE_SERIAL=y
CONFIG_CONSOLE_SERIAL_115200=y
CONFIG_UART_DEBUG=y
CONFIG_UART_FOR_CONSOLE=0
BUG=b:227151510
TEST=Able to build and boot google/redrix with all scenarios between #1--#3
and able to meet the expectation as mentioned above.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0b008ca9d4f40bfa6a989a6fd655c234f91fde65
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63166
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Follow-up commits move this to a common place.
Change-Id: I26a37f9384a581a8a750efccc2100a5c6a6f0f85
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The hob finding functions are never looped over so there is no point
for the 'next' inside their name.
Change-Id: I18e452d313612ba14edda479d43f2797f6c84034
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Checking whether a pointer is NULL after it has been dereferenced makes
zero sense. Make sure the `wifi_ssdt_write_properties()` function never
gets invoked with a NULL argument for the `dev` parameter, and simplify
the logic around the `is_cnvi_ddr_rfim_enabled` variable accordingly.
Change-Id: I3fbc9565e7e9b4e1c14a68f6a5fd779577045236
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch replaces the implementation that is used to get the number of
variable MTRRs with `get_var_mtrr_count()` function.
BUG=b:225766934
TEST=Able to build and boot google/redrix board to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4751add9c45374e60b7a425df87d06f52e6fcb8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
Add a stack in .bss for C execution. This will make it easier to move
the setup of MTRRs in C code.
Change-Id: I67cbc988051036b1a0519cec9ed614acede31fd7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Only Cr50 versions starting at 0.5.5 support long IRQ pulses, so this
feature is enabled based on the value of the board_cfg register (see
CB:61722).
However, Ti50 versions below 0.0.15 don't support the board_cfg
register, and trying to access it will cause I2C errors (see CB:63011).
Also, all Ti50 versions only support long IRQ pulses. Therefore, add a
workaround to force enable long IRQ pulses for boards using Ti50
versions under 0.0.15, instead of enabling it based on board_cfg. This
workaround will be removed once all Ti50 stocks are updated to 0.0.15 or
higher.
BUG=b:225941781
TEST=Boot nivviks and nereid to OS with Ti50 0.0.14 and check there are
none of these I2C errors:
[ERROR] I2C stop bit not received
[ERROR] cr50_i2c_read: Address write failed
[ERROR] cr50_i2c_tis_status: Failed to read status
Change-Id: Iaba71461d8ec79e8d6efddbd505339cdf1176485
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63160
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements coreboot native debug handler to manage the FSP
event messages.
`FSP Event Handlers` feature introduced in FSP to generate event
messages to aid in the debugging of firmware issues. This eliminates
the need for FSP to directly write debug messages to the UART and FSP
might not need to know the board related UART port configuration.
Instead FSP signals the bootloader to inform it of a new debug message.
This allows the coreboot to provide board specific methods of reporting
debug messages, example: legacy UART or LPSS UART etc.
This implementation has several advantages as:
1. FSP relies on XIP `DebugLib` driver even while printing FSP-S debug
messages, hence, without ROM being cached, post `romstage` would
results into sluggish boot with FSP debug enabled.
This patch utilities coreboot native debug implementation which is
XIP during FSP-M and relocatable to DRAM based resource for FSP-S.
2. This patch simplifies the FSP DebugLib implementation and remove the
need to have serial port library. Instead coreboot `printk` can be
used for display FSP serial messages. Additionally, unifies the debug
library between coreboot and FSP.
3. This patch is also useful to get debug prints even with FSP
non-serial image (refer to `Note` below) as FSP PEIMs are now
leveraging coreboot debug library instead FSP `NULL` DebugLib
reference for release build.
4. Can optimize the FSP binary size by removing the DebugLib dependency
from most of FSP PEIMs, for example: on Alder Lake FSP-M debug binary
size is reduced by ~100KB+ and FSP-S debug library size is also
reduced by ~300KB+ (FSP-S debug and release binary size is exactly
same with this code changes). The total savings is ~400KB for each
FSP copy, and in case of Chrome AP firmware with 3 copies, the total
savings would be 400KB * 3 = ~1.2MB.
Note: Need to modify FSP source code to remove `MDEPKG_NDEBUG` as
compilation flag for release build and generate FSP binary with non-NULL
FSP debug wrapper module injected (to allow FSP event handler to execute
even with FSP non-serial image) in the final FSP.fd.
BUG=b:225544587
TEST=Able to build and boot brya. Also, verified the FSP debug log is
exactly same before and with this code change.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I1018e67d70492b18c76531f9e78d3b58fa435cd4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63007
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
