This patch adds google_chromeec_set_lightbar_rgb() to allow mainboards
to manually control the individual LED colors. This is useful for
providing visual feedback during early boot or platform-specific
events, such as low-battery warnings.
TEST=Build and boot google/fatcat.
Change-Id: I146006511ea727787ea496b0674b67fa950ce8f2
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Commit e59c5abd13 ("ec/google/chromeec: Add
EC_GOOGLE_CHROMEEC_FW_CONFIG_FROM_UFSC") refactored cbi_get_uint32() to
write directly to the caller's buffer instead of using a local variable.
This caused uninitialized memory (containing garbage addresses) to be
passed to the EC as the return buffer during CBI reads.
In the case of google/zork, the call to
google_chromeec_cbi_get_board_version() returned garbage data (e.g.,
0xae6ccd05 vs 0x5) which caused incorrect code paths to be taken:
- variant_override_gpio_table() selected wrong GPIO tables based on
invalid board version comparisons
- variant_touchscreen_update() skipped touchscreen GPIO configuration
because variant_uses_v3_6_schematics() returned true for garbage
values
- variant_uses_codec_gpi() returned wrong value, preventing
headphone jack interrupt setup
These misconfigurations caused input devices (touchpad, touchscreen,
trackpoint) to be non-functional, despite being detected by the OS.
The fix restores the original behavior by using a local variable
initialized to 0, ensuring a clean buffer is always passed to the EC.
TEST=build/boot google/zork, verify board version is read correctly,
all input devices functional under Linux/Windows.
Change-Id: Ia7be0bcc588075ab5c994edc3d68e979cc01ac79
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90761
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On certain platforms, such as Qualcomm X1P42100 (Hamoa), the AP cannot
successfully execute the standard CHARGE_STATE_CMD_GET_STATE host
command while in the S0 power state. This is typically due to hardware
arbitration or access restrictions to the battery fuel gauge bus during
active operating states.
This patch introduces a mechanism to fallback to manual State of Charge
(SoC) calculation using dynamic battery metrics:
1. Add EC_GOOGLE_CHROMEEC_BATTERY_SOC_DYNAMIC Kconfig: Allows platforms
to opt-in to manual SoC calculation.
2. Refactor existing logic: The standard command is moved to an internal
static helper google_chromeec_read_batt_state_of_charge_cmd().
3. Unified API: google_chromeec_read_batt_state_of_charge() now switches
between the standard command and the raw/dynamic calculation at
compile-time based on the Kconfig selection.
By using ec_cmd_battery_get_dynamic(), the AP retrieves cached telemetry
from the EC. This avoids triggering synchronous bus transactions to the
battery, ensuring SoC data is available even when direct fuel gauge
access is restricted.
BUG=none
BRANCH=none
TEST=Build for Hamoa and verify SoC is correctly calculated via the
dynamic info path. Verify standard platforms still use the charge
state command path.
Change-Id: I4928017362140884762140884762140884762140
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Implement google_chromeec_read_batt_state_of_charge_raw() to
calculate the battery percentage using raw capacity metrics.
Unlike the standard charge state command, this function retrieves data
via EC_CMD_BATTERY_GET_DYNAMIC. It manually calculates the State of
Charge (SoC) by comparing remaining_capacity against full_capacity.
This provides a fallback mechanism for platforms where the high-level
CHARGE_STATE_CMD_GET_STATE command is not implemented or when working
directly with the fuel gauge's dynamic data cache.
Includes:
- Zero-capacity check to prevent division by zero.
- 100% clamping to handle fuel gauge rounding/calibration drift.
Change-Id: I86d6313884762140884762140884762140884762
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90615
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement google_chromeec_read_batt_state_of_charge() to retrieve the
current battery percentage from the Embedded Controller.
The function uses the CHARGE_STATE_CMD_GET_STATE host command to fetch
the State of Charge (SoC) as calculated by the EC's fuel gauge logic.
This provides a high-level percentage (0-100) suitable for power
management decisions or UI display.
Change-Id: Iec88476214088476214088476214088476214088
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The google_chromeec_is_charger_present function previously relied on
executing the EC_CMD_BATTERY_DYNAMIC_INFO command to check the
EC_BATT_FLAG_AC_PRESENT flag.
This commit refactors the function to directly read the host event
register (EC events B) and check for the EC_HOST_EVENT_AC_CONNECTED
event flag instead.
This approach is much more efficient as it avoids the overhead of
sending and receiving a full EC command (savings ~25-30ms), using a
readily available cached status instead.
TEST=Able to build and boot google/quenbi.
Change-Id: I2ec9aca5991394ed1d4998da37e074e9324bd672
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90334
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add ec_rgb_kb_color CFR option to select RGB keyboard color at
boot. Suppress regular keyboard backlight option when RGB keyboard
is present, as they are mutually exclusive.
TEST=build/boot google/mithrax, verify RGB keyboard option enabled,
all colors able to be set at boot.
Change-Id: I55848931248a70023c49b98190105679f2999ad9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Add enum google_chromeec_rgbkbd_color with predefined color values
(OFF, RED, GREEN, BLUE, YELLOW, WHITE) and helper functions to
detect RGB keyboard support and set keyboard color. The color enum
is converted to RGB struct values internally for EC communication.
These will be used in a subsequent change adding support for setting
the RGB keyboard color at boot via CFR.
TEST=tested with rest of patch train.
Change-Id: I9afcbd8359e0fdc7c89e653165499f693367f5db
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90159
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Commit 04778ddd38 ("drivers/option/cfr: Remove old sm_object from
constructor") updated the function signature for CFR callbacks, but the
commits adding the fan and backlight controls were merged afterwards
without being adjusted accordingly. Do so here.
TEST=build/boot google/link with these CFR options enabled.
Change-Id: I9ea5224a820b014c4c8edb93e8a6b336ea6f58d0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Chromium OS EC has some specialized handling of chromebook specific
function keys on the keyboard top row, these have a function specific
action key code that is exposed to the OS and used to map their
position, and also a specific scancode that has to be mapped to a Linux
event code.
This adds the necessary mapping for KEY_HOMEPAGE, which is going to be
used in new devices.
The scancode picked is 0xe012, which maps to e02a or 0xaa, the
corresponding EC CL is:
https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/7118961
BUG=b:446007724
TEST=flashed and tested on a brox board with chromiumos, checked the
code with evtest
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Change-Id: I395721a342f507453dae19373df2f189ac1b5dac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90024
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Create a new header with CFR objects for keyboard backlight and
automatic fan control, which mainboards can include in their
setup menus in order to expose the options. The visibility of the
options are controlled by callbacks which test for device presence.
Change-Id: I2386b527f65b2e3b4ca43b9b65b69040abee00ad
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Allow enabling of automatic fan control via a setup option, while
preserving the functionality of the existing Kconfig symbol.
TEST=tested hooked up to a CFR option to toggle automatic fan control
at boot, with visibility controlled by fan presence, on a range of
ChromeOS devices with and without a PWM-controlled fan.
Change-Id: I0510c0d0bd79106036f77d59e04d455ee904ce6e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89830
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add google_chromeec_has_fan() to determine if a board has a fan or not.
The function first tries the EC feature flag (EC_FEATURE_PWM_FAN),
falling back to a RPM read test if the flag is unavailable.
TEST=tested hooked up to a CFR option to enable auto fan control at
boot, with option visibility controlled by fan presence, on a range
of Chromebooks with and without PWM-controlled fans.
Change-Id: I2a920709f0e6780c779a87568d6a8d18f817c76d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89829
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Add the ability to set the keyboard backlight level at boot, controlled
by a setup option variable and restricted to devices which actually
have a backlit keyboard.
TEST=tested hooked up to a CFR option 'ec_kb_backlight' (added later in
the patch series) to set the keyboard backlight at boot, with
visibility controlled by backlight presence, on a range of Chromebooks
with and without keyboard backlight support.
Change-Id: I92eed62935d0333f548599860b7bbe22f6b9f2b4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89828
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add a new function google_chromeec_has_kbbacklight() to check if the EC
has keyboard backlight capability. The function first tries the EC
feature flag (EC_FEATURE_PWM_KEYB), falling back to a read test if
unavailable. The EC command ec_cmd_pwm_get_keyboard_backlight() returns
-1 if the device does not have a keyboard backlight.
This function will be used in subsequent commits to guard setting the
keyboard backlight at boot and the visiblity of a CFR option setting.
TEST=tested hooked up to a CFR option to set the keyboard backlight
at boot, with visibility controlled by backlight presence, on a
range of Chromebooks with and without keyboard backlight support.
Change-Id: I74daf7a63f06239d2ba3915221555af494a9340f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89827
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`ToString(byte x)` is undefined behavior per the ACPI spec, which
causes Windows to discard the battery device status entirely.
Fix this and improve performance of the BRSX method by using an array
to store the characters read, calling ToString() only once at the end.
TEST=build/boot Win11 and Linux on google/rex, verify battery status
reported properly under both OSes.
Change-Id: I4e5aea3b2763a3c4433abe95c3a41d218fcd06c1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Enable _CRS method when EC_GOOGLE_CHROMEEC_LPC_GENERIC_MEMORY_RANGE is
configured, even without EC sync IRQ support.
Previously, the _CRS method was only generated if EC_ENABLE_SYNC_IRQ or
EC_ENABLE_SYNC_IRQ_GPIO was defined, causing LPC generic memory range
configuration to be skipped on boards that don't use EC sync IRQ which
will results in no communication between kernel and EC.
This change ensures LPC memory range resources are properly exposed
in ACPI considering the hardware limitations where the EC sync IRQ GPIO
is not available for boards using LPC_GENERIC_MEMORY_RANGE.
BUG=437459757
TEST=Build and verify EC LPC memory range is configured in ACPI tables
on boards with EC_GOOGLE_CHROMEEC_LPC_GENERIC_MEMORY_RANGE enabled
by dumping ssdt tables and also verify 'ectool version' cmd.
ectool version
RO version: ojal-0.0.0-2db24f9+
RW version: ojal-0.0.0-2db24f9+
Change-Id: If63dd631029d2756451fad71a5556bc0b23f507d
Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89420
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a Kconfig option EC_GOOGLE_CHROMEEC_FW_CONFIG_FROM_UFSC for
reading firmware configuration from Unified Firmware and Second-source
Config (UFSC) [1] from EC CBI. As the UFSC already includes both the
32-bit FW_CONFIG and 32-bit SSFC, this option is incompatible with
EC_GOOGLE_CHROMEEC_INCLUDE_SSFC_IN_FW_CONFIG.
Also check the size of the data read from CBI.
[1] https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/6974727
BUG=b:448300592
TEST=emerge=skywalker coreboot
BRANCH=none
Change-Id: I2f686838d2f7a6f3eec3bd5224f89389340f7471
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89404
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Adds the `google_chromeec_ap_poweroff()` helper function to the ChromeEC
driver.
This new API wraps the `EC_CMD_AP_SHUTDOWN` command and sends it to the
Embedded Controller (EC). This provides a cleaner, standardized way for
other coreboot components to initiate an Application Processor (AP)
power-off sequence via the EC.
After sending the shutdown command, the function calls `halt()` as the
AP is expected to power down immediately after the EC processes the
command.
BUG=b:439819922
TEST=Verify shutdown on Google/Quenbi.
Change-Id: Iace6a66972791bb7acdb978dfeea67b6ff0fec68
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89223
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generated using update_ec_headers.sh [EC-DIR].
The original include/ec_commands.h version in the EC repo is:
60aa7ccea9c include/ec_commands.h: Avoid lint errors
The original include/ec_cmd_api.h version in the EC repo is:
f47d8af4fbb include/ec_cmd_api.h: Define new API for EC_CMD_AP_SHUTDOWN command
Change-Id: I31d08bf4a0318ca3ba8c5bb5563acfe65830523b
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89296
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the ojal variant of the ocelot reference board by copying the
ocelot files to a new directory named for the variant.
BUG=b:437459757
TEST=1. Build emerge-ocelot
2. Run part_id_gen tool without any errors
Change-Id: Ic2fc86d89facae21b9bed898ebe518d316d953da
Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Generated using update_ec_headers.sh [EC-DIR]
The original include/ec_commands.h version in the EC repo is:
9b00e297ee chipset: Add a host command to issue AP shutdown
The original include/ec_cmd_api.h version in the EC repo is:
0c77d31000 UCSI/PPM: Add ucsi_host_cmd tests
Change-Id: I9b27cdd946c2e20a996ef338ec57d08de4e26059
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89007
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The host must initialize necessary settings before
accessing the Realtek EC via EMI.
BUG=b:414474440
TEST=FW_NAME=brox_rtk_ec emerge-brox coreboot chromeos-bootimage
flash to brox board with realtek rts5915
Boot normally and got those message from ap console:
[DEBUG] Google Chrome EC uptime: 107.108 seconds
[DEBUG] Google Chrome AP resets since EC boot: 2
[DEBUG] Google Chrome most recent AP reset causes:
[DEBUG] 10.479: 32775 shutdown: entering G3
[DEBUG] 92.102: 8 reset: during EC initialization
[DEBUG] Google Chrome EC reset flags at last EC boot: watchdog | sysjump
[DEBUG] PNP: 0c09.0 init finished in 81 msecs
Change-Id: I85ad210ccd40097dff552f7e72fe712e33cfd95f
Signed-off-by: Elmo Lan <elmo_lan@realtek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Jayvik Desai <jayvik@google.com>
This commit adds the necessary infrastructure to support Realtek EC
controllers RTS5912/RTS5915 within the ChromeOS EC framework.
TEST=With this commit and 87702, flash to brox(rework realtek rts5915)
Boot normally and got those message from ap console:
[DEBUG] Google Chrome EC uptime: 698.137 seconds
[DEBUG] Google Chrome AP resets since EC boot: 6
[DEBUG] Google Chrome most recent AP reset causes:
[DEBUG] 635.380: 8 reset: during EC initialization
[DEBUG] 645.374: 32775 shutdown: entering G3
[DEBUG] 680.284: 8 reset: during EC initialization
[DEBUG] 684.586: 8 reset: during EC initialization
[DEBUG] Google Chrome EC reset flags at last EC boot: soft
[DEBUG] PNP: 0c09.0 init finished in 284 msecs
Change-Id: I44118c7b61a7efcee81acdd04be90b5022007a41
Signed-off-by: Jhan Bo Chao <jhan_bo_chao@realtek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87544
Reviewed-by: Keith Short <keithshort@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit updates `ec/google/chromeec/Makefile.mk` to properly
include source files for SPI and I2C Embedded Controller (EC)
communication in the bootblock.
Previously, essential APIs (e.g., `google_chromeec_command` and
`crosec_command_proto`) were missing during EC code compilation
in the bootblock, leading to linker errors.
This patch resolves these compilation issues by ensuring:
* `ec_spi.c` is included when `CONFIG_EC_GOOGLE_CHROMEEC_SPI` is
enabled.
* `ec_i2c.c` is included when `CONFIG_EC_GOOGLE_CHROMEEC_I2C` is
enabled.
* `crosec_proto.c` is included if either
`CONFIG_EC_GOOGLE_CHROMEEC_SPI` or `CONFIG_EC_GOOGLE_CHROMEEC_I2C`
is enabled.
This ensures all required EC communication components are part of the
bootblock, allowing systems like `google/quenbi` that use the SPI EC
interface to build successfully.
Change-Id: I1d05f582a1685503118797e1788c9bc2ac191168
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87904
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some older platforms (eg, google/link), setting the wake mask
before clearing the pending events will result in an immediate
wake from S3 sleep, so swap the ordering to ensure that doesn't
happen.
TEST=build/boot google/link, verify S3 sleep works properly.
Change-Id: I483dcfabd37a1f55fd0e56eed895f5b813f018d7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Add UCSI port data/port location data which is required for Windows to
use UCSI.
Adjustments taken from EC ACPI on Dell 5400/7410 Windows devices.
TEST=build/boot google/drallion, verify type-C ports functional under
Windows 11.
Change-Id: I04aa87ec10f320d1740cd3897864d154f2aea507
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87489
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Only run _REG on attach
- Reinitialize on WAK to support S3 / Hibernate
Adjustments taken from EC ACPI on Dell 5400/7410 Windows devices.
TEST=build/boot google/drallion, verify S3 sleep works properly as
well as S0ix.
Change-Id: I162d02c7d3c81f1106ddc65a3804f7112dda66b2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87488
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some ITE ECs take long time (15-20s) to complete flash erase operation
during EC software sync. Increasing the timeout value to 30s avoids
EC_CMD_FLASH_ERASE command from timing out. As this is just a timeout
value, it should not have any effect on the boot time.
BUGS=b:386920751, b:412210635
TEST= Verify that the EC_CMD_FLASH_ERASE(0x13) is not timing out while
performing EC sync. Below error is avoided,
```
[ERROR] Timeout waiting for EC process command 19!
[INFO ] VB2:update_ec() vb2ex_ec_update_image(select) returned 0x10000001
[INFO ] VB2:vb2api_fail() Need recovery, reason: 0x26 / 0x1
[INFO ] VB2:sync_ec() update_ec(ctx, select_rw) returned 0x10000001
[INFO ] VB2:vb2api_fail() Need recovery, reason: 0x26 / 0x1
[INFO ] VB2:vb2api_ec_sync() ec_sync_phase2(ctx) returned 0x10000001
[INFO ] Saving nvdata
[ERROR] EC software sync failed (0x10000001), rebooting
[INFO ] board_reset() called!
[INFO ] full_reset() called!
```
Change-Id: Id7bfa620e8c19d5b162b60e5cc37003ff339b589
Signed-off-by: Pranava Y N <pranavayn@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87427
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add implementation of sku_id function that reports the SKU ID
information by making use of ChromeOS EC host command. This function
can replace redundant sku_id function definitions across boards that
rely on ChromeOS EC host command to report the SKU ID information.
The boards that relying on ChromeOS EC host command for SKU information
without any board specific quirks can select EC_GOOGLE_CHROMEEC_SKUID
to make use of common sku_id function.
Brya, zork, rex, fatcat, brox and dedede boards select
EC_GOOGLE_CHROMEEC_SKUID to use ChromeOS EC sku_id function.
BUG=b:396366352
TEST=Verify zork and brya boot log reports the correct the SKU ID
information
Change-Id: I958cc88bf316dd2327b6545c5a37e8010e96c5d7
Signed-off-by: Aamir Bohra <aamirbohra@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
ChromeEC support information for SKU, OEM name and manufacturer name
using EC host commands. Instead of tying it up with SKU ID Kconfig
define a new Kconfig that clearly describes and allow adding support
for SMBIOS APIs based on ChromeEC host command.
BUG=b:396366352
TEST=Verify ec_smbios still compiles for required boards.
Change-Id: I665a3276aa6dc01571657359d17f292efc601d63
Signed-off-by: Aamir Bohra <aamirbohra@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86993
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch modifies the get_lid_switch() function to allow faking the
lid switch state when the GBB_FLAG_DISABLE_LID_SHUTDOWN Kconfig option
is enabled.
When GBB_FLAG_DISABLE_LID_SHUTDOWN is enabled, the function will
always return 1 (lid open), bypassing the actual lid switch state
retrieval from the Embedded Controller (EC).
This functionality is specifically designed to facilitate factory
processes, such as netboot image downloads, where devices need to
remain operational regardless of the lid's closed state. This prevents
intended shutdowns triggered by a closed lid during manufacturing and
testing.
By setting GBB_FLAG_DISABLE_LID_SHUTDOWN, we override the actual
lid status with a simulated LID status is open, which is a
prerequisite for display initialization.
w/o this patch:
```
[ALERT] Graphics hand-off block not found
...
[INFO ] NAME | PORT | POLARITY | VALUE
[INFO ] lid | undefined | high | low
```
w/ this patch:
```
[INFO ] NAME | PORT | POLARITY | VALUE
[INFO ] lid | undefined | high | high
...
[INFO ] framebuffer_info: bytes_per_line: 7680, bits_per_pixel: 32
[INFO ] x_res x y_res: 1920 x 1200, size: 9216000 at 0xd0000000
```
BUG=b:333982806
TEST=Verified lid switch behavior with and without
`GBB_FLAG_DISABLE_LID_SHUTDOWN` enabled.
Change-Id: I89d506ab50b421b93be13b0e5e36a7ef1247e2b9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86807
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The EC code will monitor Body to choose corresponding DPTF oem variable
table. When it changes, this event will send to the ACPI FW through host
event and then pass onto the DPTF kernel driver.
BUG=b:394177292
BRANCH=firmware-trulo-15217.771.B
TEST=emerge-nissa coreboot
Change-Id: I7ed72157d3480fca5fd1a58b5d9bc3e321f4a628
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Because the AGAH EC code is based on monitoring adapter current to
choose the corresponding DPTF OEM variable table, but not every
project follows this design. Based on the comment below, the AGAH
EC code was removed in 2023, so remove the AGAH DPTF OEM variant,
allowing each OEM to adjust in EC ASL accordingly.
BUG=b:394177292
BRANCH=None
TEST=None
Change-Id: I2929eaa65a518b06f32e33cc31ae4a01bcfb77e8
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86493
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit renames the `google_chromeec_do_early_poweroff()` function
to `platform_do_early_poweroff()`, aligning it with the API that adds
early power off support using the Chrome EC.
It selects the `HAVE_EARLY_POWEROFF_SUPPORT` Kconfig option for platform
to perform early power off procedures.
Change-Id: I0c634d69de36fe8bdb6a61c121e321d3626ac3ff
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This commit implements the `google_chromeec_do_early_poweroff`
function for the Chrome EC. This allows the system to power
off before memory initialization by triggering an EC reset
with EC_REBOOT_COLD_AP_OFF.
BUG=b:339673254
TEST=Able to build and boot google/brox.
Change-Id: Ia53469feb2a020b38a5414728159b09c86c7e32d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86337
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Improve host EC command debugging with timestamps and duration for
better analysis, this feature can be enabled by selecting the config
EC_GOOGLE_CHROMEEC_HOST_CMD_DEBUG.
BUG=none
TEST=Brox/lotso device successfully built and booted. Debug messages
confirmed in device logs only when the specific configuration is
selected. Sample print: "EC HOST CMD Duration: 661 us, Command: 0x4b,
version: 0x0"
Change-Id: I8ab89830ede940d2237ad21187b137dca9689fb0
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This commit introduces an automatic linkage between the Microchip
EC (EC_GOOGLE_CHROMEEC_MEC) and ACPI memory
mapping (EC_GOOGLE_CHROMEEC_ACPI_MEMMAP) options. This linkage is
enabled when the Microchip EC is selected.
Certain data registers in Microchip ECs cannot be accessed via I/O
space. Instead, an indirection mechanism is required for register
access. When using such an EC, coreboot must publish ACPI information
to access these data registers through ACPI data ports 66h/62h.
Analysis of the coreboot codebase has revealed that the
EC_GOOGLE_CHROMEEC_MEC and EC_GOOGLE_CHROMEEC_ACPI_MEMMAP options are
consistently used together. This commit streamlines this dependency by
linking the two options.
TEST=/sys/class/power_supply/BAT0/* reports consistent values on
fatcat board.
Change-Id: Ib4120a6d0ba2f4785e8b07b33943010e58bcbdd3
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85886
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support for the generic LPC memory range configuration
in the EC ACPI code.
If CONFIG_EC_GOOGLE_CHROMEEC_LPC_GENERIC_MEMORY_RANGE is enabled, the
EC will use the generic LPC memory range for EMEM related communication
between EC and AP Firmware. This is useful for platforms that do not
have a dedicated IO range like accessed EMEM through port 62/66 or
through LPC at 900h.
The generic LPC memory range is defined by the _SB.PCI0.LPCB.GLGM()
method. This method returns the base address and size of the memory
range.
Update the comment section to reflect the alternative source for EMEM
data when CONFIG_EC_GOOGLE_CHROMEEC_LPC_GENERIC_MEMORY_RANGE is enabled.
BUG=b:354066052
TEST=Build and boot on a device with
CONFIG_EC_GOOGLE_CHROMEEC_LPC_GENERIC_MEMORY_RANGE enabled.
Change-Id: I8038e2827ec7e301bad3a5a58df007f3a448bad7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit introduces a new function,
google_chromeec_is_barrel_charger_present(), which checks if a barrel
charger is present.
The function uses the following logic to determine if a barrel charger
is present:
- If both a barrel charger and USB-C PD are present, then the barrel
charger takes precedence over USB-C PD. As a result,
google_chromeec_is_usb_pd_attached() will return false. This logic can
be used to deterministically say if a barrel charger is present even
when both a barrel charger and USB-C PD are attached.
- If an AC charger is detected and USB-C PD is not present, then a
barrel charger must be present.
This change allows the EC to accurately detect the presence of a barrel
charger, even when a USB-C PD charger is also attached.
BUG=b:377798581
TEST=Able to read the charger status correctly while booting
google/fatcat.
Experiment #1:
- USB-C PD Attached = yes
- Barrel Attached = No
- Charger Detected = Yes
```
fatcat-rev257 ~ # cbmem -c | grep -5 "ac_charger_present"
[INFO ] ac_charger_present: yes
[INFO ] usb_pd_present: yes
[INFO ] baseboard_devtree_update: Barrel Absent
```
Experiment #2:
- USB-C PD Attached = No
- Barrel Attached = Yes
- Charger Detected = Yes
```
[INFO ] ac_charger_present: yes
[INFO ] usb_pd_present: no
[INFO ] baseboard_devtree_update: Barrel Present
```
Experiment #3:
- USB-C PD Attached = Yes
- Barrel Attached = Yes
- Charger Detected = Yes
```
[INFO ] ac_charger_present: yes
[INFO ] usb_pd_present: no
[INFO ] baseboard_devtree_update: Barrel Present
```
Experiment #4:
- USB-C PD Attached = No
- Barrel Attached = No
- Charger Detected = No
```
[INFO ] ac_charger_present: no
[INFO ] usb_pd_present: no
[INFO ] baseboard_devtree_update: Barrel Absent
```
Change-Id: I9644f0dec057f95bb0a22cdc18edc1a0234ee3a9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This patch adds a new API `google_chromeec_is_below_critical_threshold()
` to check if the battery level is below the critical threshold.
The API uses the existing `ec_cmd_battery_get_dynamic()` command to
retrieve the battery flags and checks the `EC_BATT_FLAG_LEVEL_CRITICAL`
flag to determine if the battery level is critical.
This API can be used by other components to query the battery critical
status and take necessary actions, for example, while the system is
booting with low battery fuel with and/or without an AC
charger attached.
This addresses the need to implement a low battery charger icon and
detect when the system is booting with low battery fuel. The existing
`google_chromeec_is_battery_present_and_above_critical_threshold()`
API is not suitable for this purpose because any negative decision
(like battery not present and/or battery is critically low) implemented
around this existing API will also render the lower battery indicator
when the system is booting into battery cut-off mode. Ideally, we do not
wish to render any icon and simply allow boot to the OS during system
battery cut-off boot.
BUG=b:377798581
TEST=Able to read the battery status correctly while booting
google/fatcat.
Change-Id: Id1fc1df374fb4c663becc371c69b285d8b9957ff
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85759
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This patch introduces a new API, `google_chromeec_is_charger_present()`,
to determine if a charger is connected.
The API leverages the existing `ec_cmd_battery_get_dynamic()` command
to retrieve battery flags and checks the `EC_BATT_FLAG_AC_PRESENT`
flag to ascertain charger presence.
Other components can leverage this API to query the charger status,
which is particularly useful for distinguishing between barrel chargers
and USB-C chargers after relying on the
`google_chromeec_is_usb_pd_attached()` API.
BUG=b:377798581
TEST=Able to read the charger status (w/ barrel and/or w/ USB-PD)
correctly while booting google/fatcat.
Change-Id: Iadf81400f71a51c093f71fe995cacc107c50c7af
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85758
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change introduces a new API, `google_chromeec_is_usb_pd_attached()`
which checks the current status of the USB-C port and returns whether a
USB Power Delivery (PD) charger is currently connected.
This API is useful for determining if the system is currently being
powered by a PD charger.
BUG=b:377798581
TEST=Able to read the PD status correctly while booting google/fatcat.
Change-Id: I47c934ee8a7563d4ba5124bff5613e61dd66e923
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Add support for indexed IO for ec communication, Indexed I/O allows
memory access using a single I/O port base address usually called an
index register and another port address called a data register.
BUG=b:379224648
TEST= able to build nissa/trulo.
Change-Id: I6c1aab3fc914eb5af2736a8ea3adf447040905e0
Signed-off-by: Jayvik Desai <jayvik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This change allows the Chrome EC (CREC) ACPI device to publish the LPC
Generic Memory Range (GMR) address range using the _CRS method.
The Google CREC driver can now parse this information to determine the
MMIO address map, enabling access to the LPC GMR register space.
This addresses the issue where the CREC driver was unable to
automatically determine the LPC GMR base address.
TEST=Able to build and boot google/brox.
without this patch:
brox-rev0 ~ # cat /proc/iomem | grep fe0
fe000000-fe00ffff : INTC1026:00
fe000000-fe00ffff : intel_scu_ipc
fe03e000-fe03efff : 0000:00:1e.0
fe03e000-fe03e1ff : lpss_dev
fe03e000-fe03e1ff : serial
fe03e200-fe03e2ff : lpss_priv
fe03e800-fe03efff : idma64.4
fe03e800-fe03efff : idma64.4 idma64.4
with this patch:
brox-rev0 ~ # cat /proc/iomem | grep fe0
fe000000-fe00ffff : INTC1026:00
fe000000-fe00ffff : intel_scu_ipc
fe03e000-fe03efff : 0000:00:1e.0
fe03e000-fe03e1ff : lpss_dev
fe03e000-fe03e1ff : serial
fe03e200-fe03e2ff : lpss_priv
fe03e800-fe03efff : idma64.4
fe03e800-fe03efff : idma64.4 idma64.4
fe0b0000-fe0bffff : GOOG0004:00
Change-Id: Ib3ea3e2a482f9eceaa8c15e38b7e708b156bc978
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85603
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change simply replaces 0x80 with a top level constant called
ACPI_NOTIFY_CROS_EC_MKBP. There are no functional changes.
BUG=b:343288326
TEST=Build
Change-Id: Ia476263620acc269f9dd8a6b3c9e5e247b403aee
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Boris Mittelberg <bmbm@google.com>
