Exploring the Embedded Controller

Much thanks for that link. After looking at the proposed linux kernel patches, I was able to build a working ectool from DHowett’s repo, with just this tweak (I am a bit surprised this was sufficient):

--- a/include/ec_commands.h
+++ b/include/ec_commands.h
@@ -120,7 +120,7 @@ extern "C" {
 #define EC_LPC_CMDR_SCI                BIT(5)  /* SCI event is pending */
 #define EC_LPC_CMDR_SMI                BIT(6)  /* SMI event is pending */
 
-#define EC_LPC_ADDR_MEMMAP       0x900
+#define EC_LPC_ADDR_MEMMAP       0xE00
 #define EC_MEMMAP_SIZE         255 /* ACPI IO buffer max is 255 bytes */
 #define EC_MEMMAP_TEXT_MAX     8   /* Size of a string in the memory map */
$ make utils PREFIX=/usr
..
  VERSION ec_version.h
  HOSTCC  util/ectool

$ sudo ./build/bds/util/ectool version
...
RO version:    azalea_v3.4.113237-ec:66fc84,os
RW version:    azalea_v3.4.113237-ec:66fc84,os
Firmware copy: RO
...

I’m, uh, not sure if there was a more obvious/intended way I should have known about, if this is old news or bad advice, my apologies :sweat_smile:

(I first tried using the upstream framework repo branch “lotus-zephyr” which he mentioned is used for the AMD model, and I could not figure out how to just compile ectool, with appropriate board config includes …)

3 Likes

@pierce interesting, have you noticed any incompatibility with that? Do commands such as ectool led power off and ectool fwchargelimit 60 work?

The changes in the kernel patch set were quite minimal, but I’m surprised changing the port was enough. Maybe @DHowett could elaborate?

Many commands do not work on my AMD Framework, but I suspect that some of those never worked on framework models, having been designed for chromebooks?

fwchargelimit works fully.

led is a bit weird, I could only get the power button to full brightness or off, color and level don’t seem to work, and it stays on even when the laptop is otherwise fully off, and I seemingly couldn’t fix it back to normal behavior without resetting/rebooting the EC. Partly due to my limited understanding, probably.

Also working:

  • version
  • uptimeinfo
  • battery
  • temps all
  • console
  • pwmgetfanrpm
  • fanduty
  • autofanctrl

I haven’t found working “typec” or “pd” related commands yet …

2 Likes

Sorry I’ve been distracted from this thread lately!

So! The only meaningful EC differences between the AMD Framework Laptop 13 and the earlier models are:

  1. It is using the more common Chrome EC protocol …
  2. … with a different base port for memory-mapped I/O.

Because of [1], most of the drivers already supported it. Because of [2], though, they just didn’t know it. :person_shrugging:

Absolutely true! The Framework Laptop doesn’t use any of the EC’s type C port management / port controller capabilities, for example.

Thank you for doing this!

I’ve updated my primary fork of ectool with a similar (albeit, more backwards-compatible!) change.

I suspect that rather a few people aren’t over on the new repository, so that could pose a bit of a problem… :smile:

… I’ve also finally pushed the patches for my UEFI EC toolkit …

9 Likes

Thank you @DHowett for this!
I get an error while building ectool from your gitlab repo on archlinux:

 ~/Desktop/ectool-main/build/: make ectool                                                                                          ✔ 
[  6%] Building CXX object src/CMakeFiles/ectool.dir/ec_flash.cc.o
[ 12%] Building CXX object src/CMakeFiles/ectool.dir/ec_panicinfo.cc.o
[ 18%] Building CXX object src/CMakeFiles/ectool.dir/ectool.cc.o
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: cc: not implemented: non-trivial marked Initializations not supported
  966 | };
      | ^
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
make[2]: *** [src/CMakeFiles/ectool.dir/build.make:104: src/CMakeFiles/ectool.dir/ectool.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:116: src/CMakeFiles/ectool.dir/all] Errors 2
make: *** [Makefile:91: all] Errors 2

I’m not a programmer so i have no idea what caused this…maybe you have a hint for me?

Update:
The build is working now…i choosed the wrong compiler. The tool works fine now on AMD 7480U. Thank you!

2 Likes

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:

  • ectool is really just a diagnostic utility. It’s a veritable swiss army knife, but it is not an API and it is not a contract.
  • fwchargelimit is 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 that ectool supports.

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.

4 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?

check out Releases · DHowett/FrameworkWindowsUtils · GitHub

Thanks, I saw that in the git and clicked on it but could have sworn it didn’t have that nice readme. :upside_down_face: