edit: now it worked, it seems that i forgot to remove the # in the conf file or didnt safe it correctly. now all the ports arent working but im trying the workarounds mentioned in this thread.
everything worked, fedora 36 with luks encrypted / home, unencrypted efi and boot, secure boot was enabled all the time
this also worked for me, thanks!
Anyone tried to update the BIOS from Windows booted from expansion card drive? Or is that a no-no?
Success on pop!_os 22.04 via LVFS. Giant thanks for bringing its support!
Updated from EFI, just in case. 
@Kieran_Levin @nrp Whoa, I just realized that I’m experiencing a major issue since updating… My laptop is no longer charging when powered off!
A couple nights ago I powered off around 57%, put it on the charger, and went to bed. I noticed in the morning that the LED was still solid orange. That surprised me because the release notes say that it should be solid white now, whereas it used to be flashing orange sometimes when finished charging. Then I opened the laptop and found it at 57%. Last night and this morning I reproduced the issue.
Am I being dumb somehow, or is this a major bug in 3.09?
If the laptop is powered on with the lid open or closed in s2idle, it charges fine.
I’m seeing similar behaviour (not charging when powered off):
Yes and yes. Still not having any luck and I’m at a loss as to why.
I can confim the report (BIOS 3.09 Beta release - #97 by tim300) regarding the lack of charging when my computer is not powered on. 66% and still 66% after an hour. Normally I would have seen a full charge in that length of time.
@tim300 and others, thanks for reporting on this find. I would love to help test or confirm the bug, but not charging while the laptop is off is a showstopper for me, so I’m gong to have to stay on 3.07 for the time being. Looking forward to hearing a definitive answer as to whether this affects all Framework units, only those using Windows, etc…
I can reproduce the issue of the system not charging when it is off.
It looks like it can be induced by powering the system on, off, then waiting a few seconds and plugging in the charger.
The EC is commanding the charger to charge the battery, but I suspect the the analog reference is not being enabled correctly, so the charger is not actually charging the battery.
We will fix this ASAP and release an updated bios.
Yeah, my normal workflow has been to power off when I’m not working, and then only put it on the charger as necessary. When I have some more time, I’ll look at how to roll back to 3.07, unless “ASAP” from @Kieran_Levin means “in the next few days.”
If the power is already plugged in and charging proceeding at the time of shutdown, does charging continue after shutdown?
What happens if the laptop goes to 0% battery and goes off? Since won’t be able to charge while powered off, laptop will go to a limbo state/bricked? I think I’ll keep my laptop connected to power until this is fixed.
Thanks! Will you update the bios, bumping a version as 3.10 or the same new 3.09? If you update as 3.09, can a user who has the current 3.09 upgrade to the new 3.09 by LVFS? I hope you will dump it to 3.10 for us to distinguish issues reported by users.
@Ricardo Based on my testing, your concern should not be a problem. As if the battery runs out, and power is attached then the system will charge.
I edited my original post, and mentioned that this is recoverable by unplugging AC when the system is off and then plugging it in again after 1 minute, and the system will commence charging again.
Why this recovery method works, is we fully power off the EC and other system power rails 1 minute after the system turns off when on battery, which resets some of the charging logic. So after this you can plug in AC, and the system will charge normally.
So this is pretty easy to recover from, and I do not see any behavior that would prevent the laptop from recovering from not charging.
@junaruga we will release a new version 3.10, so you will be able to update through LVFS, etc.
We are working on a fix for this today, but it will most likely take a few days to do validation, so I would not expect an update until next week.
All right! Thanks for that. As a future task, if we manage the bios version with “X.YY” (major, minor version), it is easy to run out until 3.99. The “X.YY.ZZ” or “X.YY-beta1” can be the solution.
Not even sure why minor version is zero-padded 2-digit to begin with…otherwise, we could go for 3.100 and beyond.
@junaruga bios version naming has to follow the SMBIOS bios information spec. Which allows for a major/minor release version of one byte each. We don’t want to break any standards with other versioning schemas. Systems like LVFS use this to determine what version the bios is using, and if it can be updated or now.
See page 31 of.
So we could go up to 255 then, if needed.
What does the major version of 3 signify though? e.g. Why didn’t we start with 1?