Open Sourcing our Firmware

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.


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 :slight_smile:

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

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.


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.

1 Like

Correct me if I’m wrong, ectool is just an interface between the EC and userspace, I’m not sure if it can be used to flash an EC binary.

ectool help lists all available commands and seems to include a number of flash-related ones (although I haven’t tested them so ymmv)

ectool help
flasherase <offset> <size>
      Erases EC flash
  flasheraseasync <offset> <size>
      Erases EC flash asynchronously
      Prints information on the EC flash
      Prints information on EC SPI flash, if present
  flashpd <dev_id> <port> <filename>
      Flash commands over PD
  flashprotect [now] [enable | disable]
      Prints or sets EC flash protection state
  flashread <offset> <size> <outfile>
      Reads from EC flash to a file
  flashwrite <offset> <infile>
      Writes to EC flash from a file

ectool flashwrite sounds promising, though

1 Like


I believe that ectool as shipped in that repository can’t communicate with the EC in the Laptop; it doesn’t look like it implements the MCHP LPC protocol in userspace, and the Linux cros_ec_lpcs driver does not yet support Framework’s specific I/O layout yet.

For now, you may want to use an ectool build from my repo (I’ll submit it as a PR!) as documented here.


Yes, please submit a PR. That would be excellent!


Sounds like an awesome first milestone for Community-backed improvements to the EC code. Way beyond my skills though… But I will vote for it just the same

1 Like

There’s the PR that adds support for communicating with this EC. It’ll be necessary until LKML: "Dustin L. Howett": [PATCH 0/2] platform/chrome: Add support for the Framework Laptop is accepted – which it may not be. I’ll poke the maintainers again after the weekend.


And disable Intel Me (Management Engine) / AMD Platform Security Processor (PSP)


The schematics are currently available for repair shops. Will the schematics be also available to open-source developers?

1 Like

Awesome! I’m very excited to try that out.

My current Acer laptop actually isn’t working properly due to a firmware bug / sleep resume crash / bios priority order panel malfunctioning (random letters there).

Ordered in batch 7, Looking forward to see / tryout the open-source firmware, might also try to learn and contribute to it if I can :grin:

We don’t currently have the ability to provide schematics to individual consumers, but we are working on ways to better support community software development.


It’s somewhere between. It’s basically that we have vetted that the Framework Laptop should work correctly for Ubuntu 21.10, Fedora 35, Manjaro 21.2.1, and now also Linux Mint 20.3 Cinnamon Edge (apart from any caveats called out in the guides) when the guide is followed. At the same time, we don’t yet have the depth of expertise in Linux in our support organization that the Community here has. Because of that, more custom setups, deviations from the guide (like using a different WM), or using other distros is something we would still point people to the Community for.


@nrp Sources to the FrameworkGuide should be great to open, if its on git. Might be easier for community to contribute to add more information, specially for notepoints and fixes which are usually not covered by distro docs because it follows for specific hardware. Or can we have a separate wiki instance running, for software debugging and installation steps?


for those following along, this is @DHowett’s updated patch series which appears to have been approved: LKML: Tzung-Bi Shih: Re: [PATCH v2 0/2] platform/chrome: add support for the Framework Laptop


Given that it was approved, any ideas on how long would it take to reach us, the end users?


I’d guess March might be the soonest possible release of 5.18

1 Like