Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Configure EC from system firmware #571

Open
crawfxrd opened this issue Jul 25, 2024 · 1 comment
Open

RFC: Configure EC from system firmware #571

crawfxrd opened this issue Jul 25, 2024 · 1 comment

Comments

@crawfxrd
Copy link
Member

  • Feature name: sbios-ec-config
  • Start date: 2024-07-24
  • Status: Draft

Summary

Configure values controlled by the embedded controller from system firmware.

Motivation

Allow users to configure certain values, that are controlled by the EC, from
system firmware so they do not have to recompile and flash EC firmware with
their modifications after every EC release. These would be values that do not
need to be loaded at EC power-on, but rather only matter when the system
(system firmware (SBIOS) or OS) is running.

Such values could include:

  • Fan tables
  • Dynamic keyboard layout
  • Keyboard color
  • Keyboard brightness
  • Webcam power

Guide-level explanation

Reference-level explanation

All System76 laptops still use an 8051-based chip (ITE), which provides a very
limited environment to work with.

  • 8-bit architecture (8-bit data bus, 16-bit address bus)
  • Does not support standard C and requires compiler extensions
  • Limited toolchain (SDCC)
  • Limited code space (<256 KiB; <64 KiB without utilizing banking)
  • Limited RAM (<256 bytes IRAM, <2 KiB XRAM)

Drawbacks

  • Requires design of, and maintaining compatibility between, additional
    firmware (coreboot, edk2) and OS (system76-acpi) components
    • Already has to be considered, would just be more extensive
  • Does not handle cases where configurations must be applied before system
    firmware runs
    • Battery charging thresholds at EC power-on with system still in S5

Rationale and alternatives

  • These configs are only significant when system is in S0 and system firmware
    is running
  • Does not require modifying EC flash space at run-time
  • Reduces complexity of EC code by removing policy decisions from it
  • May allow saving/loading configurations from UEFI variable storage

EC manages policies for mechanisms it controls

The current situation; Policies are tightly coupled with mechanisms. Many
configurations are determined at compile-time by Makefile variables, defines
being set/unset, and hard-coded tables in the EC code.

Only some values can be updated at run-time, with most not being persistent
across EC reset. The dynamic keyboard layout is made persistent by modifying
EC flash space at run-time.

Proposals for this are included in:

Prior art

  • chrome-ec
    • I don't know how it works exactly, but its use of DPFT implies it can
      defer policies to UEFI or the OS
  • sysfs
    • Linux drivers can expose functionality such as fan control through sysfs
      attributes.

Unresolved questions

Future possibilities

Persistent configs

As noted in the rationale, configurations could be stored in UEFI variables to
make them persistent. This may be minimal work on top of implementing this RFC
if implemented in edk2.

@crawfxrd
Copy link
Member Author

Consideration: Power switch is "a key on the keyboard".
Example: HP Dev One

HP Dev One is an example of a model with the power switch being "a key on the keyboard". However, the switch is a dedicated pin (GPIO7E/KBC_PWR_ON) and is not tied to the keyboard matrix.

Every unit I've seen with this has a fixed, non-removable keyboard. They are designed to look like the key is part of the keyboard, but likely always use a dedicated pin. They function the same as any model with a removable keyboard and the power switch separate from the keyboard.

But if they ever do, besides ridicule and condemnation for the ODM, the switch shall be determined by its matrix position and not mapped through a layout; see next case.


Consideration: Key combo is used at power-on to modify boot flow.
Example: Fn+Esc to reset configs

At power-on, before system firmware starts, the EC may need to detect certain combination of held keys to alter boot flow. We currently use Fn+Esc to reset configs to default. Lenovo uses Fn+R to enter Crisis Mode, which likely involves the EC.

These combinations shall be determined by the position of the keys in the matrix (physical keyboard locations), and shall be not mapped through the keyboard layout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant