Librem 14 Failed to charge SOLVED

yes, because the values are saved in the EC’s battery-backed RAM (BRAM). As long as the internal battery isn’t disconnected, the settings will persist until overridden externally


Finally the solution provided by the support was to install the firmware using dkms instead of make (for non Debian distributions).

After cloning or downloading the source from the link provided by the support, follow instructions below.

Copy the Debian dkms.conf to the root of the source directory:

cp debian/librem-ec-acpi-dkms.dkms dkms.conf

Modify dkms.conf in a text editor so PACKAGE_VERSION is set to a value:


Add and build the module using dkms:

sudo dkms add ./
sudo dkms build librem_ec_acpi/1.0
sudo dkms install librem_ec_acpi/1.0

Now lsmod should show librem_ec_acpi:

lsmod | grep librem_ec_acpi
librem_ec_acpi         16384  0

You should also see new files to control the battery:

cat /sys/class/power_supply/BAT0/charge_control_start_threshold 
cat /sys/class/power_supply/BAT0/charge_control_end_threshold

Thank you @joao.azevedo :slightly_smiling_face:

there are already some non Debian distributions that have it packaged.

And there are some instructions for QubesOS:

And the librem-ec-acpi is now in Debian Experimental, so “soonish” it should start entering the DEB “world”

Check with the system monitor as stated in Youtube tutorial

I had to set the start and end thresholds again after installing the latest (4.14-Purism-1) coreboot update. The start was back to 0. Is there a plan to make the user defined battery charging settings persistent over the coreboot update?

1 Like

@MrChromebox ^^ :point_up:

1 Like

coreboot has nothing to do with the EC battery thresholds, updating coreboot would not change/clear them.

The most recent EC firmware update sets these to 90/100 as the default, so they should not reset back to 0/100 ever after applying it

@MrChromebox Thank you for the clarification. In that case I wonder what I did so these thresholds were reset. What I know I did was update coreboot with the coreboot utility script. And of course updates with apt. Could the latter have caused the reset?

if the kernel got updated, possible the EC driver did not persist across?

I do not know enough to answer that question… what I can say, is that I used the option to compile the update locally.