I added more info about entering and navigating the BIOS, table of contents, and default/available values for almost every item.
@nrp is the BIOS version considered GFW30.03.02 or rev 5.0? And can this be made a wiki?
I added more info about entering and navigating the BIOS, table of contents, and default/available values for almost every item.
@nrp is the BIOS version considered GFW30.03.02 or rev 5.0? And can this be made a wiki?
I think so too. I’ve noticed Windows reports the BIOS version as 3.02 and Linux as 03.02.
Yes, that is correct. 3.02 is our versioning. GFW30 is actually what our manufacturing partner calls the product. We’re not sure what happened to GFWs 1 through 29.
@nrp , thoughts on making the battery disconnect a latched setting? Seems to have some interest from the above replies.
It should be technically possible, but we have a long list of stability/diagnostic updates we need to make on firmware before we can get into feature additions.
Great! better to be on the backlog than nowhere
Is there runit equivalent command for that systemd command to get into bios?
PS: I hate to have to reboot and repeatedly press, sometimes if missed you have wasted like 1-2 mins xd (don’t take PS seriously btw, funky language use though, but its quite annoying).
I did a fair bit of searching and didn’t come up with a good alternative.
What kills laptop batteries fast is having it sit at 100% SoC (~4.2v per cell) for long periods of time, and is exacerbated by higher temperatures (typical inside a laptop). “Disconnecting” a battery will do nothing unless it’s at a lower SoC. I vote for a selectable charge threshold. If you set your SoC to 70-80% you can massively extend the life of the battery. I’ve run 80% on my current Lenovo X1 (6th) and the battery has only experienced a few percent degradation.
Hmm, I wrote a script myself.
#!/bin/bash
# /usr/local/bin/reboot-firmware
if [[ $EUID -ne 0 ]]; then
>&2 echo "This script must be run as root"
exit 1
fi
OS_INDICATION_SUPPORTED_FILE='/sys/firmware/efi/efivars/OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c'
OS_INDICATION_FILE='/sys/firmware/efi/efivars/OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c'
BUFFER_ATTR=7 # EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS
[ -f $OS_INDICATION_SUPPORTED_FILE ] && [ "$(( $(cat $OS_INDICATION_SUPPORTED_FILE | od -An -t u8 --read-bytes=8 --skip-bytes=4) & 1))" -eq 1 ] || {
>&2 echo "OsIndications is not supported"
exit 1
}
DATA="$([ -f $OS_INDICATION_FILE ] && cat $OS_INDICATION_FILE | od -An -t u8 --read-bytes=8 --skip-bytes=4 || echo '0')"
DATA=$(( $DATA | 1 )) # EFI_OS_INDICATIONS_BOOT_TO_FW_UI
BUFFER="$(printf '%08x' $BUFFER_ATTR | sed -r -e 's/(..)(..)(..)(..)/\\x\4\\x\3\\x\2\\x\1/')$(printf '%016x' $DATA | sed -r -e 's/(..)(..)(..)(..)(..)(..)(..)(..)/\\x\8\\x\7\\x\6\\x\5\\x\4\\x\3\\x\2\\x\1/')"
printf "$BUFFER" > $OS_INDICATION_FILE
reboot
RUnit does actually do its own job, to be an init system but not a exit system . It does follow the unix philosophy.
What kills laptop batteries fast is having it sit at 100% SoC (~4.2v per cell) for long periods of time, and is exacerbated by higher temperatures (typical inside a laptop). “Disconnecting” a battery will do nothing unless it’s at a lower SoC. I vote for a selectable charge threshold. If you set your SoC to 70-80% you can massively extend the life of the battery. I’ve run 80% on my current Lenovo X1 (6th) and the battery has only experienced a few percent degradation.
You can set thresholds using tlp which forwards the setting to EC of the laptop Battery Charge Thresholds — TLP 1.3.1 documentation (linrunner.de)
START_CHARGE_THRESH_BAT0=75
STOP_CHARGE_THRESH_BAT0=80
@Animesh_Sahu Do you have those thresholds working on Framework? The docs seem to say they only work on certain Lenovos but maybe they are out of date?
@Animesh_Sahu Do you have those thresholds working on Framework? The docs seem to say they only work on certain Lenovos but maybe they are out of date?
I did not got hands on framework till now, its neither in my country nor my parents (I’m a student) can afford it until my current laptop goes out completely, but I’m sure my next laptop is going to be 100% framework…
We have this exposed in the EC, but need to work on exposing this to the bios/user applications to make it usable.
The officials have confirmed that the EC is exposed, and I’d guess it should work without any problem on framework.
Yep, open source firmware is well aligned to our mission of building products that are better for people and the planet. Our EC firmware is based on chromium-ec, and we will be releasing source. As @Kieran_Levin noted, we’re also exploring coreboot. We’re currently focused on getting the Framework Laptop out into the world in a lower-risk path that uses an off the shelf proprietary BIOS, but we’re looking forward to replacing that with an open alternative in the future.
As pointed out, it is based on chromium-ec which was probably used in old lenovo thinkpads as well (zephyr framework appeared in 2016), even if sources might be different it would be easy to integrate as can take inspiration from old tlp sources and adjust accordingly for framework.
Add a new forum page if it does not work, implementation should be quick, unfortunately can’t test it out from my side :^(
Do you have those thresholds working on Framework?
I tried to set battery thresholds and it does not work with the defaults settings anyway.
Yeah, if we could get documentation, we could easily patch TLP for the Framework EC.
@RandomUser I’m not sure it’s exposed to the software yet. The Framework team has already alluded to the fact that adding that configuration to the BIOS is on their roadmap, until then Windows can’t do anything about charging thresholds. There is freeware that’ll alarm you when certain thresholds are met, but those are hacky and require you to unplug and replug manually anyways.
I’m not sure what it will look like when the Framework team gets around to that, whether it’ll be setting charge percentages in BIOS like I’ve seen on a recent-generation Dell laptop, or whether they’ll give a utility to be able to control charge levels through a tool like Asus and Lenovo provide.
As a work-around for another notebook, I wrote a Python script to monitor the battery charge level and turn on or off a smart plug that the charger is plugged into. It works well, but the computer must be on.
Crediting John Lombardo’s post here since he posted another quite literally hacky solution, but one that seems much more functional than the normally available utilities.
According to framework, and assuming I didn’t misread, the EC is exposed! So it should be possible to use rweverything to set the charge limit, much like controlling a fan.
Have not heard of that utility, I’ll have to try it out soon. If someone doesn’t beat me to it I’ll post what my experience was