Exploring the Embedded Controller

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:

  1. Use lpc instead of fwk
  2. Please let me know, because it should pick the best available interface automatically.

you 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

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. :slight_smile:

I don’t believe that the EC reports or records battery temperature.


There is a “Battery 296 K (= 23 C) 0%”

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


Nah, it’s not loading because it’s not signed. :slight_smile: 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]”… :slight_smile: 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! :slight_smile:

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. :slight_smile:

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.

1 Like

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.