Open Sourcing our Firmware

[Fraoch]

Paging @DHowett !!

Exploring the Embedded Controller

Hey all! For the past week, I’ve been exploring the embedded controller on our awesome laptops, and I’d like to share some of my findings. This is going to be somewhat structured and somewhat stream-of-consciousness, so bear with me. Most of the same findings are written up on my website at The Framework Laptop's Embedded Controller (EC) :: HowettNET. Rationale @nrp mentioned here that the EC firmware is based on chromium-ec, and it seemed like it would be a fun challenge to revers…

Based on some of the comments by Kieran in that excellent thread, I’m sure there’s cooperation.

[FrameworkBee]

@Graham_Lane

It would be fantastic if you had certified releases that are based off community firmware development on the web site so those of us looking for certain features had a safe place to download from.

This is definitely something to look into!

[Alex_Haydock]

This is fantastic news — thank you!

[Shiroudan]

Absolutely amazing! This is why I love the framework team lol, it’s a refreshing breath to have a team so intertwined with the consumers.

[DHowett]

HELL YEAH FRAMEWORK TEAM! Thanks so much!

edit notes: switched to more inclusive language! “guys” is not inclusive.

[Stephen_Manis]

Maybe this will lead to a cure for the issue with my Framework laptop where it drains the main battery when completely shut down.

[junaruga]

Great news. Thank you, Framework team!

Now I am checking the source code. Maybe the following diff shows the Framework specific modifications.

$ git diff c7fea151a88925c8167d7ad788452cdca3635215..hx20

or GUI.

[feesh]

They really did it!

@junaruga from the readme:

Most changes are limited to the following folders, however there are some modifications in common.

board/hx20
chip/mchp

[Conan_Kudo]

This is absolutely awesome, congratulations Framework!

@nrp

Fedora 35 works out of the box with full hardware support for the Framework Laptop, so we’d recommend that as an ideal entry point if you’d like to try Linux.

Aww, thanks! We love Framework too!

[Nathan_Dehnel]

Would Coreboot be able to make use of this?

[pawalls]

@nrp

we’ve published the open source Embedded Controller (EC) firmware for the Framework Laptop , available today on GitHub

@nrp – Thank you! This news switched my planned purchase of a Star Labs Starbook Mk V to a Framework Laptop. I’m looking forward to more news of this sort, especially re: BIOS/UEFI firmware.

[D.H]

I would give you a standing ovation, but I’m sitting at my desk

All jokes aside, very well done Framework Team

[mrwm]

With the EC now open, does that mean that it’s possible to map a ThinkPad keyboard to the framework laptop? It sounds like a fun thing to try out.

[Jonathan_Haas]

Nice. Also looks like you’ve already fixed the amber blinking LED when charge is disabled because of the limit: https://github.com/FrameworkComputer/EmbeddedController/commit/d8fa4cc0f83d49d3c912cc8a5bfed2823bf662a9

[bibliobone]

This sounds like fantastic news, though I’m not extremely clear on what exactly the EC Firmware controls. What sort of projects can I expect to be able to try using this?

[SodaStream]

This sounds really cool! Do we know where/what flags (if any) gets set when the Fn lock is toggled? Because I have a cool idea for a Windows tray app, and it sounds like “Fun Indicator!”

[DHowett]

@SodaStream

This sounds really cool! Do we know where/what flags (if any) gets set when the Fn lock is toggled?

Nothing that is exposed to the host, unfortunately! In board/hx20’s keyboard customizations you can see how Fn is tracked, but that’s all internal state.

[mackncheesiest]

Great to see it, Framework team!

Thinking ahead for the future, I’m hoping to fill in a few gaps in my understanding of how to actually utilize this firmware.

1. What are the methods for actually programming new EC firmware? Is there an exposed flash programming interface on the mainboard? The BIOS updates have clearly been doing it through some software-based approach as well.
2. Would there be any best-practices for reducing risk in experimenting with firmware changes? Some form of QEMU that can help at least verify the board won’t immediately halt and catch fire (even if the pretend hardware isn’t quite right)? Have a flash programmer on hand and a known-good copy of the EC firmware lying around? Test on an ARM M4 devboard? Give the code a second read through before programming?

My previous experience making changes in CPU boot firmware was only ever tested via FPGA emulation, so I’ve never needed to worry about actually breaking something

Edit: poking around a bit, ARM’s Fixed Virtual Platforms for the Cortex-M4 seem to require licenses, so that (coupled with the fact that there doesn’t look to be any Microchip Cortex-M4 platforms in the current set of qemu-system-arm boards) probably eliminates any “simple” QEMU-esque approaches

[feesh]

@mackncheesiest

Is there an exposed flash programming interface on the mainboard?

The readme points to traces on the mainboard where you can debug (and presumably flash) the EC via JTAG. Though you would need some extra hardware/solder some wires.

I would also be interested in a guide for a software approach though.

[mackncheesiest]

@feesh

I would also be interested in a guide for a software approach though.

Looks like @DHowett put together more details on software programming in a previous post. That ectool binary mentioned there is built by default with the repo’s hx20 instructions under build/hx20/utils/ectool. make utils builds it separately under build/bds/util/ectool as well.