@Daniel_Schulte @SodaStream Are you sure this behavior isn’t because unplugging your USB-C card results in a tiny bit of battery discharge? From what I can tell, the behavior is:
Charging: Steady orange
Reached threshold (not charging): Blinking orange (1s period)
Leans over; observes steady orange 22 minutes later
I’m pretty sure. Three seconds of discharge shouldn’t require 22 minutes (and counting) to trip into blink mode. Right now, Windows is reporting 86% and the light is steady.
I’m not even saying that it’s a horrible thing to happen, but that it can be distracting to slightly worrying when that kind of thing happens without knowing or understanding why. If there is a way to program a tolerance (say, within two percent of the configured threshold) that would result in a steady white, that would resolve some of the worry.
On the other hand, if it’s supposed to blink by now and it’s not, I’d wonder if anything else that relies on the battery threshold is triggering properly.
Oh weird. From what I can tell, mine stays blinking indefinitely. I have the threshold set to 79 and Windows reports it stopping charge at 80%.
The reason I believe this to be intentional is that the blinking is exactly 1 sec on, 1 sec off. Could be wrong though.
@D.H: you’ll probably be interested in this- The Framework Laptop's Embedded Controller (EC) :: HowettNET
@SodaStream I’ve discovered some limited key remapping, but not much else: The Framework Laptop's Embedded Controller (EC) :: HowettNET (this links directly to the key mapping section, even if the title doesn’t suggest that)
Try this:
From the Windows boot media, his Shift+F10 to bring up the command prompt. Then do the following:
…
Even this (SodaStream’s comment #47) didn’t work. I have a Windows To Go (“WTG”) bootable USB with Windows 10 on it. I resized its UEFI partition to 240 megabytes. That didn’t work. Later comments made me realize that the issue might be with the primary disk’s UEFI partition. So I then followed SodaStream’s instructions while within the WTG environment and that didn’t work either. My main drive’s UEFI partition is 512M in size and is almost entirely free.
Now, I know that the installer is attempting to do something with that partition because after it gives the usual “your BIOS doesn’t support secure flash” error, the letter assignment is removed (and the drive is no longer accessible through that letter until I assign it again). The partition stops showing up in the list of available mapped drives.
I have tried everything short of buying a new NVME disk just for the purpose of installing Windows onto it so that I can update the BIOS. It simply should not be necessary to go to such lengths just to update the BIOS.
What in the world is going on here??? I’m pulling my hair out over this.
I’m using Ubuntu Unity (https://ubuntuunity.org) version 21.04. My NVME SSD is 1 TB in size.
I fully expect the standard Ubuntu installer will create its UEFI partition in the same way that Ubuntu Unity did, so I shouldn’t be unique here in this. My system is a batch 6 system that came with BIOS 3.06.
An overview for those unsure of how to install the beta when on Linux (using Hiren Win10 USB Live Boot):
*NOTE: Try this at your own risk. Just because it worked for some doesn’t mean it will work flawlessly for you.
Using a Windows computer (haven’t tested it on Linux with .exe):
sudo dmidecode | less in your terminal to confirm new BIOS version (3.07)So when charging has hit the set amount will the led next to where it is plugged in begin to blink? Is this normal behavior?
I believe so, that is certainly what is happening to me when I set it to 80% charge and it reaches it
The 0.0.3.6 on LVFS testing is the prior beta version, the 3.06 one.
For the Linux/BSD/etc users. I have updated the first post to include a link to an EFI based updater that you can run from a thumb drive.
I am seeing an issue where the update fails in Fedora 35 from LVFS.
Sorry for the delay getting the LVFS version out. In the future I will publish EFI shell updates for new updates moving forward.
Thanks! I saw this post just right after I updated BIOS 
. My laptop is in Linux with secure boot on. The only way worked for me is to replace SSD and install windows, update BIOS then put back Linux SSD back.
@Kieran_Levin how long should it take with the EFI image? My laptop has been sitting on the framework logo after a single reboot for over 20 minutes now.
Thanks.
Edit: I gave up and pressed ctrl+alt+delete. The system reset and says “Error: Invalid firmware image!! Please press any key to reset system….”
I used the EFI update method and it worked just fine. I did note that my BIOS settings got wiped out, not sure if that was expected behavior. However, I did not have any issues at all with grub and I booted back into Ubuntu just fine after re-enabling secure boot in the BIOS.
I’m so stoked that battery charging limit has been added! As others have noted, I’d prefer if it was something that could be configured in the OS, but a BIOS setting is absolutely good enough, as I will very rarely ever need to charge beyond 80%. I hope this makes my Framework battery last a lot longer than batteries on my other laptops.
@drs An overview for those unsure of how to install the beta when on Linux (using Hiren Win10 USB Live Boot):
…
OK, this worked. I can’t say why it worked when a Windows To Go stick didn’t, but it did. I ended up having to use Rufus to write the USB stick because ISO2USB would immediately fail after attempting to format the drive (looked like an odd race condition or something).
Thanks!
@Kieran_Levin Thank you for the EFI based updater. I hope to give it a shot this weekend (after our crazy holiday rush at work).
The EFI based updater messed up my boot settings. I had 2 EFI boot images (Ubuntu and Debian), and the Debian image was what I usually used. After installing the BIOS update, only the Ubuntu image was accessible.
The EFI updater worked for me; glad to not have needed to use WTG or something.
I’m finding that the power light seems to sometimes flash orange too, but I haven’t set the limit at all (so it’s still at 100). Replugging the power cable brings it back to being white, but a few hours later, it’s back to flashing again, so I’m not sure what the deal is.
Succesfully updated using the EFI on USB method. Thanks @Kieran_Levin for getting that out there for us linux users!
However, I am seeing the same issue as others regarding boot options disappearing. I had rEFInd set up on a 500M boot partition on /dev/nvme0n1p1 . Before, in 3.06, all of the possible boot options from /boot/efi/EFI were listed in the BIOS boot order menu. After update to 3.07, only my Fedora install on /dev/nvme0n1p2 showed up in that menu (none from p1 or p4 partitions), and p2 is the one the BIOS would automatically boot to. Secure boot was off before, during, and after the BIOS update and the resulting loss of boot options. Also, I did not notice any missing files or directories from my boot partition.
Reinstalling rEFInd did put the rEFInd boot manager back into the BIOS boot list, and did get me back to proper dual boot functionality. However, I am still at a loss to explain how / why the BIOS update would mess with already installed EFI boot options, unless this was a new regression/flaw in 3.07 itself?!? Does 3.07 not scan /boot/efi/EFI, but only /boot/efi ?
I am happy to report Batch 2 laptop with Alpha drivers for Windows 11 working well. Device Encryption is enable and I’m also grateful. I do have a question on graphic driver from Framework. Is it a customized driver or plain jane from Intel? I’m hoping to upgrade is 97% lifecycle battery, and buy ethernet card. Merry Happy Holiday’s to all.
I was able to update using the provided EFI Shell update. However, I experienced the issue noted above “losing” my boot entry/device for Debian.
With Secure Boot disabled I was able to use the EFI Shell in rEFInd and added the necessary boot entry using the bcfg command.