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 ectoolby 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.
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.
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!
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.
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… :))
Not quite yet. There’s some work behind the scenes on getting rid of the various quirks the patchset introduces.
Sorry for the confusion! Every version of ectool in common use now automatically detects when to use the MEC LPC interface (so you do not need to pass --interface) and has dropped the Framework-specific fwk interface.
If you do need to specify an explicit interface:
Use lpc instead of fwk
Please let me know, because it should pick the best available interface automatically.
Ah, that’s nice, thanks. What confused me is that without specifying interface I’m getting this:
~/programy/ectool/_build/src$ sudo ./ectool fwchargelimit 70
Error getting I/O privilege: Operation not permitted
Cannot find I2C adapter
Unable to establish host communication
Couldn't find EC
So I assumed I2C is the default and it tries to talk to some non-existent interface.
But after specifying the LPC interface, only the I2C line goes away while the others remain, so maybe it tried using LPC as intended, but ran into some permission issues. These won’t go away even when using su instead of sudo. Someone else apparently had the same issue 2 months ago.
strace is not that helpful either, I’m not sure what exactly it tries to open:
But someone else in the Reddit thread mentions that SecureBoot must be disabled, and running sudo mokutil --sb-state says I have it enabled. That did not even cross my mind, since I thought Debian does not support it and so I assumed it is disabled in BIOS by default…
hi, i was wondering if the ectool binary allowed to change the led “power” brightness like it is possible to do in the BIOS. This would allow for glowing effects to be replicated.
ectool led power will control the power LED, but not its brightness. It looks like the Framework-specific “Set Fingerprint LED Level Control” command doesn’t work properly on AMD, but it does on Intel.
Until the kernel patches for the AMD Framework Laptops land, you’ll need to disable secure boot and use the lpc interface.
The AMD Framework Laptops only allow you to control the side LEDs in aggregate (via the battery LED as you discovered). You unfortunately cannot control them individually like you could on the Intel ones.
@DHowett btw I noticed that your new ectool repo hosted in your gitlab, doesn’t have the help text that the previous framework-ec repo at github did. Something like this (I took the liberty of adding the “[once]” bit):
--- a/src/ectool.cc
+++ b/src/ectool.cc
@@ -178,6 +178,8 @@ const char help_str[] =
" Prints timing statisitcs relating to capture and matching\n"
" fptemplate [<infile>|<index 0..2>]\n"
" Add a template if <infile> is provided, else dump it\n"
+ " fwchargelimit [<limit>] [once]\n"
+ " Set the Framework Laptop's battery charge limit, otherwise query it\n"
" gpioget <GPIO name>\n"
" Get the value of GPIO signal\n"
" gpioset <GPIO name>\n"
I can’t read battery temperature despite running the latest version (fw-ectool-git-r2760.3ebe7b8-1).
$ sudo ectool temps all
--sensor name -------- temperature -------- ratio (fan_off and fan_max) --
local_f75303@4d 305 K (= 32 C) 0% (313 K and 343 K)
cpu_f75303@4d 306 K (= 33 C) 0% (319 K and 327 K)
ddr_f75303@4d 306 K (= 33 C) N/A (fan_off=401 K, fan_max=401 K)
cpu@4c 307 K (= 34 C) 0% (376 K and 378 K)
$ sudo ectool battery
Battery 0 info:
OEM name: NVT
Model number: FRANGWAT01
Chemistry : LION
Serial number: 0035
Design capacity: 3915 mAh
Last full charge: 4047 mAh
Design output voltage 15480 mV
Cycle count 29
Present voltage 16148 mV
Present current -285 mA
Remaining capacity 2759 mAh
Desired voltage 17800 mV
Desired current 3915 mA
Flags 0x06 BATT_PRESENT DISCHARGING
For those of you who are keeping track, the patch series that adds support for the AMD Framework Laptops to the cros_ec_lpcs driver landed today for linux-next.
I don’t believe that the EC reports or records battery temperature.
@DHowett
I’m more of a Linux person so I don’t have much experience compiling on Windows, but I’m trying it out inside Virtualbox first (with Artix Linux as host and Windows 11 as guest) (after I figure it out, I want to install it on the laptop of my SO), and I get this error:
cl: command line error D8021: invalid argument '/Wno-c99-designator' [C:\Users\username\src\ectool\build\src\ectool.vcxproj]
uugh all this stuff here is exciting, i’d love to be able to control the EC locally here. unfortunately, the kernel module doesn’t load here because of secure boot and last i tried i couldn’t compile ectool…
is there stock debian/ubuntu options to make this work from userland? particularly excited about varying the LED color more widely based on charge level.
Whoops, you’re totally right. That printout is from the 11th gen Intel Framework Laptop; it shares an embedded
controller lineage with the rest of the Intel devices that are available today and may have some slightly different
features, sensors and reports from the AMD ones.
I haven’t seen any indication of battery temperature reporting on my AMD Frameworks Laptop.
Unfortunately, the ectool project requires ClangCL. It’s an optional component that ships with Visual Studio:
The module is probably not loading because it doesn’t have the required patches (which just landed for linux-next!)
If you can wait just a bit longer, it should start showing up in distribution kernels. Any version of ectool will work after that.
If you can’t: you can always disable secure boot and use a binary build of ectool:
Nah, it’s not loading because it’s not signed. Also, that patch seems to be for AMD laptops support, i have a 12th gen Intel…
Where do you get ectool? It doesn’t seem to be packaged in Debian, and I’m not a fan of “disable [security] and [run arbitrary binaries from GitHub]”… Here (Debian stable), there seems to be a ectool program in the coreboot-utils package, but it’s orphaned so i guess that explains a lot… it certainly doesn’t have ectool temps for example:
anarcat@angela:~$ ectool temps all
Error: Extra parameter found.
usage: ectool [-vh?Vidq] [-w 0x<addr> -z 0x<data>]
-v | --version: print the version
-h | --help: print this help
-V | --verbose: print debug information
-p | --getports: get EC data & cmd ports from /proc/ioports
-d | --dump: print RAM
-i | --idx: print IDX RAM & RAM
-q | --query: print query byte
-w <addr in hex> write to addr
-z <data in hex> write to data
So I guess I should update the debian package somehow!
Oh! Sorry, I’m used to all new inquiries being about the AMD devices. In that case… I believe a newer version of the kernel package (working its way through sid) now comes with a signed cros_ec_lpcs.ko.
Honestly, I used to get it by building upstream. You can also build Framework’s version. Both of these will require you to make util or make utils (I’ve forgotten which.)
It’s part of the overall EC source code. That’s why I pulled it out to live in a standalone repository! It doesn’t need the rest of the EC source code.
