Actually, the only thing I really care about is whether the addresses used for the respective features are the same, even if the overall feature set might differ a bit. I’m not interested in modding the EC itself, just in using the commands that it offers.
Because the biggest impact on my buying decision would be:
How stable has the EC API been and will it be across the years?
(Sidenote: Just curious if somebody who knows happensto stop by… How did it happen that the default and main branch in the EC repo diverted by thousands of commits?)
The Intel Framework Laptop 13s use a Microchip MEC1521, and the AMD ones (13" and 16") use a Nuvoton NPCX9.
Intel
The embedded controller firmware is based on an older version of the ChromeOS EC; this is what is in the default branch (hx20-hx30). It diverges heavily from the main branch, because main tracks ChromeOS upstream.
Apart from the modifications to the core EC “OS”, all of the code is in baseboard/fwk and board/hx[23]0.
AMD
This one is based on the Zephyr port of the ChromeOS EC, and tracks mainline more closely. It is in the branch lotus-zephyr.
All of the model-specific code lives in zephyr/program/lotus.
The 13"-specific code lives in a few subdirectories off the main tree named azalea.
The EC host command API has been very stable.
The communication interface changed between the MEC1521 and NPCX9; more details are available in this Linux patch series.
If you’re looking to develop a tool for the 16" model, you’ll need to switch to the NPCX9 communication protocol with Framework’s specific modifications to the memory-mapped I/O region.
I’ve been working on porting FrameworkHacksPkg (my EC UEFI toolkit) and CrosEC (my Windows driver) for the same.
Thanks a lot for the very quick and thorough response!
While digging through everything and also chatting with GPT about it, I realized that I maybe should’ve asked from a different perspective. Which would be not from what I’ve seen in the community here so far but instead from what I’ve already done in the past.
Assuming Windows only for everything that follows:
Because what I would want to do is create a tool mostly about fan control suitable for most users like I did for my Gigabyte laptop. So, e.g. disabling test signing is unfortunately not acceptable. And it obviously uses ACPI instead of EC directly.
I wouldn’t mind migrating to using the EC directly since Framework doesn’t seem to have implemented an ACPI abstraction but all Google spits out was about ACPI and GPT essentially just went on and on about “bla bla SECURITY CAN’T DO bla bla”. E.g. nbfc clearly is able to do it somehow but that’s a project of some complexity and I can’t find the actual EC communication implementation, only interfaces…
We don’t have to solve this now, my purchase would probably be next year but… it would be great to have the some indication that what I want to do will work.
About your porting work: Just a thought but… do you know why the EC doesn’t simply have a command like “EC_GET_IO_START_ADDRESS” rather than have every dev that uses it manage a list of platforms? At least to me, that seems a lot more straightforward and would probably improve compatibility.
(I just noticed that you’re maybe the main contributor for terminal! Thank you so much for bringing the Windows command prompt into the 21st century!! )
)