This commit adds a new timestamp, `TS_FIRMWARE_SPLASH_RENDERED`
(ID 557), to precisely mark the moment the firmware splash screen has
finished displaying.
The timestamp is recorded in `src/drivers/intel/fsp2_0/silicon_init.c`
within the `do_silicon_init` function. It's conditionally added based on
the platform's configuration:
- For platforms using FSP's native BMP rendering (prior to FSP 2.2, with
`CONFIG(BMP_LOGO)` and without
`CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`).
- For platforms where coreboot handles BMP rendering (`CONFIG(BMP_LOGO)`
and `CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`).
This enhancement provides better visibility into the boot process and
allows for more accurate performance analysis related to splash screen
display time.
BUG=b:418935715
TEST=Able to build and boot google/fatcat. Verified below details in
`cbmem -t`.
```
557:Firmware splash screen rendering finished 47,193,590 (2,235)
```
Change-Id: Ibef967dbc6e224741438e9708b42486ba03d0104
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87812
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit refactors the code by eliminating unnecessary NULL pointer
checks for the `efi_bmp_image_header header` parameter in several
functions. The calling function `fsp_convert_bmp_to_gop_blt` already
verifies that the `header` pointer is not NULL before invoking these
functions, rendering these checks redundant. Similarly, checks for
`adjusted_x` and `adjusted_y` in `calculate_adj_height_width` have been
removed. This streamlines the code and reduces unnecessary operations.
Additionally, the `is_bmp_image_compressed` function has been simplified
for improved readability by directly returning the result of the
compression type comparison.
Change-Id: Ia8afcac0fb21633e379f5d8b9713ba6f8b92c1c8
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87616
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add IDs from the EDS, with a couple extras:
- eSPI: EDS says 0x7202, but our boards show 0x7702
- GT: Value changes between 0x7d51 and 0x7dd1 based on DIMMs installed
Change-Id: I8430914edd02954cbb38592bff896733b01c735d
Ref: Intel Arrow Lake-H/U EDS, Volume 1 (#777369, rev 2.0)
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87131
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The get_color_map_num function previously returned 0 for both error
conditions (e.g., NULL header, invalid image offset) and for BMPs
that legitimately lack a color map, such as 24-bit BMP logo. This
ambiguity prevented the correct processing of 24-bit BMPs for
firmware splash screens, as the caller could not distinguish them
from malformed images.
This commit addresses this by refining error handling:
1. Modifying `get_color_map_num` to return -1 for actual errors.
2. Ensuring a return value of 0 from `get_color_map_num` now
unambiguously signifies that the BMP has no color map. This
is relevant for formats like 24-bit or 32-bit, where the
default switch case now explicitly sets the color map count to 0.
3. Changing the function's return type and its internal color map
count variable (`col_map_number`) to `int` to accommodate the
negative error code.
4. Updating the caller, `fsp_convert_bmp_to_gop_blt`, to check for
a return value `< 0` to identify errors, separating these from
the valid no-colormap case (return 0).
These changes enable the successful rendering of 24-bit BMP images
as firmware splash screens. This also provides more robust BMP
parsing and clearer error distinction overall.
BUG=b:410318591
TEST=Able to build and boot google/fatcat. Verified 24-bit
BMP logo is able to render successful.
Change-Id: I7006e823e10b9892da17ff904095ef5892bb690d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87581
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit implements coreboot native logo rendering when
`USE_COREBOOT_FOR_BMP_RENDERING` Kconfig is enabled.
When enabled, this option allows coreboot to perform the boot logo
rendering directly after the FSP initializes the display. A new API
`soc_load_logo_by_coreboot` is introduced for this purpose.
This approach offers greater flexibility for platform-specific logo
customizations (e.g., alignment) that might be impractical to
implement within the FSP.
Note that enabling this option might introduce a slight delay (~10-30ms)
in displaying BMP images compared to FSP-based rendering.
BUG=b:409718202
TEST=Built and booted google/fatcat. Verified boot splash was rendered
by coreboot as `USE_COREBOOT_FOR_BMP_RENDERING` was set to `y`.
Change-Id: I9454d0941458e29a5533a92170831f360765b413
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87541
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch introduces `USE_COREBOOT_FOR_BMP_RENDERING`, a Kconfig option
allowing platforms to choose coreboot to use its native bitmap (BMP)
logo image rendering and skip using the FSP for this purpose during
the boot process.
By default this option is disabled (default 'n'), therefore, the FSP
is utilized for displaying the BMP logo by populating the necessary
FSP UPD parameters.
Select this option for platforms that will use a coreboot native
implementation for BMP rendering (note: the native coreboot rendering
path is still under development/to be implemented).
This Kconfig provides the switch for such future integration.
Key changes:
- A new boolean Kconfig `USE_COREBOOT_FOR_BMP_RENDERING` is added under
`drivers/intel/fsp2_0/Kconfig`. It depends on `BMP_LOGO` and
defaults to 'n'.
- The help text clarifies that selecting this option will skip FSP-based
BMP rendering. Deselection implies a fallback to the FSP based
implementation.
- The function `soc_load_logo`, previously responsible for populating
FSP UPD parameters for the logo, is renamed to `soc_load_logo_by_fsp`.
This clarifies its role is specific to FSP-driven logo display.
- The call to `soc_load_logo_by_fsp` in `fsp2_0/silicon_init.c` is
now conditional on `CONFIG(BMP_LOGO)` being enabled but the new
`CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)` remains disabled.
- Implementations and calls to the renamed function are updated across
relevant SoC directories (AMD Mendocino, Intel Alder Lake, Apollolake,
Cannon Lake, Meteor Lake, Panther Lake, Skylake).
This change offers platforms greater flexibility in managing BMP logo
display, allowing them to either leverage FSP capabilities or integrate
with coreboot's native methods as they become available.
BUG=b:409718202
TEST=Built and booted google/fatcat. Verified boot splash was rendered
by FSP as `USE_COREBOOT_FOR_BMP_RENDERING` was set to `n`.
Change-Id: Ieda085df02263b9bf4bdd8f5d0e2137bef75def9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87513
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This patch moves `struct hob_graphics_info` and `fsp_graphics_info_guid`
into the FSP header file.
This change allows other coreboot APIs to utilize this information for
locating FSP graphics-related data to know the display resolutions and
other useful information (required for coreboot native implementation
of rendering splash screen).
BUG=b:409718202
TEST=Able to build and boot google/fatcat.
Change-Id: I445a4efa59769f25c93fc61ad1d15857716f5247
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87538
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fsp_gop_blt.h header includes `enum lb_fb_orientation`. This enum
is defined within `<boot/coreboot_tables.h>`.
This commit adds the necessary include directive to ensure that
`enum lb_fb_orientation` is available.
BUG=b:409718202
TEST=Able to build and boot google/fatcat.
Change-Id: I0e432bef13ab1425c29e9ca4a82b06ff264a8613
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87537
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds Wildcat Lake-specific CPU and PCIe device IDs to the
header files and driver-specific code.
Reference:
Wildcat Lake Processor Prelim External Device IDs (820363)
BUG=b:394208231
TEST=Verified on Wildcat Lake Simulation Platform
Change-Id: I4bc7a8ea898ee30d565a95b9f85d6f19886bcffb
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87262
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's an ACPI spec violation for a device to have both an _ADR and
a _HID method, so prefer the latter if a HID value is specified
via the chip registers.
Change-Id: I5d84dbea52595e61df56a5ff779d5e0ee0d84bdf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87248
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change addresses an issue in the touch driver where the ACPI _PRW
method was added unconditionally. The ACPI _PRW method should only be
generated when an Interrupt() resource is used in the _CRS method.
When a GpioInt() resource is used instead, the _PRW method is not
required.
The ACPI generation code has been updated to conditionally add the
_PRW method based on whether the wake source is a GPIO interrupt or
an IRQ interrupt. Now, the _PRW method is only added when an IRQ pin
is specified, which is consistent with ACPI requirements.
BUG=none
TEST=Configure the DRIVERS_INTEL_TOUCH option on a motherboard that
has the necessary touch configurations with wake support. Verify that
the THC ACPI tables are correctly generated in the SSDT. If wake_gpio
(i.e. GpioInt()) is used for wake, no _PRW is generated for the device.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I56fc8486c7494ff37c1d580d57838fee286128a6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87085
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement logo bitmap rotation within fsp_convert_bmp_to_gop_blt() to
support devices with portrait-oriented displays. The rotation is driven
by the panel framebuffer orientation, allowing the logo to be displayed
correctly regardless of physical panel orientation.
This resolves issues where the logo was displayed incorrectly on
portrait-oriented displays.
Additionally, discard the display orientation change if the LID is
closed aka built-in display is not active. This will ensure that
display orientation is proper when extended display is attached w/o
any display rotation.
BUG=b:396580135
TEST=Verified BMP logo display in landscape mode on a portrait panel
with rotation enabled. Also verified portrait logo display in landscape
mode with rotation enabled.
Change-Id: I110bd67331f01e523c227e1a4bdb0484f0157a60
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86850
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Taken from an ACPI dump from a Windows JSL device with MIPI camera.
Change-Id: Ibdb2b148ebfa85c3d4f5af2594b9b8847215e726
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This patch corrects spacing around assignment operators in the
`fill_blt_buffer` to comply with coding style guidelines, specifically
within the BMP color translation logic for 1/4/8/24/32-bit images.
Change-Id: Ia243d11568ec4c3d1108ff60289743919394aa32
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86860
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces a driver for the Intel Touch Controller (THC),
which supports HID-over-I2C and HID-over-SPI protocols, as well as
touch devices. The driver generates ACPI objects and publishes data
into the Secondary System Descriptor Table (SSDT) to facilitate
interaction with the touch hardware.
The driver implementation covers the following ACPI objects:
- _DSM (Device Specific Method)
- _CRS (Current Resource Settings)
- _STA (Power resource with Status), including _ON and _OFF methods
- _DSD (Device Specific Data) for THC-I2C
- _RST (Device Reset) for THC-SPI
Template device configuration for the following supported devices:
- Wacom: SPI touchscreen only
- Elan: both SPI and I2C touchscreen
- Hynitron: I2C touchpad only
It also includes template configurations for supported devices such as
Wacom (SPI touchscreen), Elan (SPI and I2C touchscreen), and Hynitron
(I2C touchpad). These configurations are divided into device-specific,
SoC-specific, and motherboard (MB)-specific details.
For SoC-specific configuration, the driver implements functions like
`soc_get_thc_hidi2c_info` and `soc_get_thc_hidspi_info`, which should
be defined in the SoC's `chip.c` file. Device-specific configurations
are provided by the driver for supported devices. For unsupported or
generic devices, the required information is expected to be provided
via the device tree. MB-specific information, such as LTR (Latency
Tolerance Reporting) values and speed, must be provided in the device
tree.
BUG=none
TEST=Configure the DRIVERS_INTEL_TOUCH option on a motherboard that has
the necessary touch configurations. Verify that the THC ACPI tables are
correctly generated in the SSDT.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Ibcd2a75a41460dee67aebdc61ee9e85fa98b71bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85198
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop duplicate/unused `mclk` field, which corrects the size of the SSDB
struct to 108 bytes. Size/fields confirmed by comparing to DSDT
dumps of UEFI firmware and SSDB struct in linux MIPI driver (ref:
/include/media/ipu-bridge.h).
Change-Id: Iea5b2138d2396e32bcecb3a48ab2b159a9b33345
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add more platform type values. Values sourced from Slimbootloader and
various DSDT dumps on github.
Change-Id: If7ea46aad76dfedf89f764e60d9bf6061f53cbe1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86794
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves the debug print which prints the mapping between CPU
Type-C port and EC Type-C port from SoC code to generic driver code.
BUG=b:399032094
TEST=Check the Type-C port and EC port mapping in coreboot log
Change-Id: Iaef5813cc825569a53feba975258f7d5fadecfab
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86704
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds the parameter which allows for custom port mapping
between CPU Type-C port and EC Type-C port to accommodate the
non-sequential mapping. Mainboard code must configure this parameter
if the CPU Type-C port to EC Type-C port mapping is not sequential.
BUG=b:399032094
TEST=build and verify TCSS port and EC port mapping
Change-Id: Id92f942e5c6b27342777b3e6fd12aff264ccec1b
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch refactors low-battery user notification logic (Kconfig,
APIs to check if low-battery rendering is required, low-battery
shutdown is required) outside FSP driver code to ensure in future
non-FSP platforms might still be able to leverage this feature/logics
to render the low-battery indicator icon during boot.
Specifically, it:
- Moves Kconfig options related to low-battery notifications from
drivers/intel/fsp to lib/
- Relocates the low-battery check and shutdown APIs drivers/intel/fsp
to bootsplash.h
* Adjusts the vendor driver to utilize the new APIs for low-battery
rendering decisions.
* Drop the unwanted header file "fsp/api.h" from bmp_logo.c
This change avoids tight coupling of low-battery functionality to FSP,
promoting code reusability across platforms.
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: Iaa730dac2bb4866183408b6390221f0bb8411a48
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit relocates the BMP_LOGO related Kconfig options from the
FSP1.1 and FSP2.0 drivers to the common library (lib/).
This change:
- Centralizes the BMP_LOGO configuration, making it accessible to
all drivers and platforms.
- Removes duplicate Kconfig entries from the FSP drivers.
- Prepares for future refactoring where BMP_LOGO will be handled
entirely within the library, enabling its use by both FSP and
non-FSP platforms.
The following Kconfig options are moved under "Boot Logo Configuration"
menu option:
- `BMP_LOGO`
- `BMP_LOGO_COMPRESS_LZMA`
- `BMP_LOGO_COMPRESS_LZ4`
- `BMP_LOGO_FILE_NAME`
- `HAVE_BMP_LOGO_COMPRESS_LZMA`
- `HAVE_CUSTOM_BMP_LOGO`
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: I9bbfade9b919cfbd0b689a67c988ed8c65deb597
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86730
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit standardizes the Kconfig option for the boot logo file name
across FSP drivers and the common library.
The `FSP1_1_LOGO_FILE_NAME` and `FSP2_0_LOGO_FILE_NAME` options are
renamed to `BMP_LOGO_FILE_NAME`.
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: I6a6c2c6d235ad9643879b00232930c8a0d2e3801
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This change eliminates the HAVE_FSP_LOGO_SUPPORT Kconfig option.
It was initially used to control BMP_LOGO selection within the FSP2.0
driver. However, upcoming refactoring will move BMP_LOGO and its
implementation to the `lib` directory therefore, BMP_LOGO can be
used by both FSP and non-FSP SoC platforms.
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: I899bbfcf7e747abe69ff0866c4594a42278891b9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86719
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
This commit introduces an early low-battery shutdown mechanism during
FSP memory initialization. This is particularly important during
firmware updates, where memory training can consume significant power
and lead to abrupt shutdowns, potentially corrupting the firmware.
The changes include:
- Adding platform_display_early_shutdown_notification() to notify the
user of the impending shutdown.
- Checking platform_is_low_battery_shutdown_needed() to determine if a
shutdown is necessary.
- Implementing a shutdown sequence if low battery is detected during
memory init, especially when no MRC cache is found (i.e. firmware
update).
- Deferring shutdown on systems without MAINBOARD_HAS_EARLY_LIBGFXINIT
so that FSP-M (uGOP) can display a message.
This prevents firmware update corruption due to low battery.
BUG=b:339673254
TEST=Verified low battery boot event logging and controlled shutdown.
Change-Id: Ia135b238d1e16722c2ca8d3b461e83b4ce513adf
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86452
Reviewed-by: Jayvik Desai <jayvik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit adds the `platform_is_low_battery_shutdown_needed` callback
to the FSP API. This allows platforms to integrate low-battery handling
logic directly into the FSP silicon initialization process. By checking
for critical conditions (e.g., low battery) within this callback after
FSP silicon initialization, the platform can initiate a controlled
shutdown before proceeding with further boot stages, preventing abrupt
shutdowns later in the boot process.
BUG=b:339673254
TEST=Able to build and boot google/brox.
Change-Id: I2d6677d70dea3d24f5a19d70608fd21229a271a0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86226
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This commit adds low battery indicator bitmap into CBFS. This screen
is displayed when the system detects a critically low battery condition.
The screen displays a logo and can be configured with a custom path.
An option to display an early low battery indicator in text mode is also
included. This early indicator can defer the firmware update.
This feature is controlled by the PLATFORM_HAS_LOW_BATTERY_INDICATOR
Kconfig option.
BUG=b:339673254
TEST=Able to see low-battery user notification in text mode before
memory init. Verified low-battery boot event listed in the eventlog.
Change-Id: I711c53455639b449fe85903139bbc06cdab08d09
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This commit moves the logo.bmp inclusion logic from
`src/drivers/intel/fsp2_0/Makefile.mk` to `src/lib/Makefile.mk`.
This change centralizes the logo inclusion logic within the `lib`
directory, aligning it with the location of `bmp_logo.c` and making
it independent of the FSP 2.0 driver.
Change-Id: I16ed1cf29b839c25b6ea1c2f10faf3d99dd707c9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Implement vbt_get() on AMD and return the VBIOS location. This allows
to drop the hardcoded addresses used in various places and return an
address in DRAM that is reserved for FSP use.
TEST: amd/birman+ still gets passed the correct VBIOS address.
Change-Id: I92d76fc4df88fbce792b9d7c912c6799617704a0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86299
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
MAILBOXES_DESKTOP is unused, and the IGD opregion spec makes no
distinction in the mailboxes supported between desktop and mobile
platforms. Rename MAILBOXES_MOBILE to IGD_MAILBOXES for consistency
with other mailbox variables and clean up the comment.
Change-Id: Ia06fe75702887aa6953bf17bd4bc14af4038bec5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86279
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
IGD mailbox #2, Software SCI Interface, is not supported by coreboot
currently, as it requires supporting the Get BIOS Data (GBDA) and
System BIOS Callbacks (SBCB) interfaces. Since coreboot doesn't
support these, don't advertise mailbox #2 support.
This eliminates an error with the Linux display drivers:
"SWSCI request timed out"
TEST=build/boot Linux 6.9, Win11 on starlabs/starlite_adl
Change-Id: I8efcf9c5d384b6e0ce159d65cb1497c2e2e47f42
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86276
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Intel's reference implementation in Slimbootloader pads the area
allocated for the extended VBT to the nearest 512-byte boundary, which
strongly suggests that the Windows driver expects the same.
TEST=build/boot Linux 6.9, Win11 on starlabs/starlite_adl, verify
VBT read properly by OS.
Change-Id: Ib3784eea6eb929ffec9672fc123b833c11c057e8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86275
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit relies on newly added Kconfig option,
USE_CBFS_FILE_OPTION_BACKEND, which allows controlling the FSP debug
log level using CBFS options (RAW binary files).
The default log-level is setup in coreboot while stitching the CBFS
option binaries depending upon the coreboot log-level.
Following files will be used to determine the log levels:
- fsp_pcd_debug_level: For the overall FSP debug log level.
- fsp_mrc_debug_level: For the MRC (Memory Reference Code) debug log
level.
In absense of these files, the FSP console log-level is determine by
calling into fsp_map_console_log_level API.
The values in these files should correspond to the FSP_LOG_LEVEL_* enum
values.
This change allows for more flexibility in controlling the FSP debug log
level, especially in cases of debugging silicon firmware issues with a
debug AP FW binary.
This capability is particularly useful when debugging issues that
require examining both silicon and MRC logs simultaneously.
BUG=b:227151510
TEST=Able to control the FSP debug log based on CBFS options
To inject the fsp_pcd_debug_level and fsp_mrc_debug_level CBFS files
with the desired log level, run:
```
cbfstool image-fatcat.serial.bin add-int -i 5 -n option/fsp_pcd_debug_level
cbfstool image-fatcat.serial.bin add-int -i 5 -n option/fsp_mrc_debug_level
```
With both fsp_pcd_debug_level and fsp_mrc_debug_level present in the RO
CBFS, both the silicon firmware and MRC behave as debug binaries.
To verify the presence of both log-level RAW CBFS binaries in the CBFS RO
slot, run:
```
sudo cbfstool fatcat/image-rex0.serial.bin print | grep fsp_
```
This should output:
```
option/fsp_mrc_debug_level 0x88e40 raw 8 none
option/fsp_pcd_debug_level 0x2a7400 raw 8 none
```
Change-Id: I2c14d26021dd0048fa24024119df857e216f18bd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86001
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This resolves a crash issue observed on Meteor Lake and introduced by
commit 70bdd2e1fa ("cpu/x86/topology:
Simplify CPU topology initialization"). This commit simplifies the
code and provides more detailed CPU topology information by
generalizing the use of the Extended Topology Enumeration Leaves
0x1f. As a result, the coreboot APIC core_id field does not provide
the fully detailed path information.
It turns out that the topology core identifier is used by the coreboot
MP service mp_get_processor_info() implementation. But the MP Service
EFI_CPU_PHYSICAL_LOCATION data structure only captures information
about the package, core, and thread. The core identifier returned to
the MP service caller must incorporate the full hierarchical path (die
group, die, module, tile, module and core).
This commit adds a new field to the cpu topology structure to
represent the core ID within the package.
For reference, here is that signature of the crash:
LAPIC 0x40 in X2APIC mode.
CPU Index 2 - APIC 64 Unexpected Exception:13 @ 10:69f3d1e4 - Halting
Code: 0 eflags: 00010046 cr2: 00000000
eax: 00000001 ebx: 69f313e8 ecx: 0000004e edx: 00000000
edi: 69f38018 esi: 00000029 ebp: 69aeee0c esp: 69aeedc0
[...]
The crash occurred when FSP attempted to lock the Protected
Processor Inventory Number Enable Control MSR (IA32_PPIN_CTL
0x4e).
69f3d1d3: 8b 43 f4 mov -0xc(%ebx),%eax
69f3d1d6: 89 4d c4 mov %ecx,-0x3c(%ebp)
69f3d1d9: 89 45 dc mov %eax,-0x24(%ebp)
69f3d1dc: 8b 55 c4 mov -0x3c(%ebp),%edx
69f3d1df: 8b 45 c0 mov -0x40(%ebp),%eax
69f3d1e2: 8b 4d dc mov -0x24(%ebp),%ecx
69f3d1e5: 0f 30 wrmsr
69f3d1e7: e9 ee fd ff ff jmp 0xfffffe39
FSP experiences issues due to attempting to lock the same register
multiple times for a single core. This is caused by an inconsistency
in the processor information data structure, where multiple cores
share the same identifier. This is not permitted and triggers a
General Protection Fault Exception.
TEST=Executing CpuFeaturesPei.efi in FSP-S does not crash on a rex
board.
Change-Id: I06db580cddaeaf5c452fa72f131d37d10dbc5974
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86004
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
As suggested by the linter:
Prefer 'unsigned long' over 'unsigned long int' as the int is unnecessary
Link: https://qa.coreboot.org/job/coreboot-untested-files/lastSuccessfulBuild/artifact/lint.txt
Huang Jin <huang.jin@intel.com>
Intel_Coreboot_Reviewers <intel_coreboot_reviewers@intel.com>
Change-Id: I940528dc4f8cb9b2d441d0f0d181cccebd315255
Signed-off-by: Ariel Otilibili <otilibil@eurecom.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Add a null check around the usage of the RFWU (Retimer Firmware
Update path) in the `usb4_retimer_execute_ec_cmd` function. This
ensures that any interaction with RFWU is only performed when the
path is valid, preventing potential null pointer dereferences.
This fixes are large amount of errors when `ec_retimer_fw_update_path`
isn't declared, such as comparisons like `If ((Local0 == Break))`.
Change-Id: I5a219345440f91332f680885b51e2cc09f14f7a7
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Match function name "init" with "remove" by renaming all
*_breakpoint_disable() to *_breakpoint_remove().
Change-Id: Id3da25cfa6fc0594887f3112e269e57e8ecb32b3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85540
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to debug stack smashing add a write breakpoint to the
stack canary (at _stack or _car_stack) and print the IP when the
stack canary is written.
TEST: Wrote to address _stack in ramstage and got the EIP of the
code that smashed the stack canary.
Change-Id: I8adf07a8425856795a4a71da5c41bec2244b02a8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84833
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Limit the ACPI OpRegion to cover only MBOX3. This seems to fix
BSOD errors seen on Windows 10/11 as reported at [1].
1: https://ticket.coreboot.org/issues/327
Change-Id: Ia2affa799e5cd84c0a03330e0f78919755f0e8ac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81295
Reviewed-by: Joel Linn <jl_coreboot@conductive.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This to fix the error when using C23:
cannot cast an object of type 'nullptr_t' to 'uintptr_t' (aka 'unsigned long')
return (uintptr_t)NULL;
^
Change-Id: Ibdc8794513a508fc61a5046692f854183c36b781
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
This change removes the SoC-specific `FSP_STATUS_GLOBAL_RESET_REQUIRED_X`
Kconfigs, as they are no longer necessary for handling FSP global reset
requests.
Previously, these Kconfigs were used to select a specific 32-bit reset
status code. However, with the introduction of FSP 2.4 and 64-bit
interfaces, the global reset status code can now vary between
architectures.
To address this, the FSP driver now sets the `FSP_STATUS_GLOBAL_RESET`
config to a common default value (depending upon most commonly used
global reset status code) based on the interface:
- 0x40000003 for 32-bit FSP interfaces
- 0x4000000000000003 for 64-bit FSP interfaces
This default can be overridden if an FSP implementation uses a
different status code (for example: Apollo Lake selects different FSP
reset status code as 0x40000005).
By removing the SoC-specific configurations, this change simplifies
global reset handling and ensures compatibility across different FSP
versions and platforms.
Below table shows the relationship between Platform, FSP and FSP Global
Reset Status:
+-----------------+--------------+-------------------------+
| Platform | FSP | Global Reset Status |
+-----------------+--------------+-------------------------+
| Alder Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Apollo Lake | 32-bit | 0x40000005 |
+-----------------+--------------+-------------------------+
| Cannon Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Elkhart Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Jasper Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Meteor Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Sky Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Tiger Lake | 32-bit | 0x40000003 |
+-----------------+--------------+-------------------------+
| Panther Lake | 64-bit | 0x4000000000000003 |
+-----------------+--------------+-------------------------+
BUG=b:347669091
TEST=Verified FSP requested global reset functionality on google/rex0
(32-bit) and google/rex64 (64-bit) platforms.
w/ 32-bit FSP:
```
(Wdt) AllowKnownReset
[FspResetSystem2] FSP Reset Initiated
FSP returning control to Bootloader with reset required return status
40000003
FSPS, status=0x40000003
FSP: handling reset type, status=0x40000003
GLOBAL RESET!
global_reset() called!
HECI: Global Reset(Type:1) Command
```
w/ 64-bit FSP:
```
(Wdt) AllowKnownReset
[FspResetSystem2] FSP Reset Initiated
FSP returning control to Bootloader with reset required return status 3
FSPS, status=0x4000000000000003
FSP: handling reset type, status=0x4000000000000003
GLOBAL RESET!
global_reset() called!
HECI: Global Reset(Type:1) Command
```
Change-Id: I32bdbf7ea6afa7d5e5f91ea96d887719d26a593f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84572
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
This allows to configure a default screen rotation in 90-degree
steps. The framebuffer contents will then be displayed rotated,
by the same amount in the other direction; i.e. if you turn the
screen to the left, the picture has to be rotated to the right
to accommodate.
This is only supported by libgfxinit from Skylake / Apollo Lake
on (earlier GPUs didn't support the 90-degree steps anyway) and
it only works with the linear-framebuffer option.
Change-Id: Iac75cefbd34f28c55ec20ee152fe67351cc48653
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This commit introduces a new config DRIVER_INTEL_ISH_HAS_MAIN_FW to
indicate that the Intel Sensor Hub (ISH) is using the ISH MAIN firmware.
The ISH MAIN firmware is located in rootfs, hence we no longer need to
store the ISH BUP version in the CSE partition.
When this config is enabled, fetching the ISH BUP version from the CSE
firmware partition is skipped.
BUG=b:360144613
TEST=Local build successful and tested on trulo by toggling the
config. Enabling this config skips printing the ISH version in cbmem.
Change-Id: I6cacf7b44ce6895ecb96db295d184c7b7d5a872c
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84493
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Move the `BUILDING_WITH_DEBUG_FSP` Kconfig option from SoC-specific
files to the FSP2_0 driver Kconfig to avoid duplication. Also slightly
improves the option's prompt and help text.
TEST=Built and booted google/rex successfully.
Change-Id: I5c3dce59c396f6c1665a3ed1b8c1bb5df0f5a8d4
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch adds a new Kconfig option `FSP_PUBLISH_MBP_HOB` to
control the creation of the ME_BIOS_PAYLOAD_HOB (MBP HOB) by FSP.
Disabling this option can improve boot time on platforms that
do not utilize the MBP HOB, such as ChromeOS devices.
The option is disabled by default on ChromeOS and enabled
by default on other platforms.
On ADL-P based platforms, this option is forced to be enabled
as ADL-P FSP relies on MBP HOB for ChipsetInit version for
ChipsetInit sync.
Removed SoC specific implementation of `FSP_PUBLISH_MBP_HOB` config
from MTL and TGL config file.
TEST=Tested on ADL-P and ADL-N platforms. Verified that MBP HOB is
created when `FSP_PUBLISH_MBP_HOB` is enabled and not created when
it is disabled.
Also verified that the system boots successfully in both cases.
Change-Id: I21da00259c0b9bcca6f545291a6259e9cce8d900
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84217
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch introduces a new configuration option,
FSP_UGOP_EARLY_SIGN_OF_LIFE, to the FSP driver. This enables uGOP
support using FSP-M for the early sign-of-life feature in SOC.
BUG=NA
TEST=Able to build google/rex and checked the config in output.
Change-Id: Ic0426ff7974a141ae9188b0098677b4cc97aee36
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
We introduce two new functions to create region objects. They allow us
to check for integer overflows (region_create_untrusted()) or assert
their absence (region_create()).
This fixes potential overflows in region_overlap() checks in SMI
handlers, where we would wrongfully report MMIO as *not* overlapping
SMRAM.
Also, two cases of strtol() in parse_region() (cbfstool), where the
results were implicitly converted to `size_t`, are replaced with the
unsigned strtoul().
FIT payload support is left out, as it doesn't use the region API
(only the struct).
Change-Id: I4ae3e6274c981c9ab4fb1263c2a72fa68ef1c32b
Ticket: https://ticket.coreboot.org/issues/522
Found-by: Vadim Zaliva <lord@digamma.ai>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
