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

Add ability to configure some important coreboot config settings #1647

Open
UndeadDevel opened this issue Apr 21, 2024 · 3 comments
Open

Add ability to configure some important coreboot config settings #1647

UndeadDevel opened this issue Apr 21, 2024 · 3 comments

Comments

@UndeadDevel
Copy link
Contributor

Is your feature request related to a problem? Please describe.
See Dasharo/dasharo-issues#285 (coreboot allows configuring battery charging limits both from the BIOS as well as the OS); this used to work in Heads 2.1 for me as well on my NV41.

See Nitrokey#35 (Setting battery charging limits worked in NK Heads 2.1, but not anymore in NK Heads 2.4 and 2.4.1). In that issue @daringer says that it's an upstream issue with Heads.

Describe the solution you'd like
Allow configuring battery charging limits (and possibly other coreboot configurable settings) from within Heads or the OS.

Describe alternatives you've considered
Unfortunately right now there doesn't seem to be an alternative other than removing Heads and using Coreboot (or going back to Heads 2.1). The usually suggested solutions online, e.g. tlp or smbios-utils all require that the firmware make the relevant system files, usually /sys/class/power_supply/BAT0/charge_control_start_threshold and /sys/class/power_supply/BAT0/charge_control_end_threshold, available to the OS, as that is how those utilities set the new limits.

Additional context
The focus is on the battery charging limits, as that's not just a convenience feature, but also important to help preserve battery life for laptop users.

@tlaurion
Copy link
Collaborator

tlaurion commented Apr 22, 2024

@UndeadDevel im confused.

If I understand this correctly, the feature is not implemented by coreboot, nor ed2k, but the EC firmware. Coreboot is responsible to expose acpi tables of EC, and then the system76_acpi kernel module is injected by OS if ids match, system76_acpi kernel module exposes the additional thresholds files under BAT0, which tlp can interact with at runtime?

So my understanding is that EC firmware doesn't have those thresholds fixated, and something went south to match what system76_acpi kernel module is looking for to expose those for user customization only from ed2k, hence the regression.

This is a simple hypothesis, but if low level stuff was there in EC, and compatible with system76_acpi kernel module (not causing regression), THEN it would mean that Heads could pack this additional required kernel module as well, and have a nice configuration menu added to change those values from Heads which would change EC values. Same for fan speeds.

Why system76_acpi kernel module (most probably is not loaded anymore because I'd mismatch) does not expose the configurable thresholds anymore?

Probably related #1639 (comment)
@pietrushnic? Cc @macpijan @macpijan

@tlaurion
Copy link
Collaborator

tlaurion commented Apr 22, 2024

Most probable solution to the ec problem Dasharo/coreboot#481 and then integration under heads:

  • include functional system76_acpi kernel module able to interact with EC
  • create dynamic menus, probably on presence of kernel module packed under modules.cpio or by export in board config

@UndeadDevel thanks for opening issues upstream here and linking to downstram issues.

@tlaurion
Copy link
Collaborator

That's Dasharo/dasharo-issues#820

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

2 participants