Exploring the Embedded Controller

I closed the lid and left the laptop hibernate, all this time with the charging cable connected.
Noticed side light turned off when went to resume.
And it was discharging after resume.

$ sudo ~/src/framework-ec/build/bds/util/ectool console
15473.814554 HC 0x98]
]
[15185.239242 Charge Limit mode = 0]
[15204.697404 Battery 65% (Display 66.8 %) / 3h:16 to empty]
[15204.698320 Charge Limit mode = 0]
[15226.056203 Battery 65% (Display 66.7 %) / 3h:53 to empty]
[15226.057098 Charge Limit mode = 0]
[15241.833095 Battery 65% (Display 66.6 %) / 2h:55 to empty]
[15241.833932 Charge Limit mode = 0]
[15257.236242 Battery 65% (Display 66.5 %) / 2h:59 to empty]
[15257.237054 Charge Limit mode = 0]
[15274.366333 Battery 65% (Display 66.4 %) / 3h:23 to empty]
[15274.367248 Charge Limit mode = 0]
[15283.985753 Battery 65% (Display 66.3 %) / 3h:1 to empty]
[15283.986636 Charge Limit mode = 0]
[15301.115822 Battery 65% (Display 66.2 %) / 3h:2 to empty]
[15301.116687 Charge Limit mode = 0]
[15317.871820 Battery 65% (Display 66.1 %) / 2h:34 to empty]
[15317.872645 Charge Limit mode = 0]
[15331.448195 Battery 65% (Display 66.0 %) / 2h:41 to empty]
[15331.449334 Charge Limit mode = 0]
[15348.548557 event set 0x0000000200000000]
[15348.549988 event clear 0x0000000200000000]
[15348.550560 ACPI query = 34]
PORT80: 0022
[15349.052992 Battery 64% (Display 65.9 %) / 2h:56 to empty]
[15349.054093 Charge Limit mode = 0]
[15358.771761 Battery 64% (Display 65.8 %) / 2h:51 to empty]
[15358.772677 Charge Limit mode = 0]
[15370.795292 Battery 64% (Display 65.7 %) / 2h:25 to empty]
[15370.796186 Charge Limit mode = 0]
[15386.973691 Battery 64% (Display 65.6 %) / 2h:37 to empty]
[15386.974529 Charge Limit mode = 0]

After disconnecting and reconnecting the cable:

$ sudo ~/src/framework-ec/build/bds/util/ectool console
15542.219925 HC 0x98]
811872 HC 0x97]
[15473.814554 HC 0x98]
+++(++)[15494.891590 Battery 64% (Display 65.0 %) / 4h:10 to empty]
[15494.892686 Charge Limit mode = 0]
[15519.194354 Battery 64% (Display 64.9 %) / 4h:20 to empty]
[15519.197136 Charge Limit mode = 0]
[15524.165946 HC 0x0b]
[15524.171124 HC 0x3e03]
[15524.171730 Charge Limit mode = 0]
[15532.139428 PD Source supply changed! old=0x0, new=0x08]
[15532.147621 CYPD_RESPONSE_PORT_CONNECT 3]
[15532.153088 Updating board_set_active_charge_port port 3]
[15532.156520 CL: p3 s1 i3000 v5000]
[15532.157068 TODO Implement pd_set_new_power_request port 3]
[15532.162367 cypd_update_power_status power_stat 0x8]
[15532.167807 INTR_REG CTRL:0 TODO Device 0x2]
[15532.170114 INTR_REG CTRL:1 TODO Device 0x2]
[15532.172584 Charge Limit mode = 0]
[15532.174946 update charger!!]
[15532.178027 AC on]
[15532.178498 event set 0x0000000000000008]
[15532.179572 event clear 0x0000000000000008]
[15532.180109 ACPI query = 4]
PORT80: 0004
[15532.416445 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
[15532.422327 Updating board_set_active_charge_port port 3]
[15532.425563 CL: p3 s0 i5000 v20000]
[15532.426117 TODO Implement pd_set_new_power_request port 3]
[15532.428187 INTR_REG CTRL:0 TODO Device 0x2]
[15532.429154 cypd_update_power_status power_stat 0xe]
[15532.436493 INTR_REG CTRL:1 TODO Device 0x2]
[15532.522444 Updating SOC Power Limits: PL2 64, PL4 121, Psys 134, Adapter 100]
[15533.408872 Battery 64% (Display 64.9 %) / 4h:4 to empty]
[15533.409764 Charge Limit mode = 0]
[15533.412245 charge_request(17400mV, 3572mA)]
[15534.566067 event set 0x0000000000000080]
[15534.566966 event clear 0x0000000000000080]
[15534.567509 ACPI query = 8]
PORT80: 0008
[15535.921457 charge_request(17400mV, 2500mA)]
[15537.121339 Battery 64% (Display 65.0 %) / 2h:7 to full]
[15537.122348 Charge Limit mode = 0]
[15541.451481 Battery 64% (Display 65.1 %) / 1h:36 to full]
[15541.452387 Charge Limit mode = 0]
[15542.213791 HC 0x0b]
[15542.214759 HC 0x97]

It seems something is causing EC to disregard that there is an actual charging cable both on lid close and after open!

After another round where I did watch the light turn off and then I resumed:

$ sudo ~/src/framework-ec/build/bds/util/ectool console 
23901.440754 HC 0x98]
k ignored]
[23883.100118 AUX Callback ignored]
[23883.100533 AUX Callback ignored]
[23883.101289 AUX Callback ignored]
[23883.101705 AUX Callback ignored]
[23883.104955 AUX Callback ignored]
[23883.105498 AUX Callback ignored]
[23883.106065 AUX Callback ignored]
[23883.106609 AUX Callback ignored]
[23883.112308 AUX Callback ignored]
[23883.112874 AUX Callback ignored]
[23883.113290 AUX Callback ignored]
[23883.113982 AUX Callback ignored]
[23883.118911 AUX Callback ignored]
[23883.119455 AUX Callback ignored]
[23883.120022 AUX Callback ignored]
[23883.120566 AUX Callback ignored]
[23883.126217 AUX Callback ignored]
[23883.126739 AUX Callback ignored]
[23883.127198 AUX Callback ignored]
[23883.1[23883.133197 AUX Callback ignored]
[23883.133764 AUX Callback AUX Callback ign[23883.140001 AUX Callback ignored]
[23883.140416 AUX Callback [23883.146973 AUX Callback ignored]
[23883.147389 AUX Callback ignored]
[23883[23883.148191 AU[23884.637426 KB extra IRQ]
PORT80: 0001
PORT80: 0002
PORT80: 0003
PORT80: 0004
PORT80: 0003
[23885.125462 Updating SOC Power Limits: PL2 28, PL4 70, Psys 52, Adapter 100]
[23885.505793 event clear 0x0000000000000002]
[23885.506372 ACPI query = 2]
[23885.511831 event clear 0x0000000000000010]
[23885.512413 ACPI query = 5]
PORT80: 0002
[23885.523813 event clear 0x0000000000000080]
[23885.524397 ACPI query = 8]
PORT80: 0005
[23885.531858 event clear 0x0000000200000000]
[23885.532430 ACPI query = 34]
PORT80: 0008
PORT80: 0022
[23885.565791 KS disable]
[23885.566284 KB Clear Buffer]
[23885.568363 KS enable]
[23885.568839 KB Clear Buffer]
[23885.846852 PS2 unhandled data 0xe1]
[23886.065700 PS2M Detected host packet during interrupt handling]
[23886.451012 PS2 unhandled data 0xa]
[23886.456528 PS2 unhandled data 0x1]
[23886.457864 PS2 unhandled data 0x41]
[23886.986330 PS2 unhandled data 0x88]
[23886.989181 PS2 unhandled data 0x0]
[23887.004538 PS2M 5 Button Magic Knock!]
[23901.438839 HC 0x0b]
[23901.439837 HC 0x97]

It looks like on lid open it is not charging anymore, and again once I disconnect and reconnect the cable:

$ sudo ~/src/framework-ec/build/bds/util/ectool console 
24101.631834 HC 0x98]
885.568363 KS enable]
[23885.568839 KB Clear Buffer]
[23885.846852 PS2 unhandled data 0xe1]
[23886.065700 PS2M Detected host packet during interrupt handling]
[23886.451012 PS2 unhandled data 0xa]
[23886.456528 PS2 unhandled data 0x1]
[23886.457864 PS2 unhandled data 0x41]
[23886.986330 PS2 unhandled data 0x88]
[23886.989181 PS2 unhandled data 0x0]
[23887.004538 PS2M 5 Button Magic Knock!]
[23901.438839 HC 0x0b]
[23901.439837 HC 0x97]
[23901.440754 HC 0x98]
+++(++)[24084.118122 HC 0x0b]
[24084.119224 HC 0x3e03]
[24084.121774 Charge Limit mode = 1]
[[24096.554007 CYPD_RESPONSE_PORT_CONNECT 3]
24096.553057 PD Source supply changed! old=0x0, new=0x08]
[24096.559793 Updating board_set_active_charge_port port 3]
[24096.563211 CL: p3 s1 i3000 v5000]
[24096.563759 TODO Implement pd_set_new_power_request port 3]
[24096.565937 INTR_REG CTRL:0 TODO Device 0x2]
[24096.567000 cypd_update_power_status power_stat 0x8]
[24096.573615 INTR_REG CTRL:1 TODO Device 0x2]
[24096.583527 Charge Limit mode = 1]
[24096.585879 update charger!!]
[24096.589229 AC on]
[24096.589700 event set 0x0000000000000008]
[24096.590450 event clear 0x0000000000000008]
[24096.590988 ACPI query = 4]
PORT80: 0004
[24096.829981 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
[24096.835753 Updating board_set_active_charge_port port 3]
[24096.839135 CL: p3 s0 i5000 v20000]
[24096.839688 TODO Implement pd_set_new_power_request port 3]
[24096.841866 INTR_REG CTRL:0 TODO Device 0x2]
[24096.842959 cypd_update_power_status power_stat 0xe]
[24096.850089 INTR_REG CTRL:1 TODO Device 0x2]
[24096.936393 Updating SOC Power Limits: PL2 64, PL4 121, Psys 134, Adapter 100]
[24097.719906 Battery 100% (Display 100.0 %) / 7h:36 to empty, not accepting current]
[24097.720956 Charge Limit mode = 1]
[24097.723428 charge_request(17600mV, 0mA)]
[24098.407295 Battery 100% (Display 100.0 %) / 7h:53 to empty, not accepting current]
[24098.410273 Charge Limit mode = 1]
[24101.625674 HC 0x0b]
[24101.626726 HC 0x97]

1 Like

Another example after a resume from hibernation without charging kicking in:

$ sudo ~/bin/ectool console
Place your right index finger on the fingerprint reader
600737.775202 HC 0x98]
27 AUX Callback ignored]
[600695.798463 AUX Callback ignored]
[600695.799071 AUX Callback ignored]
[600695.799807 AUX Callback ignored]
[600695.806918 AUX Callback ignored]
[600695.807526 AUX Callback ignored]
[600695.808262 AUX Callback ignored]
[600695.808870 AUX Callback ignored]
[600695.816633 AUX Callback ignored]
[600695.817369 AUX Callback ignored]
[600695.817977 AUX Callback ignored]
[600695.818585 AUX Callback ignored]
[600695.826417 AUX Callback ignored]
[600695.827293 AUX Callback ignored]
[600695.827901 AUX Callback ignored]
[600695.828785 AUX Callback ignored]
[600695.833263 AUX Callback ignored]
[600695.833871 AUX Callback ignored]
[600695.834766 AUX Callback ignored]
[600695.835503 AUX Callback ignored]
[600697.538408 Battery 61% (Display 62.0 %) / 1h:45 to empty]
[600697.539651 Charge Limit mode = 0]
PORT80: 0001
PORT80: 0002
PORT80: 0003
PORT80: 0004
PORT80: 0003
[600698.620632 Updating SOC Power Limits: PL2 28, PL4 70, Psys 52, Adapter 100]
[600698.766031 event clear 0x0000000000000004]
[600698.766802 ACPI query = 3]
[600698.769911 KS disable]
[600698.770751 KB Clea[600698.771273 event clear 0x0000000200000000]
[600698.772038 ACPI query = 34]
PORT80: 0003
r Buffer]
[600698.774979 KS enable]
[600698.775647 KB Clear Buffer]
PORT80: 0022
[600699.040396 PS2 unhandled data 0xe1]
[600699.550145 PS2 unhandled data 0xa]
[600699.552054 PS2 unhandled data 0x1]
[600699.553500 PS2 unhandled data 0x41]
[600700.061952 PS2 unhandled data 0x88]
[600700.065282 PS2 unhandled data 0x0]
[600700.080946 PS2M 5 Button Magic Knock!]
[600700.837918 PS2M Detected host packet during interrupt handling]
[600705.708540 Battery 61% (Display 61.9 %) / 1h:45 to empty]
[600705.709558 Charge Limit mode = 0]
[600715.962337 Battery 61% (Display 61.8 %) / 1h:52 to empty]
[600715.963445 Charge Limit mode = 0]
[600728.584885 Battery 61% (Display 61.7 %) / 1h:52 to empty]
[600728.585960 Charge Limit mode = 0]
[600737.772869 HC 0x0b]
[600737.773980 HC 0x97]
$ sudo ~/bin/ectool fwchargelimit
70

after unplugging / replugging the charge cable:

~$ sudo ~/bin/ectool console
600948.106649 HC 0x98]

[600916.068302 TODO Implement pd_set_new_power_request port 3]
[600916.070407 INTR_REG CTRL:0 TODO Device 0x2]
[600916.071791 cypd_update_power_status power_stat 0x8]
[600916.080106 INTR_REG CTRL:1 TODO Device 0x2]
[600916.088073 Charge Limit mode = 0]
[600916.090593 update charger!!]
[600916.093934 AC on]
[600916.094598 event set 0x0000000000000008]
[600916.095779 event clear 0x0000000000000008]
[600916.096509 ACPI query = 4]
PORT80: 0004
[600916.334023 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
[600916.340043 Updating board_set_active_charge_port port 3]
[600916.343623 CL: p3 s0 i5000 v20000]
[600916.344488 TODO Implement pd_set_new_power_request port 3]
[600916.346836 INTR_REG CTRL:0 TODO Device 0x2]
[600916.348111 cypd_update_power_status power_stat 0xe]
[600916.355160 INTR_REG CTRL:1 TODO Device 0x2]
[600916.440161 Updating SOC Power Limits: PL2 64, PL4 121, Psys 134, Adapter 100]
[600917.236067 Battery 60% (Display 60.8 %) / 4h:10 to empty]
[600917.239021 Charge Limit mode = 0]
[600917.245477 charge_request(17400mV, 3572mA)]
[600918.434937 event set 0x0000000000000080]
[600918.436232 event clear 0x0000000000000080]
[600918.436956 ACPI query = 8]
PORT80: 0008
[600919.113979 charge_request(17400mV, 2500mA)]
[600921.017322 Battery 60% (Display 60.9 %) / 2h:23 to full]
[600921.018353 Charge Limit mode = 0]
[600925.194251 Battery 60% (Display 61.0 %) / 2h:5 to full]
[600925.195232 Charge Limit mode = 0]
[600928.960153 Battery 60% (Display 61.1 %) / 1h:46 to full]
[600928.961414 Charge Limit mode = 0]
[600934.553850 Battery 60% (Display 61.2 %) / 1h:31 to full]
[600934.554926 Charge Limit mode = 0]
[600938.621129 Battery 60% (Display 61.3 %) / 1h:25 to full]
[600938.622140 Charge Limit mode = 0]
[600942.531649 Battery 60% (Display 61.4 %) / 1h:21 to full]
[600942.532757 Charge Limit mode = 0]
[600947.597737 Battery 60% (Display 61.5 %) / 1h:18 to full]
[600947.598977 Charge Limit mode = 0]
[600948.100471 HC 0x0b]
[600948.103644 HC 0x97]

Something is definitely off with hibernate…
This does not occur 100% of time, but often enough it could lead to a drain to 0 situation even while lid closed and plugged in.

I was suddenly wondering.

On some systems, the EC controls the maximum power limit that the CPU/iGPU can use. I was wondering if the EC here can modify the behavior similar to how motherboard vendors on desktop increase how much power the CPU can use and/or boost durations such as PL2, which is higher than the Intel stock settings from factory.

Would be interesting to see how much we can push the system to hit the power limits with sufficient thermal headroom.

4 Likes

Interesting thought, however, if I read the readmes (havent found framework specific sources yet) This might also influence USB3, pci and display clock speeds?

Im not sure how much more power we can gain without breaking something. Am I reading it correctly we are running the Zephyr RTOS in our new Frameworks? or thats only the newer Chromebook version?

1 Like

Not sure if we can run throttlestop on Windows and see if we hit a locked power limit or a limited power limit especially for 12th gen.

Even if we can maintain 64W indefinitely with thermal headroom would be cool for those using as a mini PC. From my understanding is, generally these are vendor limited by firmware than hardware.

The Intel NUC with a 1260p with boost at full tilt can hit up to 85W from the wall, so I was wondering if we can push to get a 85W sustained (assuming the Framework’s VRMs can take it).
Review of various laptops with the same 1260p showed different performance due to thermal headroom and power limits too.

2 Likes

Wendell at Level1Tech showed that it is possible to push the 1240p harder with BIOS settings by adjusting the PL1 and more :smiley:

So the 12th Gen CPUs probably can do it, just need the the Firmware and check if the mainboard can take it :smiley:

Maybe CNC a mounting mechanism for a low profile desktop cooler or even a Tower cooler/AIO for direct die contact to give thermal headroom.

I would like to have the fan speed displayed in the Gnome extension vitals. I’m trying to understand what would have to be done to achieve this goal.

Whats the status of the ec driver did it get merged?

Checking with list modules on my system, there are several chrome os embedded controller kernel modules loaded:

$ lsmod | grep cros
cros_usbpd_charger     20480  0
cros_ec_sysfs          16384  0
cros_ec_debugfs        16384  0
cros_usbpd_logger      20480  0
cros_usbpd_notify      20480  1 cros_usbpd_charger
cros_ec_chardev        16384  0
cros_ec_dev            16384  0
cros_ec_lpcs           16384  0
cros_ec                20480  1 cros_ec_lpcs

The embedded controller is listed in sysfs under:
/sys/class/chromeos/cros_ec/

The file Version contains the following, which seems plausible.

RO version:    hx20_v0.0.1-03897d4
RW version:    
Firmware copy: RO
Build info:    hx20_v0.0.1-03897d4 2022-07-15 00:23:44 runner@fv-az252-782
Chip vendor:   mchp
Chip name:     unknown
Chip revision: 00
Board version: 12

According to kernelconfig.io one should use the kernel module cros_ec_sysfs to control the embedded controller and get information from it.

According to the Linux kernel documentation sensor information is reported in /sys/class/hwmon/hwmon*. This is the same directory from which vitals reads sensor values.

On my system there is no hwmon for fan speed.
Does the embedded controller report its sensor data to anywhere in the sysfs?

I’m new to the Framework world. On my current Thinkpad X230, I’m using the
charge_control_start_threshold and charge_control_stop_threshold in TLP and with these set to that there is no charging between 40 % and 80 %, my battery stays as new after 3 years. My wife has got a Thinkbook where only the charge_control_stop_threshold is available and after 1 year the battery capacity is already reduced by 5 %. That’s not a lot, but still quite a difference. I would love to see these two threshold available in the Framework EC firmware as I’m now saving to get a Framework 13 with AMD CPU as successor to my X230.

That’s unusual, dare I say unlikely, as batteries wear even when not used.

Have you tried a full discharge and recharge to reset the battery read out.

Whereas the Embedded controller does control it doesn’t read the state of the battery. The battery info is pushed from the battery and if that isn’t calculating over a range it will not have a lot to work on.

Coulomb counting is one thing but measuring coulombs from 0 to 100 is a base measurement for wear.

That’s based on my limited understanding of course :slight_smile:

I have daily measurements and after a year I have managed to find a reading that says there is no wear but on average there seems to be less than 2% given the 3.4% wear upon receipt.

I have a limit of 78% max and run mostly plugged in

Sorry it is less than 3 years. I’ve got the battery in December 2021.

tlp-stat -b reports a loss of 10 mwh against the design capacity. So the loss is very small in that time frame. I’m most of the time on AC, but I can take the laptop on battery for some time and the charge would go from 80 % to 70 % but when plugged in it will not charge back to 80 %. I think this saves on battery cycle.

See the tlp-stat -b report below

--- TLP 1.3.1 --------------------------------------------

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = active (recalibrate)
tp-smapi   = inactive (ThinkPad not supported)

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer                   = LGC
/sys/class/power_supply/BAT0/model_name                     = 45N1029
/sys/class/power_supply/BAT0/cycle_count                    = (not supported)
/sys/class/power_supply/BAT0/energy_full_design             =  93240 [mWh]
/sys/class/power_supply/BAT0/energy_full                    =  93230 [mWh]
/sys/class/power_supply/BAT0/energy_now                     =  72400 [mWh]
/sys/class/power_supply/BAT0/power_now                      =      0 [mW]
/sys/class/power_supply/BAT0/status                         = Not charging

/sys/class/power_supply/BAT0/charge_start_threshold         =     40 [%]
/sys/class/power_supply/BAT0/charge_stop_threshold          =     80 [%]
tpacpi-bat.BAT0.forceDischarge                              =      0

Charge                                                      =   77.7 [%]
Capacity                                                    =  100.0 [%]

1 Like

@DHowett @Kieran_Levin
Are there any plans to get a signed version at some point?
Even though personally I’m exclusively a Linux user, my SO is on Windows, and it would be very nice to be able to use a Windows version without the need to go through Bitlocker or to switch into test mode!

thanks for making this ec tool, @DHowett !

i was able to set the charge limit without rebooting, and it was wonderful!

however, now i’ve set it back down to 50% after traveling, and the battery is staying at 100% charge. ectool reports that the charge limit is set to 50, but upower says it’s at 96%. do i need to do something other than just
sudo $(which ectool) fwchargelimit 50
to get it do go back down to 50%?

side note: i’d really like to learn how to write firmware like this. i know c, and i checked out the commit Add fwchargelimit and the framework OEM header 679cc25c4. how did you know to write that code? where would i go to learn how to do that? my experience with c is that i’ve written a couple implementations of malloc. i feel pretty comfortable with the c part, but not figuring out what bits to set to make the hardware do something.

thanks!

i’d totally like to help out with the project! let me know if there’s any task(s) on your TODO list. i did not see one in the repo.

I would love to have a way to lift the TDP limits. I haven´t had 12gen in my hands yet, but I can confirm that 11gen is limited in a way - TDP is first unlimited, then after a few seconds 28W hard limit kicks in and no amount of playing around in Throttlestop will lift that. I read that it is because EC overrules Throttlestop, which brought me to this topic, hoping someone more capable looked at this.

I want to experiment with water cooling or other cooling improvements, for use in my FW Tablet Lite project. The idea is that the tablet will be good as a tablet or laptop with a keyboard folio, but especially a gaming PC when plugged into an eGPU. But the performance could just be so much better. With the 28W power limit, we are looking at about 3.3 GHz sustained. WIthout the limit, the 1165g7 should be doing about 4.2 GHz all core. Now, the stock cooling can´t handle it at full power, it can hit 3.5-3.6 GHz but in my tablet there is some room so I wanted to experiment with water cooling strapped to the heatpipes that would be possible to plug in when you get home and use it as a desktop.

But why would I do it if there is nothing to gain, as the CPU is (after several seconds) limited to 28W? Do you guys think it would be possible to make it work on Windows?

I am also thinking about the new Ryzen boards, the 8-core makes little sense if it gets the same cooling and power limits as the 6-core. But if those limits could be unlocked, having a 10.5" device that weighs under 1kg and features desktop performance under certain circumstances, that would be very pleasant.

1 Like

Might there be a good reason that ectool doesn’t work on the new AMD Ryzen based Framework laptops yet? I get “Unable to establish host communication” for every --interface option I try.

I received mine just a couple days ago, I’ve installed firmware (bios) 3.03, and I’m running Arch linux with kernel 6.5.9, and have installed “fw-ectool” from aur, the build script basically just clones the latest from Dhowett/framework-ec and does make utils.

By default, the modules cros_ec and cros_ec_lpcs are loaded. I’ve tried modprobing a bunch more, including cros_ec_sysfs, cros_ec_dev, cros_ec_chardev, and cros_ec_i2c, they load but do nothing. Secure boot is off, lockdown is “[none]”. I’m flailing at this point (more generously, looking for a quick and easy clue about what key piece I’m missing).

$ sudo fw-ectool version
Missing Chromium EC memory map.
Unable to establish host communication
Couldn't find EC

$ sudo fw-ectool --interface=lpc version
Missing Chromium EC memory map.
Unable to establish host communication
Couldn't find EC

...

Sure seems like default or lpc should work. Any hints? Laptop too new?

EDIT: found a hint in dmesg:

[    2.950398] cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected

Yeah, The EC on the AMD board is different and uses a different branch of the ChromeOS EC, and the communication interface changed - @DHowett went into detail here:

6 Likes

Much thanks for that link. After looking at the proposed linux kernel patches, I was able to build a working ectool from DHowett’s repo, with just this tweak (I am a bit surprised this was sufficient):

--- a/include/ec_commands.h
+++ b/include/ec_commands.h
@@ -120,7 +120,7 @@ extern "C" {
 #define EC_LPC_CMDR_SCI                BIT(5)  /* SCI event is pending */
 #define EC_LPC_CMDR_SMI                BIT(6)  /* SMI event is pending */
 
-#define EC_LPC_ADDR_MEMMAP       0x900
+#define EC_LPC_ADDR_MEMMAP       0xE00
 #define EC_MEMMAP_SIZE         255 /* ACPI IO buffer max is 255 bytes */
 #define EC_MEMMAP_TEXT_MAX     8   /* Size of a string in the memory map */
$ make utils PREFIX=/usr
..
  VERSION ec_version.h
  HOSTCC  util/ectool

$ sudo ./build/bds/util/ectool version
...
RO version:    azalea_v3.4.113237-ec:66fc84,os
RW version:    azalea_v3.4.113237-ec:66fc84,os
Firmware copy: RO
...

I’m, uh, not sure if there was a more obvious/intended way I should have known about, if this is old news or bad advice, my apologies :sweat_smile:

(I first tried using the upstream framework repo branch “lotus-zephyr” which he mentioned is used for the AMD model, and I could not figure out how to just compile ectool, with appropriate board config includes …)

3 Likes

@pierce interesting, have you noticed any incompatibility with that? Do commands such as ectool led power off and ectool fwchargelimit 60 work?

The changes in the kernel patch set were quite minimal, but I’m surprised changing the port was enough. Maybe @DHowett could elaborate?

Many commands do not work on my AMD Framework, but I suspect that some of those never worked on framework models, having been designed for chromebooks?

fwchargelimit works fully.

led is a bit weird, I could only get the power button to full brightness or off, color and level don’t seem to work, and it stays on even when the laptop is otherwise fully off, and I seemingly couldn’t fix it back to normal behavior without resetting/rebooting the EC. Partly due to my limited understanding, probably.

Also working:

  • version
  • uptimeinfo
  • battery
  • temps all
  • console
  • pwmgetfanrpm
  • fanduty
  • autofanctrl

I haven’t found working “typec” or “pd” related commands yet …

2 Likes

Sorry I’ve been distracted from this thread lately!

So! The only meaningful EC differences between the AMD Framework Laptop 13 and the earlier models are:

  1. It is using the more common Chrome EC protocol …
  2. … with a different base port for memory-mapped I/O.

Because of [1], most of the drivers already supported it. Because of [2], though, they just didn’t know it. :person_shrugging:

Absolutely true! The Framework Laptop doesn’t use any of the EC’s type C port management / port controller capabilities, for example.

Thank you for doing this!

I’ve updated my primary fork of ectool with a similar (albeit, more backwards-compatible!) change.

I suspect that rather a few people aren’t over on the new repository, so that could pose a bit of a problem… :smile:

… I’ve also finally pushed the patches for my UEFI EC toolkit …

8 Likes

Thank you @DHowett for this!
I get an error while building ectool from your gitlab repo on archlinux:

 ~/Desktop/ectool-main/build/: make ectool                                                                                          ✔ 
[  6%] Building CXX object src/CMakeFiles/ectool.dir/ec_flash.cc.o
[ 12%] Building CXX object src/CMakeFiles/ectool.dir/ec_panicinfo.cc.o
[ 18%] Building CXX object src/CMakeFiles/ectool.dir/ectool.cc.o
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: cc: not implemented: non-trivial marked Initializations not supported
  966 | };
      | ^
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
/home/foer/Desktop/ectool-main/src/ectool.cc:966:1: not implemented: non-trivial marked Initializations not supported
make[2]: *** [src/CMakeFiles/ectool.dir/build.make:104: src/CMakeFiles/ectool.dir/ectool.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:116: src/CMakeFiles/ectool.dir/all] Errors 2
make: *** [Makefile:91: all] Errors 2

I’m not a programmer so i have no idea what caused this…maybe you have a hint for me?

Update:
The build is working now…i choosed the wrong compiler. The tool works fine now on AMD 7480U. Thank you!

2 Likes