Oh man. This is my fault. Your feedback is really helpful and I’ll try to correct the error.
1 Like
there’s no need to update if you are already running the 2021-08-03_05d9990 release, it’s identical to that on the live ISO other than the version string. We’ll be tagging future releases to avoid confusion going forward
3 Likes
sorry, how do I check this?
2 Likes
as per the last bit of the instructions (either set) - by running sudo purism_ectool info
2 Likes
That returns…
sudo: purism_ectool: command not found
2 Likes
well of course, you have to follow the part of the directions to download/extract the tool, as it’s not part of PureOS. If you’re booting the update USB/ISO, the tool is already installed. And if you’re downloading/running it on a live system, you’d use ./purism_ectool since it’s not installed in a location in the system path
2 Likes
Ah, sorry, forgive my newbieness 
2 Likes
Thanks for the guide! I was just able to go through the process, and was happy with how easy and quick it went. 
I believe there is one more L in the word “controller” (I double checked this wasn’t a cool “referer” thing, but I’m not from the embedded hardware world, I don’t know how cool kids there spell. 
)
1 Like
Purism_Librem-EC v1.9 is out. Lot of fixes.
2022-06-30
- Reduce audible noise when charger is connected
- Fix fans running at full speed when resuming from S3
- Fix battery not charging due to improper 3-cell/4-cell configuration
- Start fans at low speeds slightly earlier to maintain temperature
- Reduce PL4 power limit when battery below 40%
- Set default charger limit for 90W charger
- Warn with orange LED instead of cutting power for battery charge alert
- Improve robustness of charger parameters
- Improve robustness of battery probe and status updates
5 Likes
When running sudo ./purism_ectool flash ec-1.9_2022-06-30.rom, I get an error and then my machine immediately reboots (probably to restore the backed up v1.7 ec firmware).
Am I doing something wrong with applying this update? I am very excited to see if this update solves the coil hum issue my Librem 14 has (and so is my partner, who has much more sensitive ears than I).
1 Like
I not have my Librem 14 just now to tell exact syntaxis.
Just execute the option flash_backup instead flash so like:
./purism_ectool flash_backup ec-1.9_2022-06-30.rom # check that option to make sure.
1 Like
It would be helpful if you posted what the error was.
1 Like
The issue I was having was that running the above command gave me ~2 seconds post-failure before a hard reboot. If I recall correctly, it was an expect error (something like ‘5 is not 0’). However, running ./purism_ectool flash_backup ec-1.9_2022-06-30.rom instead of ./purism_ectool flash ec-1.9_2022-06-30.rom did in fact allow the update to succeed. I’m still unsure of the differences between these two subcommands (as they are not documented anyware, AFAICT), but at least I was able to apply the update. Thanks for You help, @carlosgonz and @Gavaudan!
2 Likes
Seems there is a new version.
Purism_Librem14-EC v1.12 (2023-02-20-64b01ec9)
2023-02-20
- Set PL4 again when CPU resumes from a sleep state to address sudden shutoffs
1 Like
Just updated EC to version 12… hoping to address some of the strange charging behavior I’ve been dealing with. I’m still trying to figure out how to consistently reproduce this, but is anyone else out there have their Librem abruptly power off when you disconnect the barrel jack to the power supply? It seems like it happens to me when the battery power is high (above 90%).
1 Like
My Librem14 does not abruptly power off at any time, however i will test like disconnecting the barrel jack power supply above 90% just to checking…
1 Like
This has been happening to me as well. It usually happens after the laptop has entered and is exiting sleep mode, where it shouldn’t have lost much power at all.
I flashed this back in March 2024 but it’s still acting funky. The charge_max_design sysfs attribute is like 8 million units, while charge_full is dipping as low as 2 mil. As charge_now goes up, sometimes the charge_full does, too.
I learned this with a simple watch script:
watch -n 5 cat /sys/class/power_supply/BAT0/charge_now /sys/class/power_supply/BAT0/charge_full
At present, it sometimes stops charging at weird intervals; 40-something%, 60-something%, and expected behavior in the 90s (I put the threshold between 90% and 100%) But when I unplug it, both charge_now and charge_full go down, when it’s really only one of them that should be going down, unless I somehow have a rapidly deteriorating battery… That doesn’t make sense because I’ve only used the official barrel charger…
I’m going to try another EC flash today to see if maybe it just got into a loop of confused state. dmesg notes numerous unhandled ACPI 80 and 81 codes coming from battery, but all I could find on those events were on- and off-battery, and normal. Sorry to bump a dead thread but this seems to be an on-going problem.
I’m on Gentoo running kernel 6.6.21, but this happened on 5.10.212 as well. I have tried calibrating the battery by letting it die and leaving it on the charger overnight, to no success.
EDIT: Last night, capacity started going back up to around the 6700000 mark. I put it to sleep overnight, but when I woke it up, it turned off as if it were losing power, and did so again when I tried to boot it without plugging it in. When I plugged it in and booted, it showed 60% battery and has been charging rather normally since.
I’m using acpid and laptop-mode-tools, and have scripts mapped to only the lid and sleep button. Both end in the echo "mem" > /sys/power/state and, when on power, resume just fine.
1 Like
This has been perplexing me for quite a while, still struggling with battery oddities. I have re-flashed the EC using Purism’s official ISO for it, and verified purism_ectool could see it. My Gentoo system cannot appear to see the EC, even with librem_ec_acpi built and installed. It seems like it’s looking in the wrong place for something.
Seeing as this is Gentoo, I’m not afraid to get my hands dirty if I need to compile something, but every attempt thus far had led to the same results of an inconsistently reporting battery that factually has the 6-8 hours advertised, but has issues communicating charge to the OS.
I took it further this time… Charge started at 89%, and reported around 3.8M out of 4.2M. When it hit 50%, charge_now and charge_max dropped, to roughly 1.89M out of 2421000, which is barely over a quarter of the battery’s actual capacity! This continued until it reported 38%, when the 2421000 became 4843000 and the charge_now stayed around 1.89M . charge_now steadily went down at this point, until the 1000 mark. It reported 0% for over 3 hours of runtime after this point, left open and idling. I went to bed, and by the time I woke up, it was dead.
I charged and left it alone all day, then turned it on. The date was in 1970, so I set the hwclock, rebooted, things worked. Battery reported 54% and a charge_max currently at 4048000, which is roughly half what it should be and factually incorrect compared to the total runtime.
When I attempt to run purism_ectool info as root, I get this:
failed to connect to EC: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
To reiterate, the EC is correctly installed and reports as such via the flashing ISO. I’ve built and installed the librem_ec_acpi module via dkms, and it must work to some degree because my thresholds show up, where they didn’t before.
Currently on kernel 6.6.47. Perhaps @nicole.faerber or another EC dev can help me isolate the cause here?
1 Like