You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
sbios-ec-config
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:
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.
Drawbacks
firmware (coreboot, edk2) and OS (system76-acpi) components
firmware runs
Rationale and alternatives
is running
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
defer policies to UEFI or the OS
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.
The text was updated successfully, but these errors were encountered: