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:
lpc instead of fwkyou do not need to pass
--interface
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:
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
newfstatat(4, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1d), ...}, AT_EMPTY_PATH) = 0
write(4, "Error getting I/O privilege: Ope"..., 53Error getting I/O privilege: Operation not permitted
) = 53
close(4)
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.
Do you have the i2c module loaded? On my system, I have:
$ lsmod | grep i2c
i2c_algo_bit 20480 1 amdgpu
i2c_piix4 32768 0
i2c_hid_acpi 12288 0
i2c_hid 40960 1 i2c_hid_acpi
i2c_dev 28672 0
sudo ectool led left green
It only shows “EC returned error result code 3”, I can only
sudo ectool led battery green
which controls both left and right leds at the same time
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.
There is a “Battery 296 K (= 23 C) 0%”
@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]
To get there, my steps were:
- git clone (into 'ectool')
- cd ectool
- mkdir 'build'
- cd build
- cmake ..
- cmake --build .
I am probably missing something obvious, like a Microsoft software package. Any advice?
Edit: would it be because you are using Mingw by any chance?
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:
linux/x64Nah, 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.
I found that upon $ sudo ectool battery
The “Desired current 2740 mA” is not a constant value, sometimes it gets higher sometimes lower, does that have anyting to do with temperature?
Edit: It goes to 3915 mA during discharging
the fwchargelimit can be set to 255, is it a bug?
Hi, this is an amazing work! I am just struggling with the driver signing on Windows since I do not want to allow test signing and disable secure boot.
I thought about signing the Windows driver myself with a certificate, but just noticed that Microsoft changed their driver signing policies since Windows 10 1607 and only Microsoft-signed drivers via the Microsoft portal are now permitted? Sounds complicated.
Do you know if one can use the generic non-Framework EC software utilities that are already signed or somehow work around the signing, such as RWeverything or nbfc’s ec-probe? When I use ec-probe.exe monitor or ec-probe.exe dump, it gives me some memory dumps where some values change over time, but I have no idea if they’re meaningful and what addresses to look at in the AMD Framework 13 since all your old blog posts are about the Intel variants.
Note: Apparently the RWeverything driver is on Microsoft’s blocklist, but can be allowed by disabling the “Microsoft Vulnerable Driver Blocklist” feature.
Edit: I think that using ec-probe.exe dump stopped Framework from reporting battery status to Windows, it got stuck at 85% for a long time. Reboot fixed it.
If you would consider disabling the signed-driver blocklist, and installing RWeverything, you really should consider disabling Secure Boot. Vulnerable drivers are one of the main ways that the malware, which Secure Boot is supposed to stop, work. So, you know, just don’t install malware 
See also How a Microsoft blunder opened millions of PCs to potent malware attacks | Ars Technica (the blocklist wasn’t actually being updated for a couple years … people outside microsoft figured it out because active malware continued to bundle and use known vulnerable signed drivers).
EDIT: I’m cavalier about secure-boot because I used desktops/laptops heavily for over a decade while secure-boot didn’t exist yet, and it makes lots of interesting tinkering things painful/annoying.
I understand what you’re saying, but I still think we should figure out a reasonable way to sign the driver since more and more people are using it.
It is not just about disabling secure boot, it is the fact that you are essentially installing a random unsigned driver from the internet. Even if I trust DHowett, someone can steal his password, login into his repository, and replace the driver by infected executables, all under his account. You are then going to install a virus and it could take weeks before anyone realizes.
Unfortunately, I do not really have any experience with the Microsoft procedures. The way I understand it, you need an EV certificate (easy to obtain, but quite expensive), register for Microsoft Entra ID and Microsoft Windows Hardware Developer Program (looks like you “just” sign a bunch of agreements, but it should be free), then the driver needs to pass the HLK tests (no idea about this, but it seems that Microsoft publishes VHLK virtual machines with everything set up to run the tests), and finally you upload the test results to the Microsoft portal, where it gets somehow approved and signed by Microsoft.
Sounds very elaborate. I dunno if you have to pay anything to Microsoft, but it seems the only paid part is the EV certificate, which is unfortunately quite pricy. The whole procedure sounds somewhat straightforward, but it could also be a big pain in the butt. I cannot judge
I would like to help but not sure how. We have EV certificates in our company that we use to sign our software, but I am not sure I’d be able to push through the idea that we’d be signing this driver ourselves. Ideally, since Framework is also using it in their own scripts, Framework would sign the driver using their own certificates.