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>
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>
