Debian Bug report logs - #1021409
RFP: fw-ectool -- Framework laptop embedded controller tool

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: RFP: fw-ectool -- Framework laptop embedded controller tool

Date: Fri, 07 Oct 2022 15:37:13 -0400

Package: wnpp
Severity: wishlist

* Package name    : fw-ectool
  Version         : none
  Upstream Author : https://frame.work/
* URL             : https://github.com/FrameworkComputer/EmbeddedController
* License         : BSD-3 clause
  Programming Lang: C
  Description     : Framework laptop embedded controller tool

The fw-ectool binary provides users with ways of interacting with
the embedded controller in their laptop. This could mean something as
fancy as changing LED colors:

    ectool led left blue

or more critical as limiting charge percentages:

    ectool fwchargelimit 80

The actual repository above contains the *entire* embedded controller
source code, but the actual binary I'm interested in is only inside
the `util` directory. Apparently:

https://www.howett.net/posts/2021-12-framework-ec/#using-fw-ectool

... the way to get the binary is with:

    make utils

inside said repository.

I'm not sure we want to ship the entirety of this source code in
Debian, however, so I'm looking for advice on how to manage this. In
particular, I understand that the framework EC is based on the
Chromebook EC, so it's technically a fork. And therefore the ectool
here *could* be used (or not?) on a chromebook as well. I'm not sure.

Ideally, that tool would be split out in a different source repository
and could interoperate with different ECs out there, but this is not
the hand we have been given yet.

I am not aware of a similar tool in Debian, but would very welcome
other advice on this.

Thanks!

Message #10 received at 1021409@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: 1021409@bugs.debian.org

Subject: some findings

Date: Fri, 07 Oct 2022 15:47:13 -0400

I needed to install libusb-1.0-0-dev and libftdi-dev to build the
thing. But then it doesn't start, I reported the issue here:

https://community.frame.work/t/exploring-the-embedded-controller/12846/91?u=anarcat

a.
-- 
On ne peut s'empêcher de vieillir, mais on peut s'empêcher de devenir
vieux.
                        - Henri Matisse

Message #15 received at 1021409@bugs.debian.org (full text, mbox, reply):

From: Louis-Philippe Véronneau <pollo@debian.org>

To: 1021409@bugs.debian.org

Subject: Re: some findings

Date: Tue, 10 Sep 2024 12:38:53 -0400

On Fri, 07 Oct 2022 15:47:13 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= 
<anarcat@debian.org> wrote:
> I needed to install libusb-1.0-0-dev and libftdi-dev to build the
> thing. But then it doesn't start, I reported the issue here:
> 
> https://community.frame.work/t/exploring-the-embedded-controller/12846/91?u=anarcat
> 
> a.
> -- 
> On ne peut s'empêcher de vieillir, mais on peut s'empêcher de devenir
> vieux.
>                         - Henri Matisse
> 
> 

FWIW, I built it and it seems to run fine on the current unstable:

$ sudo ./build/bds/util/ectool inventory
EC supported features:
1   : Flash support
2   : Direct Fan power management support
3   : Keyboard backlight support
5   : LED support
7   : Keyboard support
9   : BIOS Port 80h access support
10  : Thermal management support
13  : Host event support
14  : GPIO support
15  : I2C master support
16  : Charger support
17  : Simple Battery support
18  : Smart Battery support
22  : USB Cros Power Delivery support
25  : Temporary secure vstore support
32  : Unified wake masks for LPC/eSPI support
33  : 64-bit host events support
34  : Execute code in RAM support

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

Message #20 received at 1021409@bugs.debian.org (full text, mbox, reply):

From: Louis-Philippe Véronneau <pollo@debian.org>

To: 1021409@bugs.debian.org

Subject: Re: some findings

Date: Tue, 10 Sep 2024 13:32:09 -0400

I agree it would be nice to remove everything that isn't needed to 
support the framework laptops. That probably requires someone who knows 
what they are doing though...

From what I can see online, the Intel boards are the hx20 and hx30, 
whereas the AMD ones the lotus-zephyr. Those live on separate branches.

Framework says:

"We upstream common features where they fit into the design decisions of 
Chrome OS. However, there are a number of features and changes that will 
be unlikely to be upstreamed because they are unnecessary for Chrome OS 
operation or do not fit the philosophy of Chrome OS."

This means we can't hope for a single tarball that works on all the 
Framework boards...

Duplicating code never is wonderful, but I feel the only solution is to 
have a source package per board. I would propose:

* fw-ectool-hx20-hx30
* fw-ectool-lotus-zephyr

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

Send a report that this bug log contains spam.