Might there be a good reason that ectool doesn’t work on the new AMD Ryzen based Framework laptops yet? I get “Unable to establish host communication” for every --interface option I try.
I received mine just a couple days ago, I’ve installed firmware (bios) 3.03, and I’m running Arch linux with kernel 6.5.9, and have installed “fw-ectool” from aur, the build script basically just clones the latest from Dhowett/framework-ec and does make utils.
By default, the modules cros_ec and cros_ec_lpcs are loaded. I’ve tried modprobing a bunch more, including cros_ec_sysfs, cros_ec_dev, cros_ec_chardev, and cros_ec_i2c, they load but do nothing. Secure boot is off, lockdown is “[none]”. I’m flailing at this point (more generously, looking for a quick and easy clue about what key piece I’m missing).
$ sudo fw-ectool version
Missing Chromium EC memory map.
Unable to establish host communication
Couldn't find EC
$ sudo fw-ectool --interface=lpc version
Missing Chromium EC memory map.
Unable to establish host communication
Couldn't find EC
...
Sure seems like default or lpc should work. Any hints? Laptop too new?
EDIT: found a hint in dmesg:
[ 2.950398] cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected
Yeah, The EC on the AMD board is different and uses a different branch of the ChromeOS EC, and the communication interface changed - @DHowett went into detail here:
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
(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 …)
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 …
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++.
@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?
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.
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.
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.
@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?
