I have put instructions on how to flash new EC firmware here.
The new EC firmware should fix the âBattery flippingâ issue.
Please be aware that there is a risk that you could brick your laptop, with the only fix being sending it back to Framework.
Please only try it if you are sure.
DISCLAIMER of LIABILITY. The information provided is offered âas isâ and without any warranties, express or implied. I disclaim any and all liability for any actions taken based on the contents here.
It is a long process of downloading and compiling various tools.
Please let me know whether it works for you or not.
Link to instructions:
Note:
These instructions only work for âazaleaâ and âlotusâ laptops. Essentially, it only works for FW13 AMD 7640U / 7840U and FW16 AMD 7840HS based laptops currently. It has not been tested and probably will not work on Intel based laptops.
Has anyone tried my EC firmware?
From a risk perspective:
My instructions try to ensure the new EC firmware is written only to the RW part and not the RO part of the flash.
If one succeeds in writing to the RW part of the flash, and leaves the RO part unchanged, it should not brick your laptop.
If you mistype my instructions and accidentally write to the RO part of the EC flash, it is not something I have tested, and it might brick your laptop. In all my experimentation, I only wrote to the RW part of the flash. I have never attempted to write to the RO part of the EC flash.
I am waiting to see if Framework has more communication about BIOS 3.08 first. They seem to think it would solve my issue. Itâs been about a month since weâve heard from them, so they ought to be giving us some kind of update soon.
I read over your instructions. They seem mostly straightforward. I might build a docker container to simplify the compilation steps, since they seem to be Debian-specific and Iâm on Arch (probs a holdover from the Chromebook days )
It should work on non-debian/ubuntu distros.
One might just need to modify the apt install steps to be dnf install commands instead.
If it helps, I could just upload the binary of the ec firmware, and then anyone could do the upgrade using the EFI shell, that works on both Windows and Linux because it uses the EFI shell environment before an OS loads.
Regarding my fixes for the mini-cycles charge / idle / discharge bug in the EC. There has been no peep from FW as to whether they wish to include my changes or not.
I had an initial email thread open with them regarding one aspect, whether all FW main boards supported the IDLE state, they have been silent since then.
So, I have no idea whether or not they will actually really fix all the edge cases with their upcoming BIOS release.
Here are some of the edge cases:
The battery BMS re-calibrates itself periodically. This can result in the charge % changing, thus trigger charge / idle / discharge cycles.
Not all uses wish the battery to discharge with the AC PSU connected. So if the user changes the battery limit from 80% to 60% they donât expect it to immediately discharge, whereas others do like that behavior. This should therefore be configurable.
There is need for a hysteresis around the transition between IDLE and Normal (Charge).
There is a need for a hysteresis around the Discharge / Idle. During charge there is a possibility for the charge of overshoot the battery limit %. It should switch to IDLE here, instead of immediately discharge back to the battery limit %. It add unnecessary charge/discharge cycles.
The charge can skip the battery limit value, e.g. during a BMS re-calibration, and in this case, currently it just keeps charging up to 100%.
My EC fixes, cover all these edge cases by improving the battery sustain code to have 3 limits.
Limits are: lower, upper, discharge
SOC = Current charge %
State NORMAL (Charge if AC connected).
If SOC > upper, switch to IDLE.
if SOC > discharge, switch to DISCHARGE
State IDLE (Donât try to charge, even if AC connected)
If SOC < lower, switch to NORMAL
if SOC > discharge, switch to DISCHARGE
State DISCHARGE (Discharge the battery, even if AC is connected)
if SOC < upper, switch to IDLE.
if SOC < lower, switch to NORMAL.
If the user does not wish to ever force the DISCHARGE state, they set the âdischargeâ limit to > 100%, e.g. 120%, so it can never be reached.
It is a very simple state machine, but covers all the edge cases well.
Thatâs really unfortunate. The fact that this is a âCommunity Forumâ aside, it kind of seems like Framework really has no system set up for proper contributions to upstream, and given the debacle that is their firmware situation right now, I cannot see such a thing happening, even though if they did, the situation would improve drastically for folks. I want to assume best intentions on Frameworkâs part. Community contributions to the official firmware of the device would fill a very wide gap in their support.
Though that is becoming increasingly more difficult, especially given that last night support told me:
As much as we want to provide how many weeks, months it will take to release the BIOS update however, we still donât have any update yet.
The Open Sourcing of their EC firmware is either virtue signaling, or a legal requirement. I seriously do not understand how this company cannot provide firmware support with relatively minor, low effort software patches, and yet was able to design and release TWO new products for this year.
I know Iâm just shouting into the wind at this point, but I feel Iike I got scammed. At this point, I have no other option than to assume this product, less than two years after I bought it, is no longer going to receive any software updates, and canât in good conscience recommend people buy Framework products. I would very much like to have my mind changed, and the only thing thatâs going to do that is if Framework actually allocates enough resources to bring the software support up to a standard deserving of the price tag.
So you plan to release the binaries for Windows users as well? The work youâve done is amazing but I wonât use it on my Debian install because I use Windows for gaming, where I need the full performance.
Amazing job by the way, Framework should definetly take notesâŚ
If you donât wish to compile from source, but just install the binary EC firmware.
You can following these instructions (skip the compile step, but follow the rest):
It only works for FW13 AMD 7x40U (azalea) and FW16 7x40HS (lotus).
When flashing the firmware, look at the âgo.nshâ and change the filename to âec-azalea.binâ or âec-lotus.binâ depending on which mainboard you have.
If you try to write a lotus one to a azalea mainboard, it will prevent you. It does a check that the EC firmware image is for the right mainboard.
This process will work on both Windows and Linux as the tools are EFI shell based, so work before an OS is booted.
Note: I donât know where the EFI partition appears in Windows, so the file paths might need changing for Windows.
Example output, if you try to write a EC Firmware image to the wrong mainboard:
Gentle reminder - we are curating from this only. Feel free to add your additional details and findings in the same post, but, we need these details otherwise we are fishing in the dark.
For us to track and address this, we need specifics. The initial gitlab post has âArch Linux on a Framework laptopâ which lacks critical information.
All affected, please provide, using this flow (please keep it short and to the flow below):
Framework Model:
(Please be specific; Framework Laptop 13 AMD Ryzen 7040 Series, Framework Laptop 16 AMD, Framework 13 , Framework Laptop 13 13th Gen Intel Core, etc - because this is a FW13 forum thread, likely only affecting FW13 folks, but we need details on which hardware is affected)
Distribution and release affected:
(Arch users, just provide the kernel used and the last time you updated)
Your upower version:
(This is the version you are running, after fully being updated with your packages and confirming the behavior still exists)
Confirming yes or no you are using stock power management:
(Confirming there is no additional governor, TLP, etc is use - your running a stock configuration. For Arch users, you are using TuneD-PPD or PPD only.)
Power adapter used:
(Framework provided or if its yours own, we need brand, model and power specs)
Which expansion bay are you connected to for power:
(As this is for FW13 models, with the laptop facing you, please indicate if it is top left/ top right, bottom left/ bottom right.
I acknowledge this started out as FW13, Arch in this thread. But I suspect this may be affecting other platforms as well, hence the details above.
Please do not skip over any of these details, I need all of this to have something actionable to pass along to engineering. Thanks
Maybe you could forward the problems that @James3 found in the EC controller firmware, as this appears to be the root cause of a lot of the problems that upower has