-
Notifications
You must be signed in to change notification settings - Fork 95
Description
- 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:
- RFC: Enable user-configurable settings including Fn Lock, Debounce, etc
- RFC: Persistent run-time configs
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
- I don't know how it works exactly, but its use of DPFT implies it can
- sysfs
- Linux drivers can expose functionality such as fan control through sysfs
attributes.
- Linux drivers can expose functionality such as fan control through sysfs
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.