Use existing define for SMRR and PMRR support instead of redefining
it in various places.
TEST=No functional change, thus untested.
Change-Id: Ie366a9d695800acd9713bd4e8393201a1f0a5ab2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91015
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For most targets it's known if the CPU supports alternative SMRR
registers or not. Only on model_6fx runtime detection is necessary.
On all platforms this allows the compiler to optimize the code and
thus shrink the code size if alternative SMRR aren't supported.
TEST=On Lenovo X220 the ramstage is 308 bytes smaller.
Change-Id: I3a965d142f79ad587b8cedc9b4646b05e2a45f8b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91014
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The `intel_early_me_init_done()` function prints the ME status. In order
to see the ME status once in all paths, have the aforementioned function
only call `intel_early_me_status()` before handling a reset request.
Change-Id: I42ad1b25889a21047b7cf55e7940293e73794d8b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91374
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
DDR frequency (in MHz) was doubled for no reason, then doubled again to
convert it to MT/s. Moreover, the calculations assume a reference clock
of 133 MHz, but a 100 MHz reference clock also exists.
Add two functions: `is_100_mhz_refclk()` to check whether the reference
clock is 100 MHz, and `get_ddr_freq_mhz()` to get the DDR frequency, in
MHz. Use both functions in `report_memory_config()` to show the correct
DDR ref. clock and frequency, and use one in `setup_sdram_meminfo()` so
that SMBIOS tables contain the correct memory speed.
Tested on ASRock Z97 Extreme6 with four DDR3-1600 sticks, DDR frequency
is correctly reported as 800 MHz with either reference clock frequency:
Default 133 MHz reference clock:
memcfg DDR3 ref clock 133 MHz
memcfg DDR3 clock 800 MHz
After forcing 100 MHz ref clock for 800 MHz (edit NRI's `init_mpll.c`):
memcfg DDR3 ref clock 100 MHz
memcfg DDR3 clock 800 MHz
Also, SMBIOS type 17 correctly reports memory speeds of 1600 MT/s:
$ sudo dmidecode --type 17 | grep -i speed
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
It is expected that behaviour using either MRC binary is the same since
the `MC_BIOS_REQ` and `MC_BIOS_DATA` registers have to be programmed in
order for the DDR clock to start running. The decision to test with NRI
is because one can easily change the chosen reference clock to 100 MHz.
Resolves: https://ticket.coreboot.org/issues/624
Change-Id: Idead9cd55b453d3ff4695c977dee763ff50830f8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Be consistent when printing the channel assignment, and use unsigned
printf specifiers since the values themselves are unsigned.
Change-Id: I66b93233707dec73dc7a25423789a24770ac678f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Increase the logo_bottom_margin from 100 to 200 in the display_logo
configuration if FRAMEBUFFER_SPLASH_TEXT Kconfig is enabled.
This adjustment ensures the OEM footer logo and associated
splash text are rendered higher on the screen, improving visibility
and alignment with updated UX requirements.
BUG=None
TEST=Boot MediaTek device and verify the splash text is 200px from
the screen bottom edge as expected.
Change-Id: I490e50e200dfffedf24cb30fe0ca6ea6ae037d3d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91383
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update Wildcatlake FSP headers to align with the FSP version WCL.3515.03.
BUG=b:475358197
TEST=Build the ocelot CB with the latest header changes.
Change-Id: I1232523e662d91cf43e7ed6bcc4fbefeaf8447e9
Signed-off-by: Sowmya V <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90753
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Avi Uday <aviuday@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove platform-specific uart.c and switch to the common UART device
list driver. This eliminates duplicate code.
The pantherlake uart.c simply defined uart_devices[] array. The common
driver now handles this using the PCI_UART_DEVFN macro defined in
pci_devs.h.
This commit:
- Selects SOC_INTEL_COMMON_FEATURE and
SOC_INTEL_COMMON_FEATURE_UART_DEVICES in Kconfig
- Removes uart.c and updates Makefile.mk
Change-Id: I59443ece21bc45c8b6986fdd2bc24dd9ccf7a543
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91244
Reviewed-by: Kim, Wonkyu <wonkyu.kim@intel.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove platform-specific uart.c and switch to the common UART device
list driver. This eliminates 18 lines of duplicate code.
The Alder Lake uart.c simply defined uart_devices[] array with
PCH_DEVFN_UART* macros. The common driver now handles this using the
PCI_UART_DEVFNn macro defined in pci_devs.h.
This commit:
- Adds PCI_DEVFN_UART* aliases pointing to PCH_DEVFN_UART* for naming
consistency with common code
- Selects SOC_INTEL_COMMON_FEATURE and
SOC_INTEL_COMMON_FEATURE_UART_DEVICES in Kconfig
- Removes uart.c and updates Makefile.mk
Change-Id: Iafd4881c44dd9ccf7e204378bbafafbd1c884db0
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91242
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces a common UART device list implementation that
eliminates duplication across multiple Intel SoC platforms. Instead of
maintaining nearly identical uart.c files in each platform directory,
this common driver uses platform-specific macros to define UART device
function numbers.
The common implementation expects each platform to define the following
macros in their soc/pci_devs.h header:
- PCI_DEVFN_UART0
- PCI_DEVFN_UART1
- PCI_DEVFN_UART2
This approach maintains platform flexibility while reducing code
duplication and simplifying maintenance. The driver is compiled across
all stages (bootblock, verstage, romstage, postcar, ramstage, smm) to
support various UART usage scenarios.
Change-Id: Iba82a2fe24dd9ccf704e4a0fadc481b63662b94d
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91241
Reviewed-by: Kim, Wonkyu <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Introduce a new directory structure src/soc/intel/common/feature/ for
sharing SoC-specific code across Intel SoC generations to reduce code
duplication.
Unlike the common block code (src/soc/intel/common/block/) which is
intended for reusable IP blocks, the feature code is for SoC-specific
functionality that is similar (but not identical) across multiple
generations. Platform-specific differences are handled through
configuration options or platform-specific macros.
This commit:
- Creates src/soc/intel/common/feature/ directory
- Adds feature/Kconfig defining SOC_INTEL_COMMON_FEATURE
- Adds feature/Makefile.mk to build subdirectories
- Updates src/soc/intel/common/Kconfig.common to source feature/Kconfig
- Updates src/soc/intel/common/Makefile.mk to include feature/ subdirs
- Documents the common code directory structure in
Documentation/soc/intel/code_development_model/code_development_model.md
Change-Id: Idb842376a0a785a6439eeeb5a3a934d0bc575b09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91360
Reviewed-by: Bora Guvendik <bora.guvendik@intel.corp-partner.google.com>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
In this case, the callback function already treated the option as if
it were a boolean option, which likely only worked by chance.
Change-Id: Ic4b86c45e4837fcdb30cf594bb7e30400864e77e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91356
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I6c4e44507fc371fc8b693b2289c58eb61ac84aa8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91355
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I3ac872881627179cb4ef344132bb601c78ca3a01
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I7f3bb4f13a143e37869c22d66a514581a88deeb2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91353
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: If9030e770a59d9de87f7b0f2112887db6126aacf
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91352
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I4e4f5c071f4299876e4ecd9defe7782c85eac3d8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91351
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I4be1ac4644c461fd64766e27383e479ff518a889
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91350
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I009413db0873c42a98cfc8bddb8613c66d496947
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91349
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I491f92b334d0e9f98737b94a7232e9361e86743d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91348
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I77bfefd0bf173da34675ad64253daae472834bb8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: Ib480c7dcd99eb5bf16b124584b4e7dbad90d0c84
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I8f3a69dfb9fb915c44c9a5486512aa82c2615fab
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
In this case, the callback function already treated the option as if
it were a boolean option, which likely only worked by chance.
Change-Id: I747ecd0b5a33d2773eda409e6578362d694154ee
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91344
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
In this case, the callback function already treated the option as if
it were a boolean option, which likely only worked by chance.
Change-Id: I7e53c791d48bd5ce5271505c59856bf7ff18e6d0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91343
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
Change-Id: I3c73f289271eb4bba899bbfe9d3036171cb31d7b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Boolean options are intended to represent generic "Enable"/"Disable"
options, but without enum options' extra bloat in the CFR structures.
The "volume" option has been left as-is because the code reading its
value does not seem to handle it like a boolean.
Change-Id: If183957cff6097187904e0d76c7d3ad997fe365c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91341
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit f530d37da7 ("mb/lenovo/x220: Add PCIe ports in CFR") introduced
several enum options for "Enabled"/"Disabled" settings. These work like
bool options, except that they add extra bloat to the resulting CFR data
structures.
Replace the enum options with bool options. Also rename the macro as it
no longer generates an enum option. While we're at it, properly format
"Wi-Fi" and drop a blank line at the start of a file.
Also, since checkpatch complains about the macro including a trailing
semicolon, drop it from the macro definition and add it at the end of
every use of the macro.
Change-Id: I7889e22d12e01171ed77ae98d29bbd067e45d82b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91340
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
For some reason, there is a blank line at the beginning of these files.
There is no reason to keep this line, so drop it for consistency.
Change-Id: I38092fae7a3f32b34c15d1b4500c4009fca4d5e2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
Introduce SOC_QUALCOMM_QCLIB_SKIP_MMU_TOGGLE to allow platforms to
maintain the MMU state across the QCLib execution boundary.
Traditionally, coreboot enables the MMU and performs cache maintenance
before disabling it and handing control to QCLib. QCLib then performs
its own initialization: saving MMU registers, performing cache flushes,
and disabling the MMU before returning to coreboot. During the
subsequent entry, QCLib would restore registers and repeat the cycle.
By selecting this Kconfig, we optimize boot time by avoiding these
repeated enable/disable operations. QCLib is permitted to utilize the
MMU context already established by coreboot, bypassing redundant
reinitialization, register restoration, and expensive cache flushes
to the Point of Coherency.
- Legacy platforms continue to toggle the MMU by default.
- Platforms selecting this option bypass mmu_disable() and mmu_enable().
BUG=b:449871690, b:477139887
TEST=Able to reduce boot time by 600ms while booting google/quenbi.
Change-Id: I6b5e199afc27dcb27d74d2753d2ce269ee22f0ac
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add support for THC-SPI touchscreen configuration in the GPIO pad-based
override logic.
The GPP_E17 pin serves dual purposes depending on the hardware
configuration:
- When touchscreen THC-SPI is present: NF3 (THC HID-SPI CS0)
- When fingerprint sensor is present: NF5 (GSPI0 CS0)
The firmware configuration logic now prioritizes touchscreen THC-SPI
over fingerprint sensor configuration, as these are mutually exclusive
hardware configurations.
BUG=None
TEST=Build ocelot and verify correct GPIO configuration based on
fw_config settings for both touchscreen THC-SPI and fingerprint sensor
configurations
Change-Id: I93deb6352cd0f1168ad53819151c705c6ce48b28
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: P, Usha <usha.p@intel.com>
The lapis hardware design does not have a power load switch for
the SSD. Without it, the platform cannot cut off the main power rail
to the device to enter D3cold.
Therefore, remove the RTD3 chip driver and its associated configurations
in the overridetree to align with the hardware capability. The system
will support D3hot instead of D3cold.
BUG=None
TEST=Build and boot to OS on Lapis, verify SSD functions correctly and
power state transitions align with HW design.
Change-Id: I61f15165e1d41c4f347499e2a7200f30d18bcca7
Signed-off-by: Pranava Y N <pranavayn@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Lapis requires the addition of a new fingerprint module, and
the fingerprint module needs to be distinguished via UFSC when
updating the fingerprint module fw.
BUG=b:463867670
TEST=./config/payload_utils/generate_ufsc.py ap
Change-Id: I69846aa404adc76c6446de68749f0fe469e570a3
Signed-off-by: Hualin Wei <weihualin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Drop useless ACPI code and make the codebase look more like the
T430 codebase. IASL doesn't remove empty scope blocks and it
causes binary differences in the produced DSDT.
TEST=TIMELESS build shows that T530 DSDT is now identical to the
T430 DSDT.
Change-Id: Ie65668b98c5ee772a926a265d09ee20ab8d2e15e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move the TPM entry to make the devicetree.cb look like the T530
devicetree.cb. Should not change any functionality, but changes the
TIMELESS build artifact.
Change-Id: Ia49c8fe9781e4d97aaf5ef38d5d76fdfc8c0f0be
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Fill in the speed in MT/s that the DIMM currently runs at and the
speed it could run at.
Change-Id: I936b97bd517f2fcf80ff403171fc89d4a4487761
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90396
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some silicon initialization modules, like OpenSIL report bus width
extension as 16 bits for ECC for DDR5 memories. Handle this case
correctly for DDR5 and LPDDR5 memories by reporting appropriate
bitfield of the SPD width. This field is used later by coreboot to
calculate the bus extension again, which results in 16bit extension
for ECC.
Change-Id: Ia0a9c221a5d047dd7feb212027f5da2399ccb8e1
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
ACPI stores trackpad_state and kbl_brightness as small indices in
CMOS (per cmos.layout and RPTS/RWAK). The ITE init path treated the
CMOS byte as the EC's raw encoded value, so non-default settings
would fall back (e.g. trackpad disabled, kbd backlight brightness).
Treat CMOS-backed values as LUT indices and fix the kbl_brightness
fallback to use an index.
Change-Id: Id8d320c9544c9fa73b234817717c47f1fa169c64
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91301
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Bring in ACPI ASL code from sio/nuvoton/common and hook up the
SIO ACPI suspend hook.
TEST=PS/2 keyboard can wake asus/p8z77-m from S3 but not S5, as
expected.
Change-Id: I8d38928adb840d6fcb4703dd9ad69480813156ca
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89746
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Retire the short-lived special setup to share C code between them, in
favour of the common init code provided by CB:82632.
Tested on asus/p8z77-m with SeaBIOS 1.17.0.
Change-Id: I699fc08d9bfc56dad28eb20042884e979785c070
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently DSDT keyboard and mouse device declarations generated by
this file use IDs derived from the logical device number, in the
form of KBD# and PS2# where # is the LDN. This is far from the norm
for mainboards with only one super I/O chip, where they are named
PS2K and PS2M, which is also the names used by the much more
simplistic ASL code in drivers/pc/pc80. They also use hard coded
PNP IDs.
This patch adds two preprocessor symbols, SUPERIO_KBC_PS2KID and
SUPERIO_KBC_PS2MID, to allow these device IDs to be changed, most
likely to PS2K and PS2M. If not defined, existing naming logic is
kept.
Their _HIDs are also changed to refer to EISA ID from Kconfig,
like pc80 does. This in theory allows mainboard to change
their PNP IDs if needed. Only Lenovo laptops actually change this
from the Kconfig default, which is also the formerly hardcoded value.
Goal is to allow eliminating pc80 in favour of this when appropriate,
to avoid potential conflicts that may arise from having duplicate PS/2
devices defined.
TEST=With new symbols undefined, generated dsdt.asl did not change.
Generated dsdt.asl checked for correctness manually via temporary
manual edits, with all combinations of preprocessor controls.
Change-Id: I0dcc94c2cb09fee2e22776fd800c3435a9409c84
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
TEST=Processed dsdt.asl for mainboards using this super I/O chip
only contain changes specifically made by CB:89740.
Change-Id: Id8067e6058b650121e7c830a0cb298752a45d62c
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Make this chip use the common Nuvoton ACPI code before mainboards using
this chip begin to come online.
Change-Id: I000ebc92d1c408a865fb803a2e540ca3cca53ee7
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Define the requisite super I/O chip identities and bring in the common
ACPI code.
Change-Id: I2fbd77b0ddc5618a2da844f6e18ce483774c4cf0
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90575
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Define the requisite super I/O chip identities and bring in the common
ACPI code.
Change-Id: I1db85c8d0028a1c3e4a5582f3d0e503b71beac70
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90574
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With few exceptions, Nuvoton super I/O chips have the same
configuration registers.
This patch provides a single set of initialization routines to set
up power loss resume, initialize keyboard, and handle switching
PS/2 port role for mainboards with only one PS/2 port.
Power loss resume handling and PS/2 port role switching can be
controlled using nvram or CFR options. Mainboards lacking such
options will need to add them separately.
The common routines support all currently in-tree Nuvoton SIO chips
except nct5104d, nct6687d, npcd378, wpcm450. They will be hooked up
in follow-up patches.
There is also SMM code to disable PS/2 keyboard wakeup before going to
S5, otherwise the system will also power up with any key on the
keyboard, which is most likely undesirable. To use this, mainboards
must set Kconfig SUPERIO_NUVOTON_PNP_BASE, add smm.c to Makefile.mk
and call it from mainboard_smi_sleep().
Update the help text of HAVE_SHARED_PS2_PORT Kconfig with the final
option name used.
TEST=Both power loss resume and PS/2 port role control work on
asus/p8z77-m with entire train of supporting patches applied.
Change-Id: Ibaddcaa2d77c5b06ddfbb6dbaac00df5e72dd4bd
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
INTRUDER# may be asserted continuously on some Star Labs systems.
Disable routing the event to SMI by default to avoid SMI storms when TCO
SMIs are enabled (e.g. via BOOTMEDIA_SMM_BWP).
This allows boards, like starbook_tgl, which assert INTRUDER# constantly
to boot.
TEST=build/boot starbook_tgl with BOOTMEDIA_SMM_BWP selected
Change-Id: I6a2a188a295cc6be3af2043ea902d45c5bb5b95d
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91336
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some platforms can have INTRUDER# asserted continuously. If it is routed
to SMI, this can cause an SMI storm and prevent boot.
Introduce SOC_INTEL_COMMON_BLOCK_SMM_TCO_INTRUDER_SMI_ENABLE to control
whether INTRUDER# is routed to SMI, while keeping TCO SMIs available for
other uses (e.g. SPI sync SMIs needed by BOOTMEDIA_SMM_BWP).
TEST=build
Change-Id: I33eb8ce3bee64c95a4d5a6f95a096577d55c742d
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91335
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When an existing LPC window covers an IO range, but is bigger or starts
earlier the current code doesn't recognize it. It will open another
window overlapping an existing one.
Check if an existing LPC IO window covers the current one and allow it
to be bigger than the entry.
TEST=Thinkpad X280 still boots and error messages are gone.
Should fix the following line seen in the coreboot log of the Lenovo
T480 and compatible:
[ERROR] LPC: Cannot open IO window: 1604 size 1
[ERROR] No more IO windows
[ERROR] LPC: Cannot open IO window: 1606 size 1
[ERROR] No more IO windows
[ERROR] LPC: Cannot open IO window: 1610 size 10
[ERROR] No more IO windows
Change-Id: I586066238b801d2abb1122698fb4092ee0b2f6b9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91171
Reviewed-by: Ladislav Ezr <ladislav@ezr.cz>
Reviewed-by: Johann C Rode <jcrode82@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
