firmware-open VS EmbeddedController

This reminds me a lot of FW update a8dd6c2, since rolled back, which came out about 4 months ago and caused problems with darp8 (e.g. https://github.com/system76/firmware-open/issues/469, https://www.reddit.com/r/System76/comments/1692nd2/darter_pro_fails_to_resume_after_fw_a8dd6c2/, https://www.reddit.com/r/System76/comments/168oehz/new_coreboot_update/)

I suspect that my current settings are still "overkill", so I'm wondering if there's a nice way (in the absence of https://github.com/system76/firmware-open/pull/365 being merged!) to find out what the minimum speed is I can get away with without my laptop spontaneously combusting? :D

There is an issue about this: https://github.com/system76/firmware-open/issues/407 They closed it (because there was an update), but yeah it's definitely not fixed. You can subscribe to this issue to see what's going on, but do not get your hopes high - they will rarely, if ever, update the issue.

There isn't a way without flashing the firmware at least once, but there is this PR instead which exposes userspace fan controls, which might work with some of the fan control software in Linux.

Issue opened: https://github.com/system76/firmware-open/issues/432

What Framework can't offer is Coreboot with Management Engine Cleaner and other great specs. System76 just announced a new fully open source bios for their intel 10th - 13 th gen models: https://github.com/system76/firmware-open/blob/77abfadf24c9a0c45ae042cd71d3ce7be26c846e/FEATURES.md

Hi! I check the firmware-open repository from time to time and noticed that since the initial release a few potentially interesting things have been committed (e.g. Disable ME by default on everything but TGL-U or Support for NVIDIA Dynamic Boost ). Should I wait for the "official" update to show up in firmware-manager? These changes seem to have been released quite some time ago, but there is no trace of them in the GUI. I am inclined to build and flash it myself. I've flashed my ec in the past, but I don't want to set the versions of ec and firmware-open too far apart. What's the policy here? There is this warning here about "normal" users who should not do this themselves. Perhaps I am not normal :-/

git clone --depth 1 https://github.com/FrameworkComputer/EmbeddedController cd EmbeddedController make utils sudo ./build/bds/util/ectool #USE AT YOUR OWN RISK - YOU CAN BRICK YOUR LAPTOP

When I was getting ready to flash again, I noticed an issue about the compiler version used to build the firmware binary. I followed the advice, but more importantly I noticed that the issue has been recently fixed, and in the resolution, the maintainer says "Next release (hx20 3.19, hx30 3.07) will include them". It reminded me of something crucial: the Framework EC firmware source code repo doesn't have any particular indication of its level of stability at any given commit. Which commits could be considered fully tested releases? What if the head of the branch introduces a bug that they're working on fixing?

The EC code on the normal Framework devices is already based on the Chrome EC code anyway. https://github.com/FrameworkComputer/EmbeddedController

EC firmware is open sourced by framework: https://github.com/FrameworkComputer/EmbeddedController

There the keyboard input is handled by the embedded controller: https://github.com/FrameworkComputer/EmbeddedController/blob...

On the 16 the keyboard is a USB keyboard that could even be used standalone, without the laptop.

I tried the pre-compiled `ectool` from the TamtamHero's repository as we and comiled the EmeddedController from Framework (from this repository). Both give the same error message.

Great reminder that (as of right now) we're far removed from hardware that is 100% free (as in freedom). The closest we've got is probably provided by Raptor Computing Systems. However not everyone in the world is privileged enough to own such devices unfortunately. And I haven't dabbled into other possible mishaps that come with using such devices. The lack of "free-hardware" is a major concern though. I'd argue that there aren't enough reasons to be optimistic about this as of right now. Therefore our best bet is to not let good be the enemy of perfect; light at the end of the tunnel...

As far as I'm aware the only way to manually change the fan speed is using `ectool` from https://github.com/FrameworkComputer/EmbeddedController/

We open sourced our Embedded Controller (EC) firmware and made it available on GitHub for you to modify if you wish.