Exploring the Embedded Controller

1 Like

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

5 Likes

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.

3 Likes

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…

1 Like

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.

1 Like

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

1 Like

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 libusb-1.0-0-dev and 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?

3 Likes

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 <dustin@howett.net>
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

2 Likes

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.

2 Likes

Huh. I didn’t think to implement it in my slapped-together fork of ectool.

How’s this strike you?

ectool fwchargelimit 100 once

I just added it, so you may need to update!

9 Likes

Wow, nice one! Thank you. :blush:

Will do, thanks again for the speedy response!

2 Likes

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?

1 Like

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.

1 Like

I am using Ubuntu 22.04.1.
I say the battery is discharging because I closed the lid with battery at 100% and 4 days later with usb cable plugged (and white light on when I opened it again), battery was at 0%

1 Like

Ok that’s a serious decline, did you you an auto sleep when you closed the lid?

Trying to get my head around it.

  • The light indicated the battery was full
  • fwchargelimit 100 hopefully you included the ‘1’
  • Have you tried setting to 90% since?
1 Like

Yes, here is my systemd config:

# cat /etc/systemd/sleep.conf /etc/systemd/sleep.conf.d/* | grep -v ^\#

[Sleep]
[Sleep]
HibernateDelaySec=30min
[Sleep]
SuspendMode=suspend
SuspendState=disk
HibernateMode=suspend
HibernateState=disk
# cat /etc/systemd/logind.conf /etc/systemd/logind.conf.d/* | grep -v ^\#

[Login]
[Login]
HandleLidSwitch=suspend-then-hibernate
HandleLidSwitchExternalPower=hybrid-sleep
HandleLidSwitchDocked=ignore
[Login]

I did do a full reboot and used the BIOS to reset the max charge to 70 since.
Will do more testing, but would appreciate any pointers to check what is happening, maybe from @DHowett given I used the latest from his ectool

2 Likes

The most useful thing you can do when something like this is happening would be to collect an EC console log by running ectool console (or by looking at the contents of /sys/kernel/debug/cros_ec/console_log). It routinely writes charging information to this log. It looks like this:

while charging

[89350.181131 Battery 56% (Display 57.0 %) / 2h:32 to full]
[89350.182021 Charge Limit mode = 0]

while discharging

[89387.088745 Battery 56% (Display 57.0 %) / 3h:8 to empty]
[89387.089613 Charge Limit mode = 0]

For what it’s worth, fwchargelimit sends the same commands to the EC as the firmware’s setup page option does; however, once has not been very well-tested by the community, and its use may uncover bugs in Framework Computer’s implementation of one-time charging.

3 Likes