This adds the contributor names from the 24.05 release to the 25.03
release.
Anyone who is making contributions on behalf of a company, please
add the company name to the list.
Change-Id: I23f38bd125a8369e0a636c4d1602c783f6730a0a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87381
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
To avoid confusion drop the label smm_handler_start, since it's unused
and the same name is also used in the permanent handler as C entry point
(see smm_module_handler.c).
Change-Id: I22bb5d378e8848d526f897cb2de70c0221827d0d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87554
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Add support for yet another of these LGA1155 boards. Nothing too fancy,
just another slightly different combination of the same chips.
Working:
- Booting to Arch Linux using SeaBIOS (current version)
- Native RAM init
- Realtek Ethernet NIC
- Some rear USB 2.0 and 3.0 (ASM1042) ports (did not test all)
- At least one SATA port (did not test all)
- libgfxinit to initialise a DVI-D display
- VBT (extracted from `/sys/kernel/debug/dri/0/i915_vbt`)
- PCIe x16 slot
- Both PCIe x1 slots
- EHCI debug (one of the rear USB 2.0 ports)
Not working:
- Automatic fan speed control (known limitation of Super I/O code)
Untested:
- HDMI, VGA
- Internal flashing (board was ported using an EM100Pro)
- Audio
- Front USB ports
- PS/2 ports
Change-Id: I18b116d265e0b7105e13a317b552aab0e4bbc762
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86726
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update VBT to one extracted from newer Lenovo UEFI, version FWKTBFA.
The newer VBT has build number 1037 and supports Kaby Lake graphics,
while the old VBT with build number 1000 only supports Skylake.
The old VBT starts with $VBT_SKYLAKE while the new one starts with
$VBT_KABYLAKE.
TEST=Insert CPU with integrated HD 630 graphics (i3-7100) and check if
all video outputs work in firmware.
Change-Id: I5e108d4ad8bf0663f3e1fa32145e40ea9babeac5
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
These three boards use <soc/intel/common/acpi/dptf/dptf.asl> and should skip generating the TCPU device via SSDT, so select
SOC_INTEL_COMMON_BLOCK_DTT_STATIC_ASL to make that happen.
TEST=build/boot drallion, hatch, and sarien. Dump ACPI and verify no
duplicate TCPU ACPI device, verify no ACPI errors in dmesg.
Change-Id: I6070e5291ce2476fc1c24d39583fcca94bed1395
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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 introduces the GPIO configuration support for the T4 LP5
Reference Validation Platform (RVP). It includes a table that outlines
the differences in GPIO configuration between the T3 LP5 RVP and T4 LP5
RVP. The GPIO differences are applied when the board ID is recognized as
T4.
BUG=none
TEST=Ensure the T4 RVP boots to the OS, then verify the GPIO pad
configurations by inspecting the output from /sys/kernel/debug/pinctrl.
Check that the GPIO PADs match the expected configuration for the T4
board.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Ica870752bed2ba47c73d8fcd5f2f41b9cc6db65a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87447
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This commit introduces support for the T4 LP5 board memory
configuration within the ptlrvp mainboard. The addition includes
defining the specific memory configurations such as data and strobe
signal mappings, early command training, and memory part ID
assignments. By implementing these changes, compatibility and
functionality are ensured for systems using the T4 LP5 board.
The memory configuration is specified for LP5 type memory with
detailed DQ and DQS mapping for different DDR channels. This
facilitates accurate signal routing and memory initialization.
Additionally, updates to associated Makefiles and documentation files
reflect these new memory parts (Hynix H58G56BK8BX068) and their IDs,
ensuring proper recognition and usage during system builds.
BUG=none
TEST=Build and verify system initialization on the T4 LP5 board with
the updated memory configuration. Confirm that memory training and
setup proceed correctly with the newly supported memory part.
Change-Id: Ia6e862af8c322fe4467465557c416d4171796e83
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87422
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the mainboard directory for Intel's ptlrvp variant, ensure that the
`variant.c` file is compiled during the ramstage build process. This
adjustment enables the execution of variant_update_soc_chip_config()
for ptlrvp in ramstage, addressing CNVi Wi-Fi-related issues.
BUG=None
TEST=Verify that variant.c is compiled correctly in ramstage for
ptlrvp.
Change-Id: Iec9591aac536abfdd36dfba8a8fea689830ee41a
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87570
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
This commit enables the `USE_COREBOOT_FOR_BMP_RENDERING` Kconfig option for
Panther Lake.
This allows the platform to utilize coreboot's native logo rendering
capabilities after the FSP initializes the display.
Additionally, this commit adds temporary MMIO definitions for the
Panther Lake I/O map: GMADR_BASE (0xB0000000) and GMADR_SIZE
(0x10000000). These definitions are necessary to program the IGD LMEM
BAR for accessible framebuffer and to enable Write Combine (WC) MTRR
caching for the LMEM BAR.
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`.
Observed a slight delay (~10-30ms) in displaying BMP image with native
coreboot implementation compared to FSP-based rendering.
Change-Id: I658db63906e051fa82f3297f039f9e3c814df43f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This commit overrides the `logo_valignment` setting in the
`common_soc_config` for the Fatcat board variant.
The vertical alignment for the firmware splash screen logo is now set to
`FW_SPLASH_VALIGNMENT_MIDDLE`, which places the top edge of the logo at
the vertical midpoint of the screen.
BUG=b:409718202
TEST=Built and booted google/fatcat.
Change-Id: I82cb0f9e06f23fb441011b9714284ac52a76d818
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.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 commit introduces an enum `fw_splash_vertical_alignment` to
configure the vertical placement of the splash screen image.
The enum provides options for aligning the logo to the top, bottom,
center (geometrical center), or middle (top edge at midpoint) of the
display.
BUG=b:409718202
TEST=Able to build and boot google/fatcat.
Change-Id: Id70fb56a038fba93d51dc1a7906724dbed6edf94
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87540
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 change refactors MTRR handling by consolidating helper functions
from `earlymtrr.c` and `mtrr.c` into a new MTRR library (`mtrrlib`).
This approach improves code modularity and reusability, making these
utilities consistently available across different coreboot boot phases.
The following functions are now part of `mtrrlib`:
- `get_free_var_mtrr`: Retrieves the index of the first available
variable MTRR.
- `set_var_mtrr`: Configures the variable MTRR, specified by an `index`,
for a memory region defined by `base`, `size`, and `type`.
- `clear_var_mtrr`: Disables the variable MTRR at a given index.
- `acquire_and_configure_mtrr`: Acquires a free variable MTRR, configures
it with the given `base`, `size`, and `type`.
BUG=b:409718202
TEST=Built and booted google/fatcat successfully.
Change-Id: Iba332b7088221fd930e973fad9410833bff184b9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87539
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.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>
Found that certain pins did not change according to the fw_config
settings. After tracing the code, discovered that
fw_config_gpio_padbased_override() was not being called, so this change
fixes the issue.
BUG=b:410481989
TEST=emerge-nissa coreboot
Change-Id: I07fb7860b32bae4922783fe437baafdd1c86482e
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87546
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Currently there are 3 GDTs (Global Descriptor Tables) being used on x86:
- preRAM (gdt_init.S)
- SMM (smm_stub.S)
- RAM (c_start.S)
They have different layouts and thus different offsets for the segments
being used in assembly code. Stop using different GDT segments and
ensure that for ROM (preRAM + SMM) and RAM (ramstage) the segments
match. RAM will have additional entries, not found in pre RAM GDT,
but the segments for protected mode and 64-bit mode now match in
all stages.
This allows to use the same defines in all stages. It also drops the
need to know in which stage the code is compiled and it's no longer
necessary to switch the code segment between stages.
While at it fix the comments in the ramstage GDT and drop unused
declarations from header files, always set the accessed bit and drop
GDT_CODE_ACPI_SEG.
Change-Id: I208496e6e4cc82833636f4f42503b44b0d702b9e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Hook up the s0ix_enable setting to the option API, so it can be changed
at runtime without recompilation. Default to the value set by the
mainboard.
Change-Id: I6c05212eaf004ea74b7fd3fa92cbaa314474b7e9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87503
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Hook up the s0ix_enable setting to the option API, so it can be changed
at runtime without recompilation. Default to the value set by the
mainboard.
Change-Id: Id9e75020ab359bf94c75ffc1aaaef7af83d4c9c6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87501
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hook up the s0ix_enable setting to the option API, so it can be changed
at runtime without recompilation. Default to the value set by the
mainboard.
Change-Id: Id35705304e872395ce88617c83d9edecb03b02a1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87500
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>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Hook up the s0ix_enable setting to the option API, so it can be changed
at runtime without recompilation. Default to the value set by the
mainboard.
Change-Id: I2d2f5c1587bd86c8fee634a49e1ec989c2bef783
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87499
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hook up the s0ix_enable setting to the option API, so it can be changed
at runtime without recompilation. Default to the value set by the
mainboard.
Change-Id: I8f55bb7b31936c098da64f65b76965a09981ff73
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87498
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an exception handler to SMM to debug crashes when a serial
console is enabled and DEBUG_SMI is set. This allows for narrowing
down issues faster than letting the machine triple fault.
Change-Id: I2ccaf8d23d508d773ce56912983884ad6832ede6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Add/update FP enable/disable based on SKU ID. This is meant
to resolve a UMA issue with devices that had the FPMCU populated on
non-fp devices. Since the FPMCU is present, and the firmware enables
the power GPIO's based on variant, not SKU, the devices were reporting
data on fingerprint errantly. Specify the SKUs which should not have a
FP sensor and default to true to maintain the legacy behavior for
undefined devices and limit risk. Variants which do not have FP SKUs
will be unaffected.
BUG=b:354769653
TEST=Flash on device, test FP.
Disable test SKU, flash on device, test FP.
To test, run `ectool --name=cros_fp version` in the shell
When enabled, the fpmcu fw version should be displayed.
When disabled, an error should be displayed because the fpmcu
is inaccessible.
Change-Id: I9811721d0b345614e10ac27946ad45b6ec6f7494
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86826
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Delete the "TODO: Update for Phoenix" comment from files that have
already been updated in the previous chained patches (CB:85631,
CB:85632, CB:85633).
Change-Id: I137dbba5094ae8cbf842b45d6137c5b0528e5413
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85719
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Configure all strap GPIOs as outputs, rather than some being not
connected. This doesn't change anything, but is more explicit.
Set these all to sample on RSMRST.
Change-Id: I557bfc1339bad169753640c9404813305a16024e
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
As per commit cf4722d317 ("src/mb: Update unlicensable files with the
CC-PDDC SPDX ID") effectively empty files should use the Creative
Commons Public Domain Dedication and Certification (CC-PDDC) license
header. Add a function to create an empty file and add the CC-PDDC SPDX
header and a comment to change the license if content is added.
The only empty files that autoport currently generates are ec.asl and
superio.asl on non-laptop systems, where NoEC() is used.
Change-Id: I409a6d90d671258e318c26e34a35c238d6fd28c1
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84329
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This commit updates the platform reporting logic to include support
for Wildcat Lake SoC.
Key changes:
- Add Wildcat Lake-specific entries for MCH, PCH, and IGD device
IDs.
References:
- Wildcat Lake Processor EDS Volume 1 (#842271)
- Wildcat Lake External Design Specification (EDS) Volume 2 (#829345)
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: Ia4efb173f3ff9247d50bcfa496ed92b211729a3a
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87515
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces PCI device details specific to the Wildcat
Lake to Panther Lake code with conditional compilation.
Key changes:
- Add Wildcat Lake-specific PCI device definitions and
configurations, including adjustments to device function
numbers and slot assignments.
- Remove following
- PCIe RP : 00:1c.4 to 00:1c.7
: 00:06.2 & 00:06.3
- Change following
- PCIe RP5 : 00:1c.4 to 00:06.0
- PCIe RP6 : 00:1c.5 to 00:06.1
- Following devices are not present in Wildcat Lake, but their
device definitions are retained as they do not impact
functionality.
- IPU : 00.05.0
- TBT2 : 00.07.2
- TBT3 : 00.07.3
- TCSS_XDCI : 00.0d.1
- TCSS_DMA1 : 00.0d.3
- Update Kconfig to conditionally select COMMON_BLOCK_IPU
only when SOC_INTEL_PANTHERLAKE is selected.
- Modify existing code to utilize the guards, ensuring that
Panther Lake-specific devices and configurations are only
included when appropriate.
- Add configuration options for MAX_TBT_ROOT_PORTS, MAX_ROOT_PORTS,
and MAX_PCIE_CLOCK_SRC with Wildcat Lake values.
MAX_TBT_ROOT_PORTS = 2
MAX_ROOT_PORTS = 6
MAX_PCIE_CLOCK_SRC = 6
References:
- Wildcat Lake Processor EDS Volume 1 (#842271)
- Wildcat Lake External Design Specification (EDS) Volume 2 (#829345)
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: I89f9d9f043d3ff04c0c65dc9d92a76566e901da9
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87514
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Usha P <usha.p@intel.com>
This patch introduces a new chipset device tree file for Wildcat
Lake SoC.
Key changes:
- Copy the Panther Lake chipset.cb to chipset_wcl.cb and update
it with device information specific to the Wildcat Lake SoC.
1) Remove following devices:
- Ipu - 00:05.0
- Tbt Rp - 00:07.2 & 00:07.3
- Type-C xDCI - 00:0d.1
- Tcss Dma - 00:0d.3
- Pci Rp - 00:1c.4 to 00:1c.7
- 00:06.2 & 00:06.3
- Two TCSS USB ports
2) Remove Panther Lake Power limits config and add placeholder
for WCL config.
- Guard removed TCSS port references in the shared SoC code with
Kconfig.
- Rename Panther Lake chipset device tree to chipset_ptl.cb to
align with the new device tree naming.
- Update Kconfig to select the newly added chipset device tree
file when the Wildcat Lake SoC is in use.
References:
- Wildcat Lake Processor EDS, Volume 1 (#842271)
- Wildcat Lake External Design Specification (EDS) Volume 2 (#829345)
BUG=b:394208231
TEST=Build Ocelot and Fatcat and verify it compiles without any error.
Change-Id: Ieafb9856daaa48e3ecc6fc9068ae2b2d4019ff80
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87490
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes device entries from the Ocelot mainboard
devicetree that do not exist in the Wildcat Lake SoC. This ensures
that the Ocelot firmware compiles without any errors when device
tree changes of Wildcat Lake SoC are added in the subsequent patches.
Key changes:
- Remove the following devices, which are not present in the
Wildcat Lake SoC, from Ocelot:
ipu
tbt_pcie_rp2
tbt_pcie_rp3
tcss_dma1
pcie_rp9
tcss USB port 2 & 3
References:
- Wildcat Lake Processor EDS Volume 1 (#842271)
- Wildcat Lake External Design Specification (EDS) Volume 2 (#829345)
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: Ib09f66f2e567f3f42810215bca8956c7cee7b646
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87479
Reviewed-by: Usha P <usha.p@intel.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 commit updates the `fill_lb_gpios` function in
`src/mainboard/google/bluey/chromeos.c` to include additional
GPIO states for Chrome OS diagnostics.
The following GPIOs are now reported:
- GPIO_SNDW_AMP_0_ENABLE: "Speaker 0 enable" (active high)
- GPIO_SNDW_AMP_1_ENABLE: "Speaker 1 enable" (active high)
- GPIO_SD_CD_L: "SD card detect" (active low), reported
conditionally if CONFIG_MAINBOARD_HAS_SD_CONTROLLER is enabled.
BUG=b:404985109
TEST=Successfully built google/bluey with the Qualcomm x1p42100 SoC.
Change-Id: I0063e8190571241edda64165b9ade9c4331a3499
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87451
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This commit introduces several new GPIO definitions and a Kconfig
option for the Bluey mainboard to support additional hardware features.
Kconfig changes:
- MAINBOARD_HAS_SD_CONTROLLER: To indicate the presence of an SD card
controller. It defaults to 'n'.
GPIO changes (in board.h):
- Soundwire Amplifier GPIOs:
- GPIO_SNDW_AMP_0_ENABLE (GPIO 204)
- GPIO_SNDW_AMP_1_ENABLE (GPIO 205)
- Display specific GPIOs:
- GPIO_PANEL_POWER_ON (GPIO 70)
- GPIO_PANEL_HPD (GPIO 119)
- SD Card specific GPIO:
- GPIO_SD_CD_L (GPIO 71): This GPIO is conditionally defined based
on the new CONFIG_MAINBOARD_HAS_SD_CONTROLLER option.
Source: Bluey schematics (dated 04/15).
BUG=b:404985109
TEST=Successfully built google/bluey with the Qualcomm x1p42100 SoC.
Change-Id: I556b06bff73805c6451a5f8cf291c83cd0431465
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jayvik Desai <jayvik@google.com>
This commit introduces support for DDR5 memory configuration on the
PTL RVP DDR5 board. It adds the necessary board ID for PTLP_DDR5_RVP
and integrates a new DDR5 memory configuration within the variant
parameters. The memory configuration includes settings such as
resistor values, sagv values, early command training, and
DDR5-specific training parameters.
Additionally, SPD information retrieval is adapted to accommodate
DDR5-specific settings, such as DIMM module topology and SMBus
addresses.
BUG=none
TEST=Boot to OS with PTL RVP DDR5 board and verify memory
initialization.
Change-Id: I7e3bbb66edcbf4d4a10fcf6899156f125dc3d529
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87179
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The existing lanczos_weight() implementation naively follows the purely
mathematical definition for the `x == 0` special case. However, the
point of defining that special case is obviously to prevent division by
zero in the general case formula. Unfortunately we are still doing some
multiplications with `x` before we get to the division step, and our
fpmath library loses precision during multiplication. This can lead to
edge cases where `x` is not zero but `x_times_pi` later ends up being 0,
which causes the division to throw an exception after all. (I guess
we've just been lucky to not see this case in practice for now... it
requires the output pixel coordinate to be extremely close to but not
quite on the next input pixel coordinate, which may be rare in practice
with our scaling algorithms.)
This patch fixes the issue by implementing the special case later and
checking if `x_times_pi` is zero instead. Note that as long as we pass
this check, we can be confident that the division cannot fail even
though fpdiv() also truncates the divisor: this is because `x_times_pi`
was calculated from an fpmul() call with the constant fppi(), which has
34 significant bits. Even if x is the smallest possible non-zero value
after scaling for multiplication, the result `x_times_pi` must still
have 18 significant bits. That means it can be scaled down a further 16
bits for division without becoming zero.
Also add a simple unit test forcing exactly this condition to ensure the
code will not regress.
Change-Id: I2f212ee5df38252e97ec55aba3d2d25320c4b102
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87532
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
If DRIVERS_WIFI_GENERIC is disabled
`wifi_generic_cnvi_ddr_rfim_enabled` can't be found by the linker.
Additionally if there is no WIFI driver the CNVi DDR RFI Mitigation is
redundant.
Add DRIVERS_WIFI_GENERIC check around `CNVi DDR RFI Mitigation`.
TEST=Boot Intel Alder Lake-P RVP with DRIVERS_WIFI_GENERIC=N and
cnvi_wifi disabled
Change-Id: I4f89ef41a730e38e08886828db0d14f1277ccaf0
Signed-off-by: Harrie Paijmans <hpaijmans@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Was inadvertently left out when this board was created.
TEST=build, verify ramstage.o created in variant subdir of build dir.
Change-Id: I3c728ba2abe94be4115a60d3a532cf0a19bec33c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Add a CFR option to boot using the native panel resolution, rather than
a fixed/scaled video mode. This option selects between two VBT files:
one with the 'fixed mode' flag enabled, and one with it disabled.
This feature is mainly a workaround to a GNOME-related bug which
causes the creation of a 2nd display at the boot resolution. This
2nd display being a lower/different resolution than the native
panel resolution causes severe flickering/artifacting rendering
the display unusable unless this 2nd phantom display is disabled
on every boot.
Change-Id: I9e39258ce0171aab425150679d1ce30d69b2b1ef
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Add a CFR option to boot using the native panel resolution, rather than
a fixed/scaled video mode. This option selects between two VBT files:
one with the 'fixed mode' flag enabled, and one with it disabled.
This feature is mainly a workaround to a GNOME-related bug which
causes the creation of a 2nd display at the boot resolution. This
2nd display being a lower/different resolution than the native
panel resolution causes severe flickering/artifacting rendering
the display unusable unless this 2nd phantom display is disabled
on every boot.
Change-Id: I275b5f8455fed58c0167e3a69db27bbc21577db0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87494
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
For boards for which set the 'Fixed Mode at boot' flag in the VBT, add
a CFR option to boot using the native panel resolution, rather than
a fixed/scaled video mode. This option selects between two VBT files:
one with the 'fixed mode' flag enabled, and one with it disabled.
This feature is mainly a workaround to a GNOME-related bug which
causes the creation of a 2nd display at the boot resolution. This
2nd display being a lower/different resolution than the native
panel resolution causes severe flickering/artifacting rendering
the display unusable unless this 2nd phantom display is disabled
on every boot
Change-Id: Ia75727f393744caf9062763e6118c1e2601512fa
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Allows the Bluetooth RTD3 feature to be toggled on/off.
On some devices, enabling Bluetooth RTD3 causes the BT device to
continually disconnect/reconnect under Windows, so having the ability
to disable it in those cases is useful.
Change-Id: I1730dc35d56919fcf03acdf577288caf1e1a4ee3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87492
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Commit a959f0ad76 ("allocator_v4: Disable top-down allocation for
EDK2") disabled top-down allocation for edk2 due to a bug which broke
display init with Intel IGD. A workaround has been implemented in
MrChromebox's fork (and others) while the issue is being resolved
upstream, so re-enable top-down allocation unless upstream edk2
is being used.
TEST=build/boot various Google mainboards with edk2 payload selected.
Change-Id: I0e9b0d02bbf30878aef37a97d6a743a402700fc7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
When soft-disabled, boards selecting SOC_INTEL_CSE_LITE_SKU boot up
with a working state of M3_NO_UMA vs NORMAL, so handle this condition.
Without this, when vboot is not used, the board will simply fail to
boot as vboot_recovery_mode does not exist:
[ERROR] cse_lite: CSE does not meet prerequisites
[ERROR] cse_lite: Failed to get CSE boot partition info
[DEBUG] cse: CSE status registers: HFSTS1: 0x80032044,
HFSTS2: 0x32280126 HFSTS3: 0x50
[EMERG] cse: Failed to trigger recovery mode(recovery subcode:6)
This commit addresses the first error (does not meet prerequisites),
which allows CSE sync to continue and boot the RW partition in
the soft-disabled state. It also allows the CSE to properly transition
back into the normal working state (when that option is selected via
CMOS or CFR).
TEST=build/boot google/wyvern, verify able to disable/enable the ME
properly via CFR option.
Change-Id: I46da5ac248e267acee958d66ebbd97d945e722b9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87517
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: Jérémy Compostella <jeremy.compostella@intel.com>
When soft-disabled, boards which select SOC_INTEL_CSE_LITE_SKU boot
with their working state having a value of M3_NO_UMA (0x4), as
opposed to the "normal" value of M0_NO_UMA (0x5). Add a define for
this value (taken from older ME code in coreboot) and add a function
to check if the CSE is in that state, which will be used in a
subsequent commit.
TEST=tested with rest of patch train
Change-Id: I405987ece00b3849a9fcdf1bfc8b377fd8d010dc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87516
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>
This commit refactors the configuration options for Intel
Panther Lake SoC variants to improve clarity and maintainability.
Key changes:
- Introduce a new SOC_INTEL_PANTHERLAKE configuration option to
serve as a base selection for all Panther Lake SoC variants.
- Update SOC_INTEL_PANTHERLAKE_U_H and SOC_INTEL_PANTHERLAKE_H to
select SOC_INTEL_PANTHERLAKE instead of
SOC_INTEL_PANTHERLAKE_BASE.
- Update existing code to utilize the new SOC_INTEL_PANTHERLAKE
guard where Panther Lake variant guards are applied.
BUG=b:394208231
TEST=Build Ocelot and Fatcat and verify it compiles without any error.
Change-Id: I656006dab6f08c9a16996ad194fa0b5b751f91aa
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87511
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The original SPMI calibration process is only suitable for pre-MT8189
SoCs. Update the flow to also support MT8189.
BUG=b:379008996
BRANCH=none
TEST=build pass and driver log is normal:
[INFO ] [Pass] dly:1, pol:0, sampl:0x2
[INFO ] [Pass] dly:1, pol:0, sampl:0x2
Signed-off-by: Zhigang Qin <zhigang.qin@mediatek.corp-partner.google.com>
Change-Id: I636b3062fc25fc1d7d39e3426602e6434be4c26a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87508
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
