* 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!

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.

$ 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

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