hello, Sorry if this has been said elsewhere but am i correct in thinking that changing the colour of the power led on the framework 16 isn’t possible?
when i try to change it i get result code 3
i also get code 3 when trying to specify a side which i remeber someone saying isnt do able on the fw 16.
is there any reason why that inst exposed on the newer versions?
and one more thing is it possible to trigger the battery disconnect in ectool rather than limiting the charge can do the same thing as the bios disconnect option?
I notice that Dave Howett’s framework ec page is dated 22-Dec-2022 and so doesn’t mention the AMD Framework 16 laptop. But his ectool does support it.
To save others from figuring out how to compile it - just clone the repo and then follow the commands listed in the .gitlab-ci.yml file. Note: it needs root permissions to work. The command: ectool version gave
RO version: lotus_v3.4.113353-ec:b4c1fb,os:
RW version: lotus_v3.4.113353-ec:b4c1fb,os:
Firmware copy: RO
Build info: lotus_v3.4.113353-ec:b4c1fb,os:7b88e1,cmsis:4aa3ff 2024-03-26 07:08:43 lotus@ip-172-26-3-226
Tool version: 0.0.1-isolate Jul 9 2024 none
DHowett in this discussion mentions the code is Zephyr port of the ChromeOS EC
which I presume is chromiumos ec platform but then links through to some very long complex multi-git extractions to build .
Sigh - it does seem very hard to find the actual EC source code.
Also it seems that the AMD Framework 16 EC datasheet is not freely available - probably have to have a login account at nuvoton to get it…
The good news is that the ectool is working well even if the documentation of the EC and the firmware source is very difficult to obtain.
Also interestingly
ectool chipinfo
gives
Chip info:
vendor: Nuvoton
name: npcx9m3f
revision: 00160207
4 Likes
The actual EC source code for the Framework 13/16 AMD models is around here: EmbeddedController/zephyr/program/lotus at lotus-zephyr · FrameworkComputer/EmbeddedController · GitHub
2 Likes
Thanks – I’ve downloaded it - now look at how to build it - seems I need the zmake command as per zephyr build instructions
I have downloaded the chromium code which builds depot_tools
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/local/games:/snap/bin:/home/amw/src/depot_tools export PATH
fetch chromium
cd src && ./build/install-build-deps.sh
gclient sync
- which took about 12 hours… and gets me the cros_sdk tool but not zmake…
There’s a CMakeLists.txt in their repos, so you should try compiling using cmake.
I’m not sure whether “EndeavourOS” packages the ChromeOS EC drivers by default; you should be able to discover if it does by checking…
- Is there a
cros_ec_lpcs.kounder/lib/modules?- `find /lib/modules -name ‘cros_ec*’
- Is
/dev/cros_ecpresent?ls -l /dev/cros_ec
- Are the modules throwing any errors?
dmesg | grep cros
LEDs
Unfortunately, yes - both of these things have changed with the AMD framework laptops.
The power LED no longer supports anything but white; it was updated for compatibility with the chromebook edition which only supported white.
I suspect they wanted to keep documentation between the models similar.
The side LEDs are treated as one entity, “charge” or “battery”, in the AMD boards and probably any newer boards as well.
Battery
You can issue a battery disconnect manually with ectool batterycutoff.
The machine is not intended to be used with the battery shut down. Do this only for experimentation.
In addition to what @pierce said (thank you!), I wrote up a quick gist explaining how to take a clean Debian install (I used a container, but you can use bare metal or whatever) to a Zephyr build environment. It’s actually terrible.
That gist is here.
If you are trying to build for the Framework Laptop 16 AMD, use lotus anywhere you see the name azalea.
3 Likes
On a FW16 I have:
lsmod |grep cros
cros_ec_lpcs 20480 0
cros_ec 20480 1 cros_ec_lpcs
/dev/cros_ec is not present.
dmesg | grep cros
[ 21.416956] cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected
My guess is the ACPI config is not set up correctly.
For the AMD Framework Laptops, you need to be on kernel 6.11 or greater, or apply the kernel patch here: [PATCH v3 0/4] platform/chrome: cros_ec_lpc: add support for AMD Framework Laptops - Dustin L. Howett
Thanks - that worked fine!
Surprisingly I did need to explicitly add contrib to my repository - perhaps that is no longer default on Debian bookworm.
Now perhaps I can debug some of these black screen crashes.
I’m getting this error on FW 13 Intel 13th gen, is there any way to fix this? I couldn’t figure it out… Just FYI I’m on BIOS 3.05 (recently released)
❯ sudo ectool chargecontrol
ERROR: Old EC doesn't support GET.
Usage: chargecontrol
Get current settings.
Usage: chargecontrol normal|idle|discharge
Set charge mode (and disable battery sustainer).
Usage: chargecontrol normal <lower> <upper>
Enable battery sustainer. <lower> and <upper> are battery SoC
between which EC tries to keep the battery level.
❯ sudo ectool chargecontrol normal 20 80
ERROR: Old EC doesn't support sustainer.
Usage: chargecontrol
Get current settings.
Usage: chargecontrol normal|idle|discharge
Set charge mode (and disable battery sustainer).
Usage: chargecontrol normal <lower> <upper>
Enable battery sustainer. <lower> and <upper> are battery SoC
between which EC tries to keep the battery level.
I may be mistaken, but I think those commands are only functional on the AMD platform’s EC, which uses a new architecture.
1 Like
I just built mainline v6.10 and Dustin’s patches are already present -
commit c8f460d991df
Author: Dustin L. Howett <dustin@howett.net>
Date: Tue Apr 2 19:47:13 2024 -0500
platform/chrome: cros_ec_lpc: add quirks for the Framework Laptop (AMD)
The original Framework Laptop 13 platform (Intel 11th, 12th, and 13th
Generation at this time) uses a Microchip embedded controller in a
standard configuration.
The newer devices in this product line--Framework Laptop 13 and 16 (AMD
Ryzen)--use a NPCX embedded controller. However, they deviate from the
configuration of ChromeOS platforms built with the NPCX EC.
* The MMIO region for EC memory begins at port 0xE00 rather than the
expected 0x900.
cros_ec_lpc's quirks system is used to address this issue.
Signed-off-by: Dustin L. Howett <dustin@howett.net>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Tested-by: Thomas Weißschuh <linux@weissschuh.net>
Tested-by: Mario Limonciello <superm1@gmail.com>
Link: https://lore.kernel.org/r/20240403004713.130365-5-dustin@howett.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
M drivers/platform/chrome/cros_ec_lpc.c
-
My FW 16 hibernates and recovers ok with power cable plugged in
-
But if I then unplug the power and use zoom-client (a snap in debian bookworm) to connect to a meeting it freezes for a about 3-5s then goes black screen and after a while reboots. Strangely the ectool console shows no sign of the reboot that I can see - https://paste.debian.net/1323605/
1 Like
I didn’t realize it had made it into 6.10. Thanks!
1 Like
You need to build it from the source code. [later: I was mistaken. Binaries are available. See @deLemere’s post under this one.] There are links to Dustin’s ectool web pages (for crude instructions) and his git repo in this thread. I’ve not actually built it myself (although I understand the process).
I’ve been following this thread for a couple of years. The tool’s capability, build process and compatibility gotchas are explored in a lot of detail. If you’re thinking of building it yourself, grab a beverage and start reading from the first post.
If you summarise your system (FW model, distro and kernel version) someone who’s built it for a similar system might be willing to help you avoid any of the bumps they found in the road.
Dino
edit: corrected a misunderstanding for future readers.
3 Likes
You can download here:
2 Likes
I apologize if this is already answered in this thread. I tried searching for “flash RW” or “write RW” and came up empty handed. I’d like to build a new version of the lotus EC and write it to my RW slot. My primary interest is fixing the bug where the CPU gets stuck throttled at low MHz after being plugged in and waking. Unfortunately, with the console commands disabled and the read to memmap only taking a single byte means I can’t get a read out of EC_MEMMAP_POWER_SLIDE (0x151). Same issue with enabling safety_pwr_logging since that requires a console command. I figure a custom build can log the right data for my debugging and allow me to hopefully figure out where the bug is that is getting me stuck in a throttled state (or at least allow me to send a command to unstick things).
Is there good documentation as to how to build a local branch and flash it to RW (plus how to get back when it inevitably goes wrong 
).
Btw, for anyone wanting to use Github search to find things, I forked the Framework/EmbeddedController repo and made a branch with the current lotus EC code as the default branch. That makes it so searching the repo in Github searches that branch instead of the hx20-hx30 branch. I made a new branch instead of using the lotus-zephyr because I didn’t realize that was already at the correct commit
Is it possible to make another key (eg caps lock) act as the fn key?
I was successfully able to map caps to other keys (like esc) but not fn.
Here’s what I tried so far:
- get matrix position of
capsandfnfrom fw matrix (4,4 and 2,2) - ask ectool what the scancode is for
fnusing these instructions (it’s apparently 00FF ie 255) - use the command
ectool raw 0x3E0C d1,d1,b4,b4,w255(found here) (theb4,b4is the matrix position ofcapsand thew255is scancode forfn)
It didn’t work. (My caps-lock key then made an equal sign and caused my touchpad to stop working.) Then after a bit of research I found out that the fn key probably doesn’t even have a scancode?
But I was given hope by this comment: