Interesting I seem to have 60+ watts even when charging form 78 to 100% ?? using default Framework charger.
I’m just referring to the average W you compute by taking the difference in mAh of charge of the battery one minute apart and multiply it by 15.4V/60(h/min) [sticking with 15.4V being the design voltage for the battery]; not the actual power pulled from the wall.
I’m a bit off on detail, it was actually a 12V car type PD charger, I had 63W briefly but always around 60W ? as soon as powered on, no matter the state of charge.
I would like to use the power led in windows like a hdd activity monitor.
Does somebody know the address that is used for controlling the leds?
I can’t find it in the EC source…
I made a little application that uses DHowetts CrosEC driver for windows and turns the power led into a storage activity indicator.
This is mainly for my own use but if someone misses the hdd led as much as me: https://github.com/Matze5800/fw_led/releases
You have to install the driver first: https://github.com/DHowett/FrameworkWindowsUtils/releases
Is it possible to port Zephyr to it?
THIS IS SO COOL! You’re the first person I’ve heard of who is using my CrosEC driver in any capacity. I realize now that I should probably publish a NuGet package containing the header so that you don’t need to carry around a copy of the source in your repository.
The interface is intended to look a bit like the Linux
cros_ec interface so that applications can be roughly portable between the two operating systems.
Please feel free to file issues–or pull requests!–if there’s anything you need.
One of the upstream EC maintainers started working on a port of the
hx20-specific bits to mainline, which would almost certainly build with Zephyr. His work is here. Nothing may come of it, but it looks like the ChromeOS folks are pretty excited about it.
Love to see this spun off into its own thread and a guide to getting it working on Windows.
I really dislike not having an activity monitor…
Has anyone gone through a self-signing procedure for the CrosEC driver on Windows?
I’m guessing it’s something like this?
FWIW, I do distribute the driver with a code signature. Unfortunately, not even putting a certificate in the system trust store will allow the kernel to load a driver signed with that certificate outside of test mode.
Self-signing may provide you peace of mind (though, if you’re trusting the binary without building it locally but intend to self-sign it, it is somewhat moot), but it will not lift this restriction.
Windows will only load (outside of test mode) drivers that are signed with an EV identity and then further cross-signed by Microsoft.
Obvious maybe but fancontrol, battery levels, led colors work as expected on my 12th gen framework. Thinking about some controls in i3 to controll the fanspeed maybe and let the leds reflect some statuses (do they under windows? and why dont we have blue? could I add a led?)
I have tried this fork and the original and I just can’t get fw-ectool to work. I am running Debian bookworm and installed
libftdi-dev to fulfill build dependencies. Then I built the package with
make utils. Both in the original and the fork, I get this error:
sudo build/bds/util/ectool --interface=fwk version
Cannot open lockfile /run/lock/cros_ec_lockCould not acquire GEC lock
(Obviously, in the original,
--interface=fwk doesn’t work, so I didn’t pass that.)
What am I doing wrong?
I love the EFI driver, but how can I do the mapping of ESC to caps look in the EC?
I too am getting:
$ sudo ./build/bds/util/ectool version
Cannot open lockfile /run/lock/cros_ec_lockCould not acquire GEC lock.
$ git log -n1
commit d5b5b5008d2f98400206deb182e8ce772b6df9df (HEAD -> main, origin/main, origin/HEAD)
Author: Dustin L. Howett <firstname.lastname@example.org>
Date: Tue Apr 12 08:14:25 2022 -0500
Remove COMM_FWK, but keep --interface=fwk as an alias for lpc
UPDATE Without recompiling it started working. I suspect a kernel update.
For reference it is now working for me with kernel 5.15.0-52-generic
I finally set up this tool today and it’s great! It was so simple to set it up, and being able to change the charge threshold with a simple command in the terminal is incredibly useful.
I am stumped on one thing already though, which is how to use the one-shot full charge from the command line. I do get the impression it was implemented from different parts of the thread.
Here, it was discussed how there is a high bit which allows the charging limit to stay in place, but a one-off exception will be made to give it a full charge:
Here there is a screen snip of a GUI version of the tool which appears to have this feature as an available option:
I read through all the available commands in the built-in help tool and have poked around in the online documentation, but I still can’t quite figure out if this feature is available from the command line.
It’s no hardship to run
sudo ectool fwchargelimit 100 and then just run it again to set the charge threshold back where you had it after the battery is fully charged, but since I saw it mentioned in the thread I thought I would ask in case I am just missing something.
Huh. I didn’t think to implement it in my slapped-together fork of
How’s this strike you?
ectool fwchargelimit 100 once
I just added it, so you may need to update!
Wow, nice one! Thank you.
Will do, thanks again for the speedy response!
I am getting this odd behavior of battery draining even while plugged (11th Gen).
I did try
ectool fwchargelimit 100 once and it does seem to have happened after I used it.
I did have the bios updated to the latest (3.17).
Is there any inspection, setting I can do with ectool to troubleshoot this?
So you are using a Windows OS?
What makes you say the battery is discharging.
Currently I have battery charge limit set to 100% though that is not the issue.
Whatever setting the computer will sometimes draw a high load very quickly and then the battery will provide some of the current so yes it will appear to charge a little and could be quite often.
Even if the usage jumps from 20w to 40w for soem milliseconds then the load will take what it can from the battery as it is being charged, but there will always be a blip when the battery feeds the demand and the power supply catches up.