Add a common implementation of gspi_soc_bus_to_devfn() to reduce code
duplication across multiple Intel SoC platforms. This implementation
uses the SOC_GSPI_DEVFN(n) macro which must be defined by each platform
in their soc/pci_devs.h header to map GSPI bus numbers to PCI device and
function values.
This change enables consolidation of nearly identical gspi.c files from
Alder Lake, Meteor Lake, Panther Lake, Tiger Lake, Jasper Lake, Elkhart
Lake, Cannon Lake, and Skylake platforms.
The implementation leverages the existing
CONFIG_SOC_INTEL_COMMON_BLOCK_GSPI_MAX Kconfig option and includes
compile-time assertions to ensure the configuration is within supported
limits (up to 7 GSPI controllers).
Change-Id: I776cebd70968fd4b8bbab176bca0a446a0cc76ab
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91322
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `LPCL` and `LPS0` methods are specific to PCH-LP, and are not used
at all on PCH-H. To prevent accidental use and to reduce the DSDT size
on PCH-H builds, add some preprocessor guards around those methods.
For the ASRock Z97 Extreme, `build/dsdt.aml` size goes from 8538 bytes
down to 7904 bytes, a reduction of about 7%.
Change-Id: I775dcde4932f6039ba7d5673364e495837a386da
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Declaring named objects for constants is not ideal, especially when done
inside of a method (it is highly inefficient). Instead, use preprocessor
defines.
Change-Id: I2d9d17b820ee72ba628b44ae508a7c467c023dd9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Declaring named objects for constants is not ideal, especially when done
inside of a method (it is highly inefficient). Instead, use preprocessor
defines.
Change-Id: I1143f2aa09a2ed04da92edcf6ae9d832c0b5e2fa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91393
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Setting `SWAI` and `SAIP` is already done in the LPT-H and LPT-LP
specific branches, so there's no need to do it again. WPT-LP does
NOT need these writes.
Change-Id: Ib5156fab1384cdc531fc1d49dd61e5fc4600e894
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91391
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
- Add documentation about Old/New motherboard revisions
- Mention that FW6A/B/C exist as both Old and New Revision
- Mention that the current codebase only supports the Old Revision
- Add documentation about FW6D and FW6E variants, currently unsupported
Signed-off-by: Purdea Andrei <andrei@purdea.ro>
Change-Id: Ifdf1624c8d206326c64163382b31c6001300b4df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Introduce a common implementation for I2C device function to bus
number mapping that can be shared across multiple Intel SoC platforms.
The implementation uses:
- CONFIG_SOC_INTEL_I2C_DEV_MAX: Kconfig value for max I2C controllers
- SOC_I2C_DEVFN(n): SoC-specific macro for I2C devfn names
This eliminates duplicate code across platforms that follow the
standard I2C controller numbering scheme.
Change-Id: Ib242d7a839ccb26394794382098cecb658adf698
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91258
Reviewed-by: Guvendik, Bora <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 339ef9b5c9 ("soc/intel/common/block/lpc: Improve automatic
window opening") introduced a bug in the decoding of existing LPC I/O
window sizes from the LGIR (LPC Generic I/O Range) registers.
The AMASK field in the LGIR register stores bits [7:2] of the address
mask, with bits [1:0] implicitly always set to 1 (representing 4-byte
granularity). The original implementation incorrectly calculated the
window size as:
exist_size = 1 + ((reg32 & LPC_LGIR_AMASK_MASK) >> 16)
This fails to restore the implicit lower bits [1:0] of the mask.
For example, a window programmed with size 8 bytes:
- Stored mask: (8-1) & 0xfc = 0x4 (bits [7:2] only)
- Incorrectly decoded: 0x4 + 1 = 5 bytes (WRONG)
- Correctly decoded: (0x4 | 0x3) + 1 = 8 bytes (CORRECT)
This bug caused failures on Panther Lake boards where existing windows
were not recognized as covering requested ranges, leading to:
[ERROR] LPC: Cannot open IO window: 800 size 8
[ERROR] No more IO windows
The fix properly reconstructs the full mask by OR-ing in the implicit
bits [1:0] before calculating the size:
exist_size = ((amask_raw & 0xfc) | 0x3) + 1
BUG=b:486133237
TEST=Boot Panther Lake Fatcat board, verify no LPC window errors
Change-Id: I0b5f95c01da6ce84924a038106edec600e3b97f8
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91418
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Migrate the low-battery power-off sequence in Intel common reset
logic to use platform_handle_emergency_low_battery().
This ensures that all Intel-based boards benefit from the unified
ChromeOS battery alert flow (LED notification and ELOG recording)
without duplicating the logic in the SOC layer.
BUG=none
BRANCH=none
TEST=Verified that low-battery shutdown on Intel platforms still
correctly logs ELOG and triggers visual alerts via the new hook.
Change-Id: I37c15a1f7dd5acee10389c0521e8c9b2f2d90d42
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Refactor trigger_critical_battery_shutdown() to use the newly
implemented platform_handle_emergency_low_battery() hook.
This removes duplicate logic from the Bluey mainboard directory and
ensures consistency with the ChromeOS common battery handling code
for visual alerts and ELOG recording.
BUG=none
BRANCH=none
TEST=Build and boot on Bluey; verify emergency shutdown still
triggers red LEDs and logs ELOG events correctly.
Change-Id: I28da29eb3f0033abe524f7ee12d6b823392e9766
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Introduce platform_handle_emergency_low_battery() to handle the
pre-shutdown sequence when battery levels are critical.
This hook ensures:
1. Visual feedback is provided (Lightbar set to red).
2. The event is logged to ELOG for post-mortem analysis.
3. A delay is enforced to ensure logs are committed and the user
notices the alert before the AP powers off.
BUG=none
BRANCH=none
TEST=Verified lightbar turns red and ELOG is recorded on low battery
boot.
Change-Id: I3f1b2757002d7a2a76dfb51d24a04e2d81b061bb
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Initialize the ChromeOS EC LEDs during the bootblock phase for the
fatcat mainboard. This ensures the LEDs are powered on early in the boot
process to provide visual feedback to the user.
This covers edge cases where the lightbar was left in an OFF state
by AP firmware and no EC reset occurred to restore defaults.
TEST=Boot moonstome and verify the LEDs turns on during the
bootblock stage.
Change-Id: I24ce78e4a30ea8fce7d7a90e01525c328db7e325
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Initialize and turn on the Chrome EC lightbar during the early romstage
initialization phase. This ensures that the lightbar is active and
ready to provide visual feedback as early as possible in the boot
process.
This covers edge cases where the lightbar was left in an OFF state
by AP firmware and no EC reset occurred to restore defaults.
BUG=b:477531197
TEST=Boot bluey and verify the lightbar turns on during the
early romstage.
Change-Id: I9336acc83d0455c21378ef7cb77939d4d5d54250
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Turn off the lightbar when the system boots into Low-Battery with
Charger or Off-Mode Charging states.
This ensures that the external lightbar does not provide conflicting
visual signals while the built-in display is showing the charging
animation. Additionally, this prevents unnecessary power consumption
from the lightbar in these power-restricted modes.
BUG=b:477531197
TEST=Boot bluey in off-mode charging; verify lightbar is disabled.
Boot bluey normally; verify lightbar functions as expected.
Change-Id: Ice64d700aee82c780f872a3cb18f8a873e9189f5
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Implement google_chromeec_lightbar_on() to allow the host to
explicitly enable the Chrome EC lightbar. This function sends the
LIGHTBAR_CMD_ON sub-command through the EC_CMD_LIGHTBAR_CMD
host command.
BUG=None
TEST=Verified lightbar can be re-enabled after being turned off on
supported hardware.
Change-Id: I838525ba091281fefb3b6a33b9974037d06706d4
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91381
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Implement google_chromeec_lightbar_off() to allow the host to
explicitly disable the Chrome EC lightbar. This is achieved by
sending the LIGHTBAR_CMD_OFF sub-command via the multiplexed
EC_CMD_LIGHTBAR_CMD host command.
This API is useful for power-saving scenarios or UI synchronization
during specific boot modes, such as low-battery or off-mode charging.
BUG=None
TEST=Verified that the lightbar turns off when this function is
called on supported hardware.
Change-Id: Ic118dbd5e9af64d06490dd16aa115aca2c1df3a5
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91377
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Micron MT62F1G32D2DS-031RF memory part to mem_parts_used.txt
and generate corresponding SPD ID entry.
BUG=b:483845259
TEST=Use part_id_gen to generate related settings
Change-Id: I0476c4dcc55204b8fc278d969fa0f09462671b8c
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91172
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Creation of named objects within a method is highly inefficient, as per
IASL's remarks during DSDT compilation. But it is possible to use local
variables instead of named objects to store a package.
Update the `GPLD` method to use a local variable, instead of creating a
named object. While at it, unify cosmetics of the several copies of the
method across the codebase.
TEST: Build coreboot for the ASRock Z97 Extreme6 (Lynx Point) and run:
- acpiexec -b "Evaluate _SB.PCI0.XHCI.HUB7.GPLD 0" build/dsdt.aml
- acpiexec -b "Evaluate _SB.PCI0.XHCI.HUB7.GPLD 1" build/dsdt.aml
Observe return value is the same before and after this change.
Change-Id: Id66322150c90309f42f574584728c6b1db353c0c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91390
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Signal integrity measurement on I2C1 bus showed not optimal rise time.
Therefore the clock frequency is reduced from 400kHz to 100kHz to reach
optimal signal integrity also during coreboot runtime.
TEST=Signal integrity measurement during coreboot runtime.
Change-Id: I9721ede7aa645b2ca46f377bbe557f78c36581f6
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91079
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.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 12 lines of duplicate code.
The Skylake uart.c simply defined uart_devices[] array. The common
driver now handles this using the PCI_DEVFN_UARTn macros 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: Id686de6bb4dd9ccf78644817881b2abfb5ae0352
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Remove platform-specific uart.c and switch to the common UART device
list driver. This eliminates duplicate code.
The cannonlake uart.c simply defined uart_devices[] array. 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: I819dc9853b4b44eb97238c1d5ad464dd9ccf7f9a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91248
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 9702010123.
Fatcat RVP is sometimes unable to boot when non-serial image is flashed.
Reverting this CL until permanent verified fix is landed.
BUG=b:487523987
TEST=Able to boot fatcat to OS from Gen4 SSD slot
Change-Id: I5c61879cfb6e5f54d439284d1f75db5bfceddd1d
Signed-off-by: Pranava Y N <pranavayn@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91422
Reviewed-by: <srinivas.kulkarni@intel.com>
Reviewed-by: Avi Uday <aviuday@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Remove platform-specific uart.c and switch to the common UART device
list driver. This eliminates duplicate code.
The elkhartlake uart.c simply defined uart_devices[] array. 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: I778faf19128f41509f70d324dd9ccf71d93cab0b
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Remove platform-specific uart.c and switch to the common UART device
list driver. This eliminates duplicate code.
The jasperlake uart.c simply defined uart_devices[] array. 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: I8f7c68c8c44dd9ccf7cb49af8a3561a47d4aacc2
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Remove platform-specific uart.c and switch to the common UART device
list driver. This eliminates duplicate code.
The tigerlake uart.c simply defined uart_devices[] array. The common
driver now handles this using the PCI_UART_DEVFNn macros 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: I9520bd3f4dd9ccf777e34c79a8c8237adb8b0fed
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91245
Reviewed-by: Werner Zeh <werner.zeh@siemens.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 meteorlake uart.c simply defined uart_devices[] array. The common
driver now handles this using the SOC_UART_DEVFN(n) macro defined in
pci_devs.h which uses token concatenation to map to platform-specific
PCI_DEVFN_UARTn definitions.
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: Ic791eaa2521a44aba330e149fb0185094dd9ccf7
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91243
Reviewed-by: Kim, Wonkyu <wonkyu.kim@intel.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the defines for PCI register SMM_FEATURE_CONTROL to the header
soc/pci_devs.h like it's done on other server platforms as well.
While on it add BIT1 that will be used in the following commit.
TEST=Not a function change, thus untested.
Change-Id: Ib05bb129f069ab1a6f4752a2dac829b3b7b41ec9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
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>
