Y’all might be better served by discussing this in a separate thread, since it’s diverged quite a bit from a discussion about the embedded controller. 
5 Likes
Hello! Do you know if the ectool in https://github.com/DHowett/framework-ec work with 12th gen mainboards as well?
I came across this thread looking to see if I could control battery levels in user-land on 12th, and it’s not entirely clear if it would work or not (or end up breaking something badly!).
1 Like
Yup, it should work fine!
4 Likes
I’ve looked at the current framework-ec repository and it looks like it has quite a few prerequisites for cross-compiling the firmware. The ectools utility is tucked away in the utils directory, and I assume it does not need cross-compilation. How difficult would it be to extract that one utility from the whole repository so that it can be built by itself, without the heavy prerequisites that are required for the full framework-ec repo?
1 Like
Thanks! Indeed, make utils does the trick, although with a bunch of warnings that one can ignore, as it turns out. It results in a dynamically linked executable ectool, but as far as I can see it’s just linking to the c-library, so once built, the executable should be relocatable and runnable without special environment requirements.
The repo is rather huge (about 150Mb) for such a small tool, but that’s a relatively minor issue. A lot of it is documentation and git history, actually.
At the moment the interface is a bit rough because it’s mainly a generic tool, so there are a bunch of options that don’t actually apply to the Framework EC.
The most useful command is probably the convenience option Dustin added:
sudo ./ectool --interface=fwk fwchargelimit ...
One option I found that does seem to work as well, and may be useful is:
sudo ./ectool chargecurrentlimit ...
It allows capping the charging rate for the battery. If it is indeed the case that fast charging is a little damaging to Li-ion batteries, it may make sense to lower this a little in situations where charging doesn’t need to be super-fast. Does anyone have insight into what good ranges for the value would be?
I’ve noticed that under normal conditions, Framework is quite happy to charge at a rate of 30-40W so that’s somewhere in the 2600mA range. That means your battery is basically fully charged within 1-2 hours, which is nice. However, there are scenarios where one may be perfectly happy with a much slower rate (e.g., you come home and let it charge overnight). Is there benefit in lowering the cap? Is it possible to damage things by setting the cap higher than it should be?
3 Likes
I’m just referring to the average W you compute by taking the difference in mAh of charge of the battery one minute apart and multiply it by 15.4V/60(h/min) [sticking with 15.4V being the design voltage for the battery]; not the actual power pulled from the wall.
1 Like
I would like to use the power led in windows like a hdd activity monitor.
Does somebody know the address that is used for controlling the leds?
I can’t find it in the EC source…
1 Like
1 Like
I made a little application that uses DHowetts CrosEC driver for windows and turns the power led into a storage activity indicator.
This is mainly for my own use but if someone misses the hdd led as much as me: https://github.com/Matze5800/fw_led/releases
You have to install the driver first: https://github.com/DHowett/FrameworkWindowsUtils/releases
5 Likes
Is it possible to port Zephyr to it?
THIS IS SO COOL! You’re the first person I’ve heard of who is using my CrosEC driver in any capacity. I realize now that I should probably publish a NuGet package containing the header so that you don’t need to carry around a copy of the source in your repository.
The interface is intended to look a bit like the Linux cros_ec interface so that applications can be roughly portable between the two operating systems.
Please feel free to file issues–or pull requests!–if there’s anything you need.
One of the upstream EC maintainers started working on a port of the hx20-specific bits to mainline, which would almost certainly build with Zephyr. His work is here. Nothing may come of it, but it looks like the ChromeOS folks are pretty excited about it.
3 Likes
Love to see this spun off into its own thread and a guide to getting it working on Windows.
I really dislike not having an activity monitor…
1 Like
Has anyone gone through a self-signing procedure for the CrosEC driver on Windows?
I’m guessing it’s something like this?
FWIW, I do distribute the driver with a code signature. Unfortunately, not even putting a certificate in the system trust store will allow the kernel to load a driver signed with that certificate outside of test mode.
Self-signing may provide you peace of mind (though, if you’re trusting the binary without building it locally but intend to self-sign it, it is somewhat moot), but it will not lift this restriction.
Windows will only load (outside of test mode) drivers that are signed with an EV identity and then further cross-signed by Microsoft.
1 Like
Obvious maybe but fancontrol, battery levels, led colors work as expected on my 12th gen framework. Thinking about some controls in i3 to controll the fanspeed maybe and let the leds reflect some statuses (do they under windows? and why dont we have blue? could I add a led?)
1 Like
I have tried this fork and the original and I just can’t get fw-ectool to work. I am running Debian bookworm and installed libusb-1.0-0-dev and libftdi-dev to fulfill build dependencies. Then I built the package with make utils. Both in the original and the fork, I get this error:
sudo build/bds/util/ectool --interface=fwk version
Cannot open lockfile /run/lock/cros_ec_lockCould not acquire GEC lock
(Obviously, in the original, --interface=fwk doesn’t work, so I didn’t pass that.)
What am I doing wrong?
3 Likes
I love the EFI driver, but how can I do the mapping of ESC to caps look in the EC?
I too am getting:
$ sudo ./build/bds/util/ectool version
Cannot open lockfile /run/lock/cros_ec_lockCould not acquire GEC lock.
$ git log -n1
commit d5b5b5008d2f98400206deb182e8ce772b6df9df (HEAD -> main, origin/main, origin/HEAD)
Author: Dustin L. Howett <dustin@howett.net>
Date: Tue Apr 12 08:14:25 2022 -0500
Remove COMM_FWK, but keep --interface=fwk as an alias for lpc
UPDATE Without recompiling it started working. I suspect a kernel update.
For reference it is now working for me with kernel 5.15.0-52-generic
2 Likes
I finally set up this tool today and it’s great! It was so simple to set it up, and being able to change the charge threshold with a simple command in the terminal is incredibly useful.
I am stumped on one thing already though, which is how to use the one-shot full charge from the command line. I do get the impression it was implemented from different parts of the thread.
Here, it was discussed how there is a high bit which allows the charging limit to stay in place, but a one-off exception will be made to give it a full charge:
Here there is a screen snip of a GUI version of the tool which appears to have this feature as an available option:
I read through all the available commands in the built-in help tool and have poked around in the online documentation, but I still can’t quite figure out if this feature is available from the command line.
It’s no hardship to run sudo ectool fwchargelimit 100 and then just run it again to set the charge threshold back where you had it after the battery is fully charged, but since I saw it mentioned in the thread I thought I would ask in case I am just missing something.
2 Likes