This commit introduces ChromeOS-specific logic to the Panther Lake SoC
TDP selection. It addresses the need to correctly set the CPU TDP to 15
W without having to set the desired_tdp flag in each mainboard device
tree.
BUG=b:465698900
Change-Id: Ibaee530159f7e3b94aac16ab50b749cb161cee10
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This commit introduces a mechanism to configure the Thermal Design Power
(TDP) for Panther Lake, allowing board designers to override the default
TDP reported by hardware and select the value that matches their
specific board requirements.
Previously, the TDP value was determined solely by the hardware, which
limited flexibility for platforms that support multiple TDP options. By
adding a new field to the `soc_intel_pantherlake_config` structure and
implementing the `soc_get_cpu_tdp()` function, this change enables
boards to opt out of the default TDP and specify a custom value.
BUG=b:465698900
Change-Id: I6e401c2c7d7d0cda24fa07ec024813874fac3ed5
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90150
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update PL1 override values from a fixed value to zero, indicating that
the platform should use the default TDP value. This change allows the
common code to dynamically set PL1 according to the specific TDP SKU,
improving flexibility and ensuring correct power limit configuration
across different hardware variants.
Previously, PL1 was hardcoded to 15 for some SKUs, which could lead to
instabilities for SKUs with different TDP requirements.
TEST=No instability was observed on certain Fatcat SKUs.
Change-Id: Ibfb6b52aa15ad66740abc39f6f869dfa5e90de3c
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89934
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Guvendik, Bora <bora.guvendik@intel.com>
Reviewed-by: Ryu, Jamie M <jamie.m.ryu@intel.com>
Reviewed-by: Kim, Wonkyu <wonkyu.kim@intel.com>
Checkpatch emits the following warning about autoport-generated code:
WARNING: space prohibited between function name and open parenthesis '('
So, simply get rid of that space.
Change-Id: If52e3d56c6b254efb61c70c8e482014dd4208172
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nicholas <nic.c3.14@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch increases the size of the FW_MAIN_A and FW_MAIN_B slots to
8.5MB to accommodate APDP, Ramdump and ADSP-lite images. A 5MB
estimated size of QTEE image is also taken into account to avoid future
resizing.
Size required for QTEE:
Current size -> 2776K, Estimated size -> 5120K (5MB)
Additional size needed -> 5120K-2776K = 2344K
Size required for new images:
Ramdump - 449K
APDP - 0.7K
ramdump_meta - 0.1K
apdp_meta - 1.4K
ADSP_Lite - 1192K
Total = 1643K
Additional size needed (QTEE + new images):
2344K+1643K = 3987K
Current Layout of FW_MAIN_A/B slots:
Total size - 4608K (4.5MB)
Used size - 4126K
Free size - 482K
Additional size needed (excluding free size):
3987K-482K = 3505K
Total size of FW_MAIN_A/B slots:
4608K+3505K = 8133K
An additional buffer of 591K is included in the final size to
provide room for increase in size of other blobs. So,
Final size of FW_MAIN_A/B slots:
8133K+591K = 8704K (8.5MB).
TEST=Create an image.serial.bin and ensure it boots on X1P42100.
Change-Id: I3b3ba5c4bf8b5d3830174a890ea7cd089e3f274f
Signed-off-by: Venkateshwar S <vens@qualcomm.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90594
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The pic_width and pic_height fields of dsc_config are equivalent to
edid.mode.ha and edid.mode.va, respectively. To remove duplicate
information in panel_serializable_data, remove these two fields from
dsc_config.
BUG=b:424782827
TEST=emerge-tanjiro coreboot
BRANCH=none
Change-Id: I7f1dd4b431a610fa928b29da420b0c0e0bef5fcc
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90561
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The pic_width and pic_height in the dsc_config struct are equivalent to
edid.mode.ha and edid.mode.va. The duplicate information should be
removed from the panel_serializable_data struct, by removing from
dsc_config. To do that, replace references of dsc_config.pic_width with
edid.mode.ha in the MT8196 code.
BUG=b:424782827
TEST=emerge-tanjiro coreboot
BRANCH=none
Change-Id: Id1014886851a999ccdfec7ec86df2e7341ba9ffd
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90560
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
We'd like to replace dsc_cfg->pic_width with edid->mode.ha in MT8196's
dsc_configure_registers() and then deprecate the 'pic_width' field. To
do that, we will first need to pass the edid struct pointer from
mtk_ddp_mode_set() all the way to that function.
Currently mtk_ddp_mode_set() is in the MediaTek common code, which calls
SoC's mtk_ddp_soc_mode_set(), but the edid isn't passed. To simplify the
edid pointer passing, drop mtk_ddp_soc_mode_set() and replace it with
SoC's mtk_ddp_mode_set(). To minimize the duplicate code of calculating
vrefresh, introduce mtk_get_vrefresh() to the display API, and reference
it from SoC's code.
BUG=b:424782827
TEST=emerge-tanjiro coreboot
BRANCH=none
Change-Id: Ifb84c6b954dde2f25c3ac491a5392b7725c13a43
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90559
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Pass dsi_regs to mtk_dsi_cphy_timing() to be consistent with other DSI
APIs and mtk_dsi_dphy_timing(). This also supports C-PHY with dual
channel, although there is currently no such a device.
BUG=b:424782827
TEST=emerge-tanjiro coreboot
BRANCH=none
Change-Id: I81805aa181c46fb29c70d18553dbf0c0c06c2888
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90558
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Move dpm_init() and spm_init() from mainboard_init() in rauru to
soc_init() in mt8196. This centralizes the power management
initialization within the SoC-specific code.
BUG=none
TEST=Build pass, boot ok.
Change-Id: Ic2914fd0fc85032c96ce076416e9b9c46fe19e0d
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90550
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
That parameter was mistakenly added here while trying to silent lcov
complaints. Drop it again since it's not supported here.
Change-Id: I77bed4ebb7d3ef6daea39c812bacfcad7a72aee7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Add missing configuration items for rex variants to have functional
MIPI cameras under Windows/mainline Linux:
- Add IPUA device to graphics device configuration
- Add sensor_name register to sensor device configurations
Screebo was missing the gfx/generic configuration for all other display
outputs present in other variants, so add that as well.
TEST=build/boot Win11/Linux on karis and screebo, verify MIPI camera
functional under both OSes using the standard driver stack.
Change-Id: I14ec0efd88c43ca94ebde2be4652775bcb6d73c3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Ensure all mipi_camera sensor configurations have both ssdb.lanes_used
and ssdb.link_used defined, and that these values correctly match the
corresponding (known good) CIO2 IPU port configuration:
- ssdb.lanes_used must match cio2_lanes_used = {x} for CAMx
- ssdb.link_used must match cio2_prt[x] for CAMx
Change-Id: Ifbf22c69d29c71138b7f59f08782d90425a09e30
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
The issues still appears even after commit 65833355ca ("tests: Disable
gcov warnings"). So, disable the HTML generation completely until the
issue is figured out.
Change-Id: I683889ff8a0769697154079f99fe1d6ff9773281
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90578
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
This adds a few items which were merged after the preliminary release
notes were merged, and updates the statistics for actual release tag.
Change-Id: I3b59568a67a3caa553c5f409edfed3053c1d4b7d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The previous default size of 256KB provided for only 64KB of actual
space for EFI variables, and after accounting for fragmentation, did
not provide enough free space for applying updates, such as for the
UEFI revocation database (DBX). Increasing it to 512KB allows for
192KB space for variables, and allows the UEFI DBX to be updated
properly via fwupd.
TEST=build/boot starlite_adl, verify UEFI DBX able to be successfully
updated via fwupd.
Change-Id: I0fd28e38f5d3ad1e4db33fa3ab075929044ac831
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add a CFR option to expose the newly-added EC control to set the charge
LED brightness (normal/dim/off).
TEST=build/boot starlabs/lite_adl, verify charge LED control via CFR
Change-Id: I090437e8de2fd65bfad93a2037fd9346347e9fc1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Ali Hamid <ali@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90566
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add CFR options to expose EC controls to set the brightness of the
power and charge LEDs (normal/dim/off).
TEST=build/boot starfighter_mtl, verify LED control via CFR
Change-Id: I2af8372f923f92af62e48da77d4bddb87ab1eba0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90565
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add CFR options to expose EC controls to set the brightness of the
power and charge LEDs (normal/dim/off).
TEST=build/boot starbook_mtl, verify LED control via CFR
Change-Id: I7e1fe4efaab4327c8b95b108a9014e50058d6ed4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90564
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add support for controlling charge LED brightness similar to the
existing power LED brightness control. This includes:
- New Kconfig option EC_STARLABS_CHARGE_LED
- Charge LED CFR option in cfr.h
- Implementation in ite.c using shared led_brightness array
- ECRAM_CHARGE_LED register definition
Refactor LED brightness enum values into shared led_brightness array
for reuse between power and charge LED controls.
EC changes for charge LED brightness
TEST=build/boot starlabs/lite_adl and verify LED control via CFR
Change-Id: I0f243d666e1fdc7d6df9859bb1cdcf460b6029ec
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Ali Hamid <ali@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90563
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
This fixes the duplicate ddr6 entry which should have been ddr5.
Change-Id: I3bbee8a2fbacc7fa057e225fcfe307877b4f2716
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The mtk_ddp_ovlsys_start function is updated to take edid and path
as arguments. This allows the function to configure the framebuffer
address and overlay for DISP_PATH_DUAL_MIPI path.
BUG=b:319511268
TEST=cherry pick CB:90504 and manual enable BMP_LOGO related configs.
The logo is drawn in the ramstage.
Change-Id: I60809f7062907617f2af1badcad9f53477911020
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Add an option to lock the regions BOOTBLOCK and COREBOOT, leaving the
regions TOPSWAP and COREBOOT_TS for updates in an Intel Top Swap
redundancy scenario.
This means that the user can now write and choose to boot from the
update regions, selecting the attempt_slot_b CMOS option, and there is
a protected golden copy of the entire firmware, that cannot be
overwritten and can be reverted to by resetting CMOS.
This is part of an ongoing implementation of a redundancy feature
proposed on the mailing list:
https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Change-Id: Ia6dea22c41e2fc778af6ca7049b72c92686ec85f
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Before CPU resume, it is necessary to reinitialize the MTE-related
settings of booker in MCUPM to prevent the loss of booker
configurations after resume.
BUG=b:467186613
TEST=Build pass, Verify S/R OK on Navi and Sapphire.
Change-Id: Ieaf4c2ea0f8a5c372a5dbf4d0f6c44fbd978e6a6
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90546
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Separating the bootblock into two copies (in BOOTBLOCK and TOPSWAP fmap
regions) breaks the CBFS verification as TSPI CRTM knows nothing about
the new regions and looks for bootblock in a hard-coded COREBOOT fmap
region.
Introduce and use cbfs_unverified_area_type_alloc() which is an
extension of cbfs_unverified_area_alloc(), very similar to how
cbfs_ro_type_map() is an extension of cbfs_ro_map(). This allows to
specify a region of the bootblock file and skip verification because
bootblock serves as a container of hashes and is not verified itself.
The branching is done on the state of RTC BUC to always use the current
bootblock. Somewhat confusingly, the measurement always uses BOOTBLOCK
region because with active Top Swap that's the way to access a
memory-mapped TOPSWAP region.
Makefile.mk now verifies both COREBOOT and COREBOOT_TS regions.
cbfstool needed a few updates as well:
- recognize both "BOOTBLOCK" and "TOPSWAP" regions
- recognize both "COREBOOT" and "COREBOOT_TS" regions
- reset metadata cache before processing each region as cache may now
be invalid
SMM doesn't link with vboot functions, so cbfs_file_hash_mismatch() has
to skip verification in SMM due to the use of CMOS options backend.
This is a part of the bootblock redundancy feature proposed
on the mailing list:
https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Tested by successfully booting into Protectli VP6670 with Top Swap and
CBFS Verification features enabled and Top Swap state being toggled.
Change-Id: Ia75e714ae84d8c0ae09b27495e3056313b109999
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89691
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a correction of CB:89570 (commit 04ea4724e2 ("Makefile.mk:
separate bootblocks into BOOTBLOCK and TOPSWAP")). It wasn't obvious
that CBFS verification depends on bootblock being added first (otherwise
cbfstool considers CBFS verification to be disabled because anchor is
part of a bootblock). Correct this and add a comment for anyone else
who might edit this code in the future.
The issue manifested itself in build failing to perform CBFS
verification via cbfstool when the firmware was built with
CBFS_VERIFICATION enabled.
Change-Id: If775480394270fc05206cde0707c511b126265d3
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90436
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Take advantage of cbfstool's ability to operate on multiple regions and
introduce a variable with a list of main CBFS regions: it's just
"COREBOOT" in most cases, but becomes "COREBOOT,COREBOOT_TS" when Top
Swap update mechanism is enabled (see [0]).
This is meant to simplify Makefiles by avoiding extra branches in
existing and future changes.
[0]: https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Change-Id: If537d0d21a2867fafc2241ea9a0b4c0c6ca290a8
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90435
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-by: Filip Gołaś <filip.golas@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
This is a correction of CB:89570 (commit 04ea4724e2 ("Makefile.mk:
separate bootblocks into BOOTBLOCK and TOPSWAP")) which has FITs in both
BOOTBLOCK and TOPSWAP point at microcode in COREBOOT region.
This can be tested by comparing outputs of
build/util/cbfstool/ifittool -f build/coreboot.rom -r TOPSWAP -D
and
build/util/cbfstool/ifittool -f build/coreboot.rom -r BOOTBLOCK -D
with microcode addresses as shown by
uefitool build/coreboot.rom
The addresses in two regions must not be identical and their last six
hex digits must match what uefitool shows in "Base:" field (not
"Offset:").
Change-Id: Ie37aee7a26be18d1a4d8993afd2a2484c38c0b1e
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Filip Gołaś <filip.golas@3mdeb.com>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
The addition provides a way to select USE_OPTION_TABLE for a mainboard
which depends on the CMOS backend for options. This is needed to
support update mechanism based on Top Swap that permits recovery via a
CMOS reset (see [0]). The indirection is necessary because
USE_OPTION_TABLE is part of a `choice`.
[0]: https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Change-Id: I9e8f044077a5158650627a305c352cc9de578293
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90433
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-by: Filip Gołaś <filip.golas@3mdeb.com>
In addition to adding all currently-known names for the boards, add SoC
names to baseboards to make finding boards based on SoC family easier.
Change-Id: I389f68f09409ce3eb51422dbcfe7e80d463a1594
Signed-off-by: Alicja Michalska <alicja.michalska@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Build test the zstd code on qemu x86 and qemu aarch64.
Change-Id: Ib1f10b983492e01f74c7218e03e04615a41e7312
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89277
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This adds the option to compress ramstage and payloads with zstd.
zstd compressed ramstages are typically +5% bigger than lzma compressed
ramstages. The decompressor .text section grows by 20KiB and the
decompressor needs 16KiB more heap than the lzma decompressor.
To use less heap inside the zstd decompressor the build time define
ZSTD_DECODER_INTERNAL_BUFFER is used.
Quote:
The build macro `ZSTD_DECODER_INTERNAL_BUFFER` can be set to control
the amount of extra memory used during decompression to store
literals. This defaults to 64kB. Reducing this value reduces the
memory footprint of `ZSTD_DCtx` decompression contexts, but might
also result in a small decompression speed cost
TEST=Booted on Lenovo X220 with zstd ramstage showed no disadvantage
over a bigger internal buffer used.
TEST=Booted on Lenovo X220. The zstd decompressor is twice as fast
as the lzma decompressor.
cbmem -t shows:
- finished ZSTD decompress (ignore for x86) 79,444 (24,494)
- finished LZMA decompress (ignore for x86) 94,971 (45,545)
TEST=Booted on QEMU Q35, QEMU aarch64 virt, QEMU riscv RV64 with
zstd compressed ramstage.
Change-Id: Ic1b1f53327c598d07bd83d4391e8012d41696a16
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69893
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Define ENV_RAMSTAGE_LOADER in rules.h similar to ENV_PAYLOAD_LOADER
to simplify the current code and avoid code duplication when adding
zstd support.
Change-Id: I8c049c640b11c6f0b51e37dd2c368bb786ca9b0f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90153
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This adds zstd support to cbfstool. The code is taken from zstd-1.5.7
with modifications:
- renaming bits.h to zstd_bits.h to avoid conflicts with coreboot's
bits.h used on riscv
- renaming compiler.h to zstd_compiler.h to avoid conflicts with
coreboot's compiler.h
- Dropped all streaming API functions
- Dropped multithreaded support, since it's now unused
- Dropped local DDict support
zstd offers similar compression ratios to LZMA, but a vastly fast
decompress speed. Typically zstd results in slightly larger binaries
than LZMA. Whether zstd should then be preferred over LZMA depends on
a few things:
- Caching: When loading from memory mapped boot devices, zstd will read
the boot medium multiple times, while LZMA will not. If the memory
mapped boot medium is not cached zstd results in much slower
decompression.
- Boot medium speed: Often, but not always LZMA results in smaller
binaries. If the boot medium is the bottleneck, than loading smaller
binaries might actually be faster. On a fast boot medium (high spi
freq, using quad/dual io), the performance benefits from zstd might be
more substantial
- zstd decompression code has a much larger footprint than LZMA. If the
stage (postcar) is loaded in uncached memory the size increase might
slow things down.
On QEMU Q35 postcar .text section size doubled, while heap section
has growen by 50%.
- zstd uses a lot of .bss (CTX is about 32KiB large). This might not be
available in some environments.
Orignal commit from 2022 was using zstd-1.5.2. Updated to zstd-1.5.7.
Change-Id: I34508268f8767008ef25cb9e466d201345881232
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69753
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the xxhash lib to commonlib/bsd folder so that it can be
easily included by tools. Update use of standard headers to
allow compilation on POSIX compatible systems as well.
Use the new xxhash lib in cbfstool over the existing duplicated
xxhash lib residing in lz4/lib.
Change-Id: I21041409d5b734cecf43294dcaf3bf17531dbc15
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89682
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for the new memory Micron MT62F1G32D2DS-031RF WT:C using
spd-3.hex, and MT62F2G32D4DS-031RF WT:C using spd-6.hex
DRAM Part Name ID to assign
K3KL6L60GM-MGCT 0 (0000)
H9JCNNNBK3MLYR-N6E 1 (0001)
H58G56CK8BX146 2 (0010)
K3KL8L80CM-MGCT 3 (0011)
MT62F1G32D2DS-031RF WT:C 4 (0100)
MT62F2G32D4DS-031RF WT:C 5 (0101)
BUG=b:447273470
BRANCH=firmware-trulo-15217.771.B
TEST=util/spd_tools/bin/part_id_gen ADL lp5 \
src/mainboard/google/brya/variants/pujjocento/memory \
src/mainboard/google/brya/variants/pujjocento/memory/mem_parts_used.txt
Change-Id: Ica96fefb3fb8b18ed693383641960c67e128e7e7
Signed-off-by: Zheng Li <lizheng@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90454
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add MT62F2G32D4DS-031RFWT:C in the memory_parts.json and re-generate
the SPD.
Micron: MT62F2G32D4DS-031RFWT:C
BUG=b:447273470
TEST=util/spd_tools/bin/spd_gen spd/lp5/memory_parts.json lp5
Change-Id: I2dc0151db31ed07c61454e800d539c9b546a1ea7
Signed-off-by: Zheng Li <lizheng@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Newer gcov/lcov versions shipped in CI container images throw a warning
and thus cause the CI to fail. It's unclear how to fix this warning at
the moment, but gcov isn't critical anyway. So disable this specific
warning for now, so that we can roll out new CI images.
Excluding file '/home/coreboot/node-root/workspace/test_coreboot/payloads/libpayload/tests/libcbfs/cbfs-lookup-test.c'
lcov: WARNING: (inconsistent) /home/coreboot/node-root/workspace/test_coreboot/payloads/libpayload/libcbfs/cbfs.c:79: unexecuted block on non-branch line with non-zero hit count. Use "geninfo --rc geninfo_unexecuted_blocks=1 to set count to zero.
(use "lcov --ignore-errors inconsistent,inconsistent ..." to suppress this warning)
Excluding file '/home/coreboot/node-root/workspace/test_coreboot/payloads/libpayload/tests/libcbfs/cbfs-lookup-test.c'
[snip]
Message summary:
1 warning message:
inconsistent: 1
genhtml: ERROR: (corrupt) unable to read trace file 'build/coverage/tests.info': genhtml: ERROR: (inconsistent) "/home/coreboot/node-root/workspace/test_coreboot/payloads/libpayload/libcbfs/cbfs.c":77: function 'cbfs_unmap' is not hit but line 79 is.
To skip consistency checks, see the 'check_data_consistency' section in man lcovrc(5).
(use "genhtml --ignore-errors inconsistent ..." to bypass this error)
(use "genhtml --ignore-errors corrupt ..." to bypass this error)
make[1]: *** [tests/Makefile.mk:277: coverage-report] Error 1
make: *** [util/testing/Makefile.mk:103: what-jenkins-does] Error 2
Change-Id: I2c52c53fbe856a8bca062f34c576fdfda3818f2b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90554
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
If the APs are much faster then the working hart, it is possible that it
will enter HART_SLEEPING state before the working hart checks whether or
not the APs woke up by checking the HART_AWAKE state.
One can reproduce this issue by adding the following print message and
testing it in QEMU. One will notice that it will get stuck.
+ printk(BIOS_SPEW, "waiting for hart %d\n", i);
while (atomic_read(&OTHER_HLS(i)->entry.sync_a) != HART_AWAKE)
Fix it by adding another sync step at the end of `smp_resume()`.
Tested: QEMU RISC-V with -smp 64 parameter
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I1e0485831f71dde400d793b9f7bda88ae6519913
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Depending on the Kconfig, LAPIC may be in either xAPIC or x2APIC mode.
However, coreboot generates MADT LAPIC entries based on APIC ID rather
than currently enabled LAPIC mode. This resulted in LAPICs enabled in
x2APIC mode being described as xAPICs in MADT.
Create appropriate MADT LAPIC entries based on currently enabled mode
by calling is_x2apic_mode.
TEST=MADT describes LAPICs in x2APIC mode on Gigabyte MZ33-AR1, matching
the actually enabled LAPIC mode.
Change-Id: Iebbbca415f0b775339cbfab5c24848940d92878d
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89475
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Makefile is patching the BIOS moudule base address and size so that
the openSIL knows where the reset vector resides. However, the printf
used for hex convertion is missing 0x prefix for hexvalue. Kconfig hex
values start with 0x prefix. Otherwise, there is a chance the bios_base
variable could be interpreted as decimal integer. This could result
in improper reset vector address being calculated in OpenSIL and APs not
able to be brought up.
Change-Id: Ib528491b266ec2e8d74b9c8713788f8f37037162
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89472
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
