Thanks for this! I’ve packaged it up as Nix Flake at tlvince/ectool.nix and can confirm it works fine on a Framework 13 AMD 7640U.
4 Likes
I also tried building from the new ectool repo, also ran into this compiler error using gcc (typical linux default, in my case very recent gcc-13.2.1)
src/ectool.cc:966:1: sorry, unimplemented: non-trivial designated initializers not supported
It’s an easy fix though:
--- a/src/ectool.cc
+++ b/src/ectool.cc
@@ -955,6 +955,7 @@ static const char *const ec_feature_names[] = {
[EC_FEATURE_REFINED_TABLET_MODE_HYSTERESIS] =
"Refined tablet mode hysteresis",
[EC_FEATURE_EFS2] = "Early Firmware Selection v2",
+ [EC_FEATURE_SCP] = "System Companion Processor",
[EC_FEATURE_ISH] = "Intel Integrated Sensor Hub",
[EC_FEATURE_TYPEC_CMD] = "TCPMv2 Type-C commands",
[EC_FEATURE_TYPEC_REQUIRE_AP_MODE_ENTRY] =
I’m not sure if it would be appropriate to create an account on DHowett’s Gitlab instance to open a PR, this seems to be from upstream anyway? Actually, how was I able to compile from the old github framework-ec repo, it seems to have the same array? … is it just because in the old repo it was C, and in the new one it’s .cc aka c++? hmm …
EDIT: Yeah, it’s because it’s being compiled in C++ mode in the new ectool repo. Designated initializers are a C99 feature, and much more recent and a bit more limited in standard C++.
2 Likes
Thx that actually helped.
I do hope the cors_ec chages get merged upstream soon so that’ll work out of the box.
I wonder if that would also make charge limits work with tlp and stuff.
Sorry about that, and the delay in fixing it. The upstream project may have missed this when they moved to C++. I pushed a fix in 3ebe7b8.
5 Likes
@DHowett what is the status of your fork of EmbeddedController?
I’m asking because I see that your main branch is 710 commits ahead and 10098 commits behind the forked project and your last commit is from a year ago. What I’d like to do is use the fwchargelimit, has there been any interest in pushing your changes upstream?
– Wink
Thriving! I use it to submit pull requests to Framework.
If you’re asking about the build of ectool from that repository, however: it is not undergoing active development, as the bulk of the work has moved to a different repository with a much less annoying build system and more support for Windows, which also by chance tracks upstream¹ much better.
Unfortunately, that’s a bit of storytelling on GitHub’s part. My main branch tracks Framework’s hx20-hx30 branch (or the old hx20 branch), but GitHub believes it should be tracking Framework’s main branch. Well, unfortunately, Framework’s main branch is a point-in-time snapshot of Google’s upstream EC repository’s main branch.
This means that any work based on Framework’s code is already wildly out of date with Google’s as they forked the EC nearly three years ago. But also, that’s not a problem because it is tracking just fine against Framework’s hx20-hx30 branch.
But also, that doesn’t matter since ectool doesn’t change all that much. The version of ectool in that repository is entirely acceptable for the hx20 and hx30 (Intel 11th and 12th generation) as well as the AMD Framework Laptops (with the requisite kernel patches.)
I’m not intending on upstreaming fwchargelimit to either Framework or Google, for a couple reasons:
ectoolis really just a diagnostic utility. It’s a veritable swiss army knife, but it is not an API and it is not a contract.fwchargelimitis specific to a single OEM, and is built on the embedded controller’s support for OEM “host commands.” It would do unpredictable things on the majority of machines thatectoolsupports.
The right path forward is to use system-specific support libraries like this one from Framework Computer themselves, or device-specific kernel modules that integrate things like charge limits and LED control into the parts of the system where they actually belong.
Now, in the meantime… Dustin L. Howett / ectool · GitLab ships binaries for Linux-x64 and Windows
Hope that helps!
¹ Google, not Framework.
3 Likes
Are you planning to submit this to platform x86 after your other patch series lands?
@DHowett, txs for the info!
Since I happen to like and use Rust for my own programming it seems I should be able to easily clone and build framework_tool are there any gotchas I should worry about?
I don’t feel that it’s quite up to quality for upstream yet–I need to learn a bit more about platform driver binding before I’m comfortable submitting it, for example–but it is my intent to upstream it!
Alas, I’m not sure. I’ve not tried out framework_tool myself!
If you’re using an AMD Framework Laptop, framework_tool will probably not work until this kernel patch series lands and the kernel version containing it hits stable.
2 Likes
If you want some help or reviews for it, feel free to contact me.
1 Like
Hi everyone! just wanted to share my little github project i’ve been working on.
A script to change the color of the power button LED based on battery level, everything is on this git repository all you need to do is run one command.
I have not tested it in every distro but i know it is working on Fedora and KDE Neon, so from there we can deduct it will work on Ubuntu.
Feel free to file some bug reports!
4 Likes
FYI, I installed the framework_laptop module (GitHub - DHowett/framework-laptop-kmod: Kernel module to expose more Framework Laptop stuff) on Debian 12 (with the sid 6.6.8 kernel), and it works seamlessly: the battery charge setting just appears in the KDE power management settings page.
5 Likes
@DHowett
I have just been reading through the topic, I just wanted to clarify:
Are you currently working on a Windows tool/GUI making these features easier to use for the average Joe? (I think the answer is yes, I just wanted to check) (Also - you are going to try and get it signed?)
If wa ting to play with these tools in a Windows environment on AMD board, what is the best link to follow for info? (The link on your site to the ‘ectools’ git is dead)
Does the fan limit persist over multiple boot cycles? Am I also right to assume that any/all changes to the EC reset/do not persist if test mode is re-enabled?
Thanks, I saw that in the git and clicked on it but could have sworn it didn’t have that nice readme. 
Thanks for submitting the dkms.conf change! I’ve been waiting on the holidays to be over to review my PR queue. 
I was at one point working on a GUI for it; however, I lost motivation to continue working on it. I’ll prepare and publish the source for that at some point.
Huh, I wasn’t aware that I had a dead link there. Thanks for letting me know!
The Windows driver, CrosEC.sys, has been updated to support the AMD framework laptop. You can get a Windows build of ectool from the windows/x64 build artifacts from the artifacts page in my ectool repository.
I am still pursuing signing¹ but in the meantime there is a fully signed driver that exposes the same userland I/O interface and is compatible with Windows ectool by coolstar, here. It currently only works on 11th, 12th and 13th generation Intel Framework Laptop 13 (with some modifications), but it’s mostly intended for stock chromebook devices running Windows. Any incompatibilities stem from the fact that it is not Framework Laptop-specific.
Any/all changes to the EC–apart from reflashing it!–reset when your computer fully powers down and is not attached to AC power. Test Mode is a specific configuration of the Windows operating system that allows the loading of untrusted kernel drivers; it has no impact on the EC itself.
¹ There are some limitations in the Windows driver model that may pose a problem; I would like to assess those before e.g. forming an LLC or something to get the right kind of signing certificate.
1 Like
I see, but I guess you could run a startup script that reset your changes when this occurred? But this would need test mode and/or signing I guess?
I also saw that NotebookFanControl had been looked into, but it used an incompatible method of adding the functionality… I was just wondering if ‘Fan Control’ By Rem0o had been looked in to? If functionality could be implemented into this application it would give us ‘dumb’ Windows users a very easy way to set the fan speed. For me I can follow a basic tutorial on running code, but I do not understand the nuts and bolts so can get hung up. I personally would like to be able to sacrifice performance for a limited fan curve/lower noise/never fully spinning up. I need to play around with the battery saver options in Windows to see if these work across battery/mains power etc but reading here seemed to suggest it was not completely consistent.
Hello,
I’d like to be able to control the power LED color and keyboard brightness on the framework laptop. I’m a bit confused as to which tool I should be using. Could someone point me to the best project for this use case? I’ve been using ectool from GitHub - DHowett/framework-ec: Embedded Controller firmware for the Framework Laptop. I’ve also seen framework_tool, which I’d love to use, but that doesn’t seem to support changing the power led color. Lastly, I’ve seen ectool from Dustin L. Howett / ectool · GitLab, but should I be using this one or the one from GitHub? Thank you for the help, and thank you for everything you’ve done so far in working on this @DHowett!
1 Like
@DHowett, do you have an idea when your cros_ec patchset will land in mainline?
As far as I can see it`s also not queued up for 6.9rc1?
It’s the last piece that is missing to have full kernel support for all Framework AMD features to work out of the box.
Thanks in advance!
3 Likes
Hi, I’m not sure if I’m misunderstanding something, but I can’t get ectool to work. First I tried cloning and building Dustin L. Howett / ectool · GitLab, but when I run
sudo ./ectool --interface=fwk fwchargelimit 70
I just get “Invalid --interface” and a “Usage” dump.
So I thought I cloned the wrong repository and it’s the generic ectool, not the Framework-specific one, and tried GitHub - DHowett/framework-ec: Embedded Controller firmware for the Framework Laptop instead. But it won’t let me easily build just the ectool, it demands Coreboot SDK to be installed which seems really unnecessary.
Meanwhile I found out about the prebuilt binaries in the first repo, so I tried that as well, but same result: it does not know the “fwk” interface. Can anyone point me to the right direction? I feel like I must be missing something super obvious… :))