Q: Librem 14 EC firmware

@MrChromebox

Quoting: Librem 14: Adding Librem EC, Freed Embedded Controller Firmware post

We will see that the EC firmware can be recompiled and flashed in the field by everyone(*). Some of the before-mentioned features will come as a user serviceable firmware upgrades after shipment of the laptops has started, for which we will of course provide pre-compiled binaries too.

Does this mean the EC firmware will be included in PureBoot/Coreboot/seaBIOS image? Or will I have to flash EC firmware separately? In case of the latter how would that be accomplished on Qubes OS?

it will be a separate update, likely using a Linux utility bundled with PureOS. Your best bet will likely be to boot a PureOS Live USB and update that way. But we’ve not determined anything for sure yet.

1 Like

I has been testing this week the new EC Firmware v1.10 already released, I just want to report that work really really good stable, no more any random shutdown or coil noises.
I hope that Purism enable the KillSwitches for BIOS and EC soon.

Purism: Librem14: EC: BIOS: New EC/Coreboot v1.13/4.19 firmware is out. :rocket:
Thanks Purism for the good work all time!

1 Like

Tested and autodetect-headphones work!!!
Kudos for @jonathon.hall

Tested with QubesOS. It detects headphones and it detects and enables microphone as well. Good job.

Switching from speakers to headphones seems quite slow. In Qubes it switches in 1-2 seconds after plugin/out. I would expect it be nearly instant. Not sure if it’s OS, hardware or firmware issue.

The Librem-EC 1.13 and coreboot 4.19-Purism-1 updates have fixed the issue affecting my sys-audio qube in Qubes OS, and I have posted a new HCL Report to the Qubes OS Forum.

Thank you @jonathon.hall.

Yes, this is known in the EC firmware currently.

The EC has very little RAM and resources to work with, so it divides up its work into a few groups depending on how frequently they should run. Some things run “as fast as possible”, some things run “every 1 second”. So as the EC loops it runs the “fast” things all the time, and whenever 1 second has passed it will run the “1 second” tasks.

We have to keep the “fast” things very tight, so the jack detect fell into the “1 second” bucket. But it takes a while for an ADC measurement to complete, so we have to kick it off, then sense it on the next loop, 1 second later. That can add up to 2 seconds from the physical jack being plugged to the EC comparing a completed ADC measurement.

There are some ways to address this, but I wanted to get some feedback on the working jack detection before we go making wider changes to the EC firmware.

2 Likes