Really cool , although some of us aren’t really that knowledged in programming, could you make a gui for those inexperienced users?
1 Like
Hello, I could maybe make a gui, what operating system do you want it for?
I’m on Windows but you could also make one for Linux.
Would python work on both Linux and Winblows?
I don’t think the posted tool works on Windows out of the box, as it was designed for Chromebooks.
I’ve pushed an update to fw-ectool that adds a convenience command for setting the charge limit.
I’ve also learned that the charge limit and key mapping can be queried!
Charge Limit
# Query
$ ectool --interface=fwk fwchargelimit
80
# Set
$ ectool --interface=fwk fwchargelimit 65
65
Key Mapping
Question: What scancode is emitted by key matrix position r4, c8?
ectool --interface=fwk raw 0x3E0C d1,d0,b4,b8,w0
3e0c(...12 bytes...)
01 00 00 00 00 00 00 00 04 08 00 00 |............ |
^ ^
| |
| |
Read 136 bytes | |
01 00 00 00 00 00 00 00 04 08 09 00 00 00 00 00 |................|
^ ^ ^^^^^
| | `-Scancode
| `-Column
`-Row
(the above exchange has been annotated; the tool doesn’t do cool stuff like that 
)
Looks like it’s 0x0009, or F10!
4 Likes
It appears this command is functional:
sudo ectool --interface=fwk fanduty XX
Also,
sudo ectool --interface=fwk autofanctrl
does restore automatic fan control. I am considering writing a script and a companion service with rules for pushing the fan to high run for certain applications (X-Plane, Handbrake, etc) that seem to get just a little more fps work done with the fan pre-spun up to 100% vs in auto…
5 Likes
if you use something like pyinstaller, you can easily generate executables for the platform you are using it on. One option would be to use Wine for the windows executable and your Linux OS for the linux one.
1 Like
One interesting question, and this may be one for @Kieran_Levin , is what happens if the charge limit is set at zero?
It rejects it; the actual lower limit is 20.
Thx. Now have a charge limit set to ~60-80.
Charge limit set to 80 whenever charge drops below 61.
Charge limit set to 60 whenever charge goes above 79.
This mimicks my thinkpad’s settings and hopefully reduces charge cycles used. I’m not sure if maintaining a constant 60% charge uses more or less cycles than maintaining a charge between 60-80 while always plugged in. But I assume it doesn’t hurt too much if its worse since the battery is unused and will take days to go from 80% to 60% anyways.
Edit: I take that back. Its discharging at a rate that makes me think its only using battery power, though the led is flashing the same as it was when set to a static 60%. I guess if the charge limit is 60% and battery is 80%, it uses the battery without charging or supplementing power from ac until the limit is reached?
1 Like
From my mid-grade understanding of battery chemistry and longevity issues, I would choose to keep a single constant moderate charge level, versus constantly cycling up and down 20%.
5 Likes
This is awesome work!
Excited to see if there’s any possibility for more advanced keyboard remapping. Would love to use the fn key as a modifier.
Unfortunately, it looks like the Fn key mappings are compiled in (today) and can’t be changed. You can change what the key labelled Fn does by mapping it to a different scancode and assigning different behaviors to it in the OS, but you won’t be able to treat it like a “layer” in the classical keyboarding sense.
3 Likes
@DHowett - thank you for building this, I’m enjoying poking around at things a bit. I noted on your page that the power led does not support blue (fyi for those reading, if you enter an incorrect color, in my case orange, you are presented with valid values - red green blue yellow white amber). When testing the different values, I found that when I entered blue as the color, the led appeared to turn off. While the ability at a glance to see if the power is on is lost, those who find the power led too bright may find this to be a reasonable temporary workaround to turn it off when so desired.
5 Likes
I’ve pushed a minor update to the page documenting host command 3E02, some Fn key combinations, VBAT RAM, and that fanduty/autofanctrl works (thanks @D.H!)
3E02 (more info)
This command seems to disable the FN/Power keys. When you call it with 0x01, it remaps them to send scancodes e016 and e025 (respectively). When you call it with 0x5A it resets some local configuration in the EC (charge limit, keyboard backlight, etc.)
Keys (more info)
Fn+B is Ctrl+Break, Fn+P is Pause, and Fn+K is Scroll Lock.
Using blue to turn off the power button LED is pretty clever, actually!
3 Likes
Alright! I’ve pushed an update to fw-ectool that fixes reading mapped memory; now commands like battery and temps work properly.
$ ectool temps all
--sensor name -------- temperature -------- fan speed --
F75303_Local 303 K (= 30 C) 0%
F75303_CPU 303 K (= 30 C) 0%
F75303_DDR 301 K (= 28 C) 0%
Battery 296 K (= 23 C) 0%
PECI 306 K (= 33 C) 0%
$ ectool battery
EC returned error result code 3
Battery info:
OEM name: NVT
Model number: Framewo
Chemistry : LION
Serial number: 00CD
Design capacity: 3572 mAh
Last full charge: 3560 mAh
Design output voltage 15400 mV
Cycle count 37
Present voltage 16625 mV
Present current 0 mA
Remaining capacity 2896 mAh
Flags 0x0b AC_PRESENT BATT_PRESENT CHARGING
In addition, I’ve documented a few more host commands:
3E09 - Chassis Intrusion Data (more info)
This host command reports whether the chassis has ever been opened and if so, how many times.
3E0F - Chassis Status
Reports whether the chassis is open right now. Does not include historical data.
3E04 - Get Fan 0 RPM
Returns the RPM of the system fan as a 32-bit integer:
3e04(...0 bytes...)
Read 4 bytes
ff 06 00 00 |....| #<< 1791 RPM
Operates very similarly to pwmgetfanrpm 0, which returns Fan 0 RPM: 1789
Undocumented Interactions
You can reboot the EC by holding power for 20 seconds. The charge LEDs will flash to indicate that you’ve done so.
Since I’m no longer on holiday from real life, updates are going to slow down… but I still hope to write a Windows driver/userland application pair that will let you control the charge limit (among other things) without getting your hands too dirty. We’ll see!
14 Likes
Jan 7 Update:
Linux Kernel Support
I’ve submitted a patch series to add support to the kernel for the Framework EC. It’s a small change to the ChromeOS EC driver to make it suitable for Framework, and the ChromeOS person who owns that code (1) is in support of the patch and (2) is a fan of the Framework Laptop!
When this merges, I can remove the code from fw-ectool that supports --interface=fwk since all communication can be delegated to the existing kernel interface. Upstream ectool (which should be available in your distributor’s repository) will work without modification!¹
¹ Caveat being that it won’t do anything Framework-specific.
Windows Support
I’m currently working on a Windows driver that is compatible (or mostly compatible) with the Linux cros_ec device driver, and have ported ectool to use it².
This is, of course, going to be open-source . . . but I need to assign an appropriate license and write up some documentation before I do so. Eventually, I’d like to pursue code signing so that you all don’t need to enable test mode (which disables driver signature enforcement and slaps a watermark on your desktop) on your computers.
² Also, got ectool building on Windows. It has surprisingly few Linuxisms, but there were a couple.
16 Likes
How does this affect the fwk command words you added earlier? Do we have to go back to the raw command hex codes?
Good on you for bringing this to more platforms and hopefully more distros/repos, to make it even easier for end users to find and implement…
So, the plan is that the kernel device only replaces the “communication” layer–how the commands are sent to the EC and how responses are received–in ectool. The commands ectool offers (and an eventual standalone user-mode application!) will remain, and I’ll continue maintaining fw-ectool until there’s a better option for both communication and sending specific commands.
In working on this, I learned that the Linux kernel already had support for speaking the specific version of the protocol the Framework Laptop uses. I suspect that this is why ectool did not: if they added support in the kernel, they wouldn’t need a user-mode implementation of it at all.
Switching to a supported kernel driver obviates the need to turn off Secure Boot and disable lockdown, as there will no longer be a user-mode application interacting directly with hardware I/O resources. It’ll be an important part of achieving broad availability.
On the Windows side, the hardest part is going to be code signing. Kernel-mode drivers must be signed with an EV certificate (typically only granted to company entities, and I do not have one of those at the moment 
) and cross-signed by Microsoft before they will work outside of test mode and with Secure Boot enabled. The second part is easy… the first part, not so much. If you have any ideas, I am all ears!
3 Likes