Drop the custom function to set the value of a single GPIO and
use the generic function prototype defined in include/gpio.h instead.
Migrate all users of the old function to the new function.
Allows to share more code between older x86 Intel boards and newer
x86 Intel boards since they now use a common header.
Change-Id: I8c83b3436818275958cd8eb8b1c0d7b235e0344c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88504
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the custom function to set the value of a single GPIO and
use the generic function prototype defined in include/gpio.h instead.
Migrate all users of the old function to the new function.
Allows to share more code between older x86 Intel boards and newer
x86 Intel boards since they now use a common header.
Change-Id: I714eaf2115a455d327e6b2313dafd0e293bee8a7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Include the missing header stdbool.h
Fixes compilation error
hybrid_graphics.h:6:28: error: unknown type name 'bool'
while refactoring some code.
Change-Id: I96f7255049cd9e24d74838a173e920a00636b09e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88546
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the BMP rendering logic, moving it from
drivers/intel/fsp2_0 to src/lib. This centralizes the code
responsible for rendering BMP images to the framebuffer.
Key changes:
- Move BMP rendering functions (e.g., calculate_logo_coordinates,
copy_logo_to_framebuffer) and their dependencies to
src/lib/render_bmp.c and src/lib/render_bmp.h.
- Decouple BMP definitions from UEFI headers by introducing new
coreboot-specific structures for BMP images and BLT pixels.
- Consolidate bootsplash-related declarations into bootsplash.h,
including new `fw_splash_vertical_alignment`,
`fw_splash_horizontal_alignment`, and `struct logo_config`.
- Update `soc_load_logo_by_coreboot` to use the new common
`load_and_render_logo_to_framebuffer` function and `struct
logo_config` for rendering.
- Relocate `release_logo` to `src/lib/render_bmp.c` for better
module structure.
- Update `src/lib/Makefile.mk` to include the new render_bmp.c.
This refactoring improves code organization and reusability, making
BMP rendering accessible without tight coupling to Intel-specific
driver code.
BUG=b:427387842
TEST=Verify firmware splash screen on google/fatcat.
Change-Id: I0e20ea7e44b4b3ccdb2d4aa9b6aa10ed3447ccfc
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88361
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current style is not part of the coding style [1]. The comment has
five lines, so it’s unclear if the short or long multi-line comment
style should be used. Use the short one, to keep it concise.
[1]: Documentation/contributing/coding_style.md
Change-Id: I500340fd02a54c69db4ca5d753fcb690fae1c520
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88491
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Bochs display driver uses port I/O functions to initialize the VGA
device, so it could only have been built on x86 architectures so far,
but its supported devices can be used just fine on others on the QEMU
side as long as the emulated platform supports PCI. A previous commit
adds port I/O functions for more including ARM* and RISC-V, which should
enable this driver to be successfully built and used on these as well.
Allow the Bochs display driver to be built for non-x86 QEMU boards by
changing the Kconfig dependencies. Make VGA text framebuffer support
depend on x86, because it isn't usable at the standard 0xB8000 address
on other architectures. Add a dependency on PCI since this is a PCI
device and vexpress-a9 (qemu-armv7) doesn't have the (emulated) hardware
for PCI.
Change-Id: I7f72d7ea13e54ecf89d067394c02b572c5f92d24
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Due to a flaw in the hardware design, the GL9763e replay timer
frequently times out when ASPM is enabled. As a result, the warning
messages will often appear in the system log when the system accesses
the GL9763e PCI config. Therefore, the replay timer timeout must be
masked.
BUG=b:428025481
Sample output on screen:
PCIe Bus Error: severity=Corrected, type=Data Link Layer
device [17a0:e763] error status/mask=00001000/00002000
[12] Timeout
Change-Id: I6f921f40f169d7811b7bd51145023b549e8aee1c
Signed-off-by: Victor Shih <victorshihgli@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88291
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This documents that if the fw_cfg table was improperly configured by
QEMU, the fw_cfg_smbios_init() function would leak memory. We could
add a check to verify that this doesn't happen, but honestly that seems
like overkill. This just documents the issue in case this code is
copied for use elsewhere.
BUG=CIDs 1405799, 1405791, 1405792, 1405796, 1405797
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4f253194dae52897633ab5d96bb8c2964b8365d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
In order to support runtime evaluation of the TPM base address
introduce and use a new method for CRB TPMs.
Change-Id: I29c81d82947eb2603472a515f9ada598e4f8e6ea
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Adds a new flags field to the lb_spi_flash coreboot table to indicate
if the SPI flash is operating in 4-byte address mode.
This allows payloads to query the current address mode directly from the
coreboot table, preventing redundant checks or re-enforcement of the
mode. The flag is set based on the
CONFIG_SPI_FLASH_FORCE_4_BYTE_ADDR_MODE configuration.
Important: `erase_cmd` was reduced from uint32_t to uint8_t.
Only the least significant byte was ever relevant, so this change
ensures accurate type representation, maintains backward compatibility
with existing coreboot table structures, and frees up space.
BUG=b:417900125
TEST=Able to build google/bluey.
Change-Id: I406536432b2a0c7f4108e5b33d5a20c272d917b0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This commit refactors the logic for entering and exiting 4-byte
addressing mode in the SPI flash driver.
Changes include:
- Renaming SPI_FLASH_EXIT_4BYTE_STAGE to SPI_FIRST_STAGE to better
reflect its broader applicability to initial boot stages.
- Applying SPI_FIRST_STAGE to both the force 4-byte address mode
and exit 4-byte address mode configurations, ensuring these
operations are only attempted during the appropriate early boot
phases.
- Renaming CMD_FORCE_4BYTE_ADDR_MODE to CMD_ENTER_4BYTE_ADDR_MODE for
consistency and clearer semantics, as 0xb7 is typically used to enter
this mode.
BUG=b:417900125
TEST=Able to build google/bluey.
Change-Id: I79e2c7bbd222fd0d76072860bdf3feba7e7d587d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Introduces logo_bottom_margin to soc_intel_common_config to allow
adjusting the vertical (or horizontal, based on orientation) offset of
the footer logo from the screen edge. This provides flexibility for
OEM branding placement.
BUG=b:423591644
TEST=Able to show OEM splash screen on google/fatcat.
Change-Id: Ie3942d9eee07091286118ac488d1cc85ecc96c4c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Many high-capacity SPI flashes (e.g., >16MB) default to 3-byte
addressing and require a specific command to enter 4-byte address mode.
This commit introduces support for sending the
CMD_FORCE_4BYTE_ADDR_MODE (0xB7) command during flash probing. When
Kconfig option `SPI_FLASH_FORCE_4_BYTE_ADDR_MODE` is enabled, this
ensures the flash chip is immediately switched to 4-byte addressing
after power-on.
This addresses issues with flashes like GigaDevice (GD25LQ128D) and
Winbond (W25Q256JWxx) that mandate this command for proper 4-byte
addressing. The new command definition is in `spi_flash_internal.h`.
BUG=b:417900125
TEST=Able to build google/bluey.
Change-Id: I935a0e1d6214d73c8ea487418adc93f016790432
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88156
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit refactors the `soc_load_logo_by_coreboot()` function by
extracting common logo rendering logic into a new helper function:
`render_logo_to_framebuffer()`.
The `render_logo_to_framebuffer()` helper is responsible for:
- Loading the BMP image (by type).
- Checking the image size.
- Converting the BMP to GOP BLT format.
- Calculating the appropriate logo coordinates based on vertical
or horizontal alignment, considering panel orientation for the
footer logo.
- Copying the logo data to the framebuffer.
- Releasing the allocated logo buffer.
This refactoring significantly reduces code duplication within
`soc_load_logo_by_coreboot()`, making it more concise and readable.
It also centralizes the logo rendering process, improving
maintainability and simplifying future modifications.
The `soc_load_logo_by_coreboot()` function now focuses on
higher-level orchestration: graphics info initialization, MTRR
setup, panel orientation adjustment, and sequential calls to
`render_logo_to_framebuffer()` for the main and optional footer logos.
Error handling for MTRR and logo rendering failures is streamlined
with a `cleanup` goto label.
BUG=b:423591644
TEST=Able to show OEM splash screen on google/fatcat at center of the
screen.
Change-Id: I10f84fd1c2081efcf787d00ab7cfc6bb24feca21
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88032
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds horizontal alignment support for splash screen
logos into the existing helper function `calculate_logo_coordinates()`.
Updated helper function determines the X-coordinate for
logo placement based on specified horizontal alignment (left, right,
or center).
The `soc_load_logo_by_coreboot()` function is updated to utilize this
helper for footer logo placement when the panel orientation is
rotated (`LB_FB_ORIENTATION_RIGHT_UP`, `LB_FB_ORIENTATION_LEFT_UP`,
or `LB_FB_ORIENTATION_BOTTOM_UP`).
A new enum, `fw_splash_horizontal_alignment`, is defined in
`intelblocks/cfg.h` to explicitly represent these horizontal alignment
options, complete with descriptive comments and ASCII art.
This enhancement provides greater flexibility in positioning splash
screen elements, especially useful for rotated displays (for the footer
firmware splash screen).
BUG=b:423591644
TEST=Able to rotate the firmware splash screen (including footer logo)
while using portrait panel.
Change-Id: I23ae6d06e1df9cad1b2907a5c02b619dc831d468
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88030
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch modifies the low-battery shutdown logic to bail out early
when the system is in a low-power state. This prevents the display of
the OEM footer logo, ensuring power conservation and avoiding
unnecessary rendering alongside the low-battery icon.
BUG=b:423591644
TEST=Boot platform with `CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`
and low battery. Verify splash appears before shutdown w/o OEM
footer logo.
Change-Id: Ie9a23c0fe9d6b7d314cf4bbe8a8a90eb5689568e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit introduces the `SPLASH_SCREEN_FOOTER` Kconfig option,
enabling a custom footer image or logo on the firmware splash screen.
This provides an additional branding opportunity for device
manufacturers.
`soc_load_logo_by_coreboot()` now conditionally loads and renders
`footer_logo.bmp` when this option is enabled. The footer logo is
positioned at the bottom of the screen.
A new `SPLASH_SCREEN_FOOTER_LOGO_PATH` Kconfig option is added to
define the footer logo's file path. It defaults to a mainboard-specific
location. `Makefile.mk` is updated to ensure this logo is included in
the CBFS.
This additional branding is made possible by rendering bitmaps using
coreboot's native implementation (`USE_COREBOOT_FOR_BMP_RENDERING`).
FSP currently lacks the necessary callbacks to support this feature.
Currently, the OEM footer branding will appear even when the
system is booting in low-battery mode. A planned update will fix this
by exiting early from the boot process, preventing the footer from
showing and conserving power.
BUG=b:423591644
TEST=Able to display custom footer logo on boot.
Change-Id: I57f8af910e8b8f56e8a4a88f8cca6d60fad380b6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit refactors the bitmap handling in the FSP2.0 driver to
enhance flexibility. Previously, `fsp_convert_bmp_to_gop_blt()`
directly called `bmp_load_logo()`, tying it to specific, predefined
bitmaps like low-battery or OEM splash logos. This prevented its
use for dynamic bitmap files (e.g., brand logos) at runtime.
To address this, `fsp_convert_bmp_to_gop_blt()` no longer handles
bitmap loading. Instead, a new unified API,
`fsp_load_and_convert_bmp_to_gop_blt()`, is introduced for scenarios
where FSP needs to load and convert a bitmap in a single step
(e.g., via its entrypoint).
This change makes `fsp_convert_bmp_to_gop_blt()` a generic API capable
of converting any provided bitmap into a BLT buffer. SoC layers
(like Alder Lake, Meteor Lake, Panther Lake) can now explicitly load
bitmaps and then pass them to `fsp_convert_bmp_to_gop_blt()`, or use
the new `fsp_load_and_convert_bmp_to_gop_blt()` for combined
operations.
Before:
- `soc_load_logo_by_coreboot()` -> `fsp_convert_bmp_to_gop_blt()`
(loads logo internally)
- `soc_load_logo_by_fsp()` -> `fsp_convert_bmp_to_gop_blt()`
(loads logo internally)
**After:**
- `soc_load_logo_by_coreboot()` -> loads logo
-> `fsp_convert_bmp_to_gop_blt()`
- `soc_load_logo_by_fsp()` -> `fsp_load_and_convert_bmp_to_gop_blt()`
BUG=b:423591644
TEST=Able to build and boot google/fatcat. FW splash screen looks
proper.
Change-Id: Ia20e8d42bca6f40c4eb652eb69e3fce84409fc35
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88014
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This case doesn't reflect an error condition, so adjust the printk
level accordingly.
Change-Id: I3afa818447d3e7c9d08968ffc6b57a663af45c3e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88011
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The generic device attached to this driver doesn't have resources
separate from the parent device to which it's attached, so
use 'noop_read_resources' to suppress a false-positive error in
the cbmem console log (GENERIC: 0.0 missing read_resources).
Change-Id: I985318dcc7cc32aaa3f6a599ade95e065900031e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88012
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Anx7625 reads EDID through AUX channel with I2C Over Aux operation,
reading 16-byte chunk a time. Sometimes, panel(CSOT MNB601LS1-3)
does not returns EDID raw data in time or returns OK without providing
data.
Root cause:
The measured difference between two adjacent UI signals of the AUX
signal is 36ns (518 - 482ns), it meets the VESA DP1.2/1.3 spec < 0.08UI
(48ns) requirement. However, this value exceeds the VESA DP1.1a spec
supported by the panel: max < 0.04UI (24ns) requirement, which exceeds
the tolerance value of the panel and leads to EDID communication
failure.
To address this issue, determined by tests, so that the issue did not
reproduce in over 200 tests
Test result:
Verified on 12pcs panels(8pcs issue panels, 4pcs new panels), 10pcs
tested 300 cycles, 2pcs tested 400 cycles, issue cannot be reproduced.
BUG=b:415946451
TEST=Tested on corsola over 200 times
BRANCH=corsola
Change-Id: I2d4f6b65b8f663ea9b9459e0343897a1223d631a
Signed-off-by: Xin Ji <xji@analogix.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Use POSTPONE_SPI_ACCESS to handle elog data later boot phase to avoid
flash access delay by other boot controllers.
Intel has pre-CPU boot controllers (e.g. CSE) which load non-CPU
firmwares. Boot-critical firmwares are loaded before CPU reset and
non-boot-critical firmwares are loaded during CPU boot. If another
controller accesses SPI to load firmwares, reading SPI by CPU is ok,
but writing to SPI for saving elog data can take ~32ms sometimes.
Saving elog data usually takes less than 1ms.
There are three elog handling sequences that need to move together
under the Kconfig:
- Soc folder
- Elog driver folder
- ChromeOS folder
Before this change, sometimes it delays like below:
BS: callback (0x7386d428) @ src/soc/intel/pantherlake/elog.c:216 (32 ms)
After this change, the delay is less than 1 ms:
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms)
TEST
1. Enable DEBUG_BOOT_STATE
2. Check time
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms))
Change-Id: I3f5e7acf5204e213179664d0d77151d415d00896
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87740
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
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>
I am using a pair of Winbond W25Q64JVSSIM SPI flash chips for
coreboot development. While working on Asus P8x7x Series
autonomous soft strap update support, aka CB:85413 and CB:87334,
I found that without its signature (mfgr 0xef, dev 0x7017) added,
rdev_writeat() would fail to get anything into the flash chip
even though it reports success. Its other parameters are copied
from W25Q64_V as the two are almost the same.
Change-Id: I4af6268a2a1bde4d2ff9c76879c3bc59b91a916d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
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>
MRC cache used to be measured as runtime data when it was resided in
CBFS before commit 82aa8338c7 ("drivers/mrc_cache: Always generate an
FMAP region"). This patch will restore this behavior for MRC cache
stored in FMAP region outside of CBFS.
Now, MRC cache will be measured at the end of
mrc_cache_load_current(), mrc_cache_current_mmap_leak() and
update_mrc_cache_by_type(), to guarantee that a tamper with the memory
(like https://badram.eu/ ) will be detected, controlled by Kconfig
option TPM_MEASURE_MRC_CACHE.
TEST=On Ivy Bridge platforms, Empty MRC cache is not measured.
Changing DIMM causes both the old cache and new cache being
measured, thus the runtime data measurement is changed, which
could be used as an alarm for memory tampering. Starting from the
second boot after changing DIMM, the runtime data measurement
becomes stable.
Signed-off-by: Ivan Kuzneczov <ivan.kuzneczov@hardenedvault.net>
Change-Id: I0d82642c24de1b317851d0afd44985195e92c104
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
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>
Currently the SMMSTOREv2 only supports MMIO ROM below 4GiB. As the
space below 4GiB is typically limited on x86, add support for extended
MMIO ROM windows as found on recent hardware.
Allow the SMMSTOREv2 to be memory mapped above 4GiB by adding a new
field to the coreboot table called 'mmap_addr'. The users outside
of coreboot must check the size field of the coreboot struct to
determine if mmap_addr is supported. When it is it holds the
64-bit physical address to the MMIO ROM window.
The old 'mmap_addr' was renamed to 'mmap_addr_deprecated' to indicate
that it should not be used any more.
Change-Id: I1131cfa5cdbf92bbd33de3e5b22a305136eec9f7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87114
Reviewed-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
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 makes Bluetooth RTD3 runtime configurable.
Change-Id: I467634e013a140e0a39802d2a1767583ba33a76e
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
On mainboard/asus/p8z77-v_le_plus, programmed MAC address is being
reverted with controller resets done at loading and unloading of Linux
r8169 kernel module.
Ghidra examination of vendor BIOS reveals an additional sequence to
program the MAC address into its ERI register block. This patch
adds code to replicate that sequence, gated by a Kconfig so it's
only included where necessary.
BUG=https://ticket.coreboot.org/issues/579
TEST=When applied with mainboard level changes in CB:87437, specified
MAC address now recognized and retained by Linux r8169 driver without
further work.
Change-Id: Iae33e24e564f9fba52acb16138fe89085d9eeb03
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87436
Reviewed-by: Matt DeVillier <matt.devillier@gmail.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>
Since CFR options require a backend to store the keys/values, select
DRIVERS_EFI_VARIABLE_STORE when edk2 is used as the payload and
SMMSTORE is enabled, so that boards only need to select
DRIVERS_OPTION_CFR in order to have a fully-functioning configuration
setup.
TEST=build samsung/stumpy with DRIVERS_OPTION_CFR selected and edk2
payload used.
Change-Id: Ib8565e4fefb1b3f05e58ab039be8ab0d1bc046f1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
DRIVERS_EFI_FW_INFO requires some Intel vendorcode headers which are
selected by default on FSP 2.x platforms, but not by earlier ones.
Select the oldest UDK binding for non-FSP 2.x boards, so that the
required headers are available, rather than depending on UDK_BASE
and requiring those boards to manually select the binding
Change-Id: I27ab64ab0c9d4d45cc09061f6f8c3725c24df706
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
DRIVERS_EFI_VARIABLE_STORE requires some Intel vendorcode headers which
are selected by default on FSP 2.x platforms, but not by earlier ones.
Select the oldest UDK binding for non-FSP 2.x boards, so that the
required headers are available, rather than depending on UDK_BASE
and requiring those boards to manually select the binding.
TEST=build samsung/stumpy with EFI variable store support, without
manually selecting UDK_2017_BINDING at the mainboard level.
Change-Id: I099d3cc7690a0faecfe32a8bc814766c67c63fbb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87408
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With DRIVERS_EFI_UPDATE_CAPSULES enabled and when at least one capsule
was found, SMMSTORE SMI handler can use commands with the highest
bit (0x80) set to access the whole flash instead of just the SMMSTORE
region. The rest of the interface is identical to regular SMMSTORE v2
except for a new call to control full flash access.
The added call saves information about the availability of capsules in
SMM memory. The call is ignored when run more than once, meaning there
should be no way of enabling full flash handling after it was disabled
and vice versa. The call should always be made by the firmware to lock
further calls, so that an OS could not gain full flash access. This is
done on entry to BS_POST_DEVICE after capsules are obtained in
BS_DEV_INIT.
Change-Id: I7f3dbfa965b9dcbade8b2f06a5bd2ac1345c7972
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
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>
Add a DSD with the HotPlugSupportInD3, as when it RTD3, the device
will appear as not-present. This will cause Windows to constantly
try to enable it, causing an endless loop of the device becoming
visible.
Test=build and boot `starlabs/starlite_adl`, check CNVi is always
visible in device manager.
Change-Id: I598ab173074522e9d5af002782c5d3ec7691a815
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87325
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a DSD with the HotPlugSupportInD3, as when it RTD3, the device
will appear as not-present. This will cause Windows to constantly
try to enable it, causing an endless loop of the device becoming
visible.
Test=build and boot `starlabs/starlite_adl`, check Bluetooth is
always visible in device manager.
Change-Id: I51a2c764ebe8b98b137eb0c98cfdcf2de6f4b86c
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87324
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
