@junaruga the current UEFI BIOS is a proprietary product made by Insyde Software.
The embedded controller firmware (controls stuff like battery management, power button behavior, etc) is based on Chromium OS EC.
Removing the G-Sensor option in the BIOS would have been at the direction of Framework, presumably to maintain consistency between different production batches since they’re removing the accelerometer from the motherboard due to supply issues.
Anyway to use the G-sensor if the laptop has it? Can’t the BIOS determine if it’s available and give those with one the option to turn it on?
I’m thinking that Framework decided to not include a G-sensor anymore so the majority of devices (that means the devices built in the upcoming years) will not have a G-sensor so they think they don’t need to provide any code to get it to work.
Which make sense, because there is little way a G-sensor can provide the system with any actual benefits, since you can’t fit anything physically fragile (like a hard disk) in it.
I’m curious about what it means for people who may have wanted to explore throwing a tablet design together. That’s not for me, mind; I wanted a notebook PC and I got exactly what I asked for. But the seemingly mid-flight prototyping might sour some enthusiasts and be cause for concern for corporate interests who’d feel more secure in making changes to hardware that doesn’t resolve or fix a problem.
Think: do I buy the 1.0 version of the device, or wait for the 1.1 version? What if the 1.1 has a 0.9 feature set and is otherwise 1.0’s overall design without delivering functional bug fixes?
Should we assume when we receive a shipment that there’s no possibility of a BIOS update? I sometimes like to run a BIOS update as a first step of building out an OS.
Beta BIOS updates have been released in this forum! Public Beta Test: 11th Gen BIOS v3.06 + Driver Bundle 2021_10_29
Also, I recently received my batch 4 unit and it had the latest BIOS when it arrived (3.06).
Should I be able to view SSD information from BIOS? I can’t and I’m wondering if it’s related to the problem of not being able to connect to SSD generally.
(I checked and it’s definitely physically snug on the insides, thanks!)
Yes. Last time someone (here) didn’t see his SSD on the BIOS the SSD was faulty and replacing it fixed the problem.
Got my Framework a little over a week ago. I’ve been babying the battery ever since, only letting it charge until it’s full then shutting it down and/or unplugging it (to prevent battery drain, and overcharging) Today Arch i3status told me my battery stopped charging around 94% capacity, whereas last week it would get to 100% and stop. Would really like to get battery health charging figured out before I have to buy another battery for this system.
there are certain things the charging regulators will do to avoid putting unnecessary strains on the battery
For example, if you unplug the system while the battery is at 100% and use it until it’s, say, 95%, the system might not charge it at all because it think 5% is not worth charging it all the way up
For example my Dell computer. In “custom” mode there are two thresholds you can set: the charging begin percentage, and charging stop percentage.
So if your battery drops below the first value (charging begin), it will charge until it hit the charging stop percentage, then it will stop. But if it didn’t hit the charging begin mark, then it simply won’t charge.
So I used to set it up like this: charging begin at 50% (that’s as low as it allow you to), and charigng stop at 75%. Between 50% and 75% (say, 60%), the battery neither charge nor discharge. It will be “idle”.
There are some different bios that show different values (e.g. actual wattage hour(in mAh), desired wattage hour (in mAh), current flow (in mA), voltage(in mV) and temperature as measured by the battery pack’s onboard regulator). It won’t give you the percentage, however.
But, as mentioned earlier, Framework don’t have in-house BIOS like other big companies do (e.g., apple, dell, lenovo, hp, toshiba, fujitsu), which generally require a more dynamic BIOS (instead of “america-megatrend copy blue-and-grey interface”) and other things, which might mean quite a expensive budget, which for something unimportant (e.g. compared to Spectre and Meltdown mitigations), it’s not entirely surprising to see them being reluctant.
Although, I hope it gets added to their to-do list.
I believe you can do them (as modern devices are surprisingly redundant and incredibly complicated). But they might just thought (nah. we aren’t going to spend 20 hours digging through the battery controller datasheet and find out a way to put it in a UI), especially since Framework, unlike Dell(or hp, or Fujitsu, or Toshiba), don’t actually make their own BIOS in-house (rather asking someone else to do it for them)
In a default it might be something like 90% and 100% respectively.
Xavier_Jiang
Framework don’t have in-house BIOS […] it’s not entirely surprising to see them being reluctant.
No, they don’t, yet. They have already mentioned that they will work on a BIOS in the future, and are already providing BIOS patches for current systems. They are merely a startup now, and clearly didn’t have enough initial capital to order enough systems for each batch at the start, let alone writing a custom BIOS. They have grown immensely over just a few months, they haven’t even been around for 6 months yet and have already sold thousands of systems. I’m confident they will eventually get around to writing a custom BIOS, and I seriously doubt this is the final revision to the hardware as-is.
See this post about the most recent Framework BIOS update with new features and fixes already.
There is clearly already work being put into the BIOS, they just needed to improve their team, which they have been working on through the new hiring process. Although, looking at your profile, I can’t imagine you’re a stranger to any of this news. So, I don’t see how Framework is “reluctant” to add this new feature, as they appear to be doing whatever the community wants/needs first, and considering there was a feature addition to change the LED brightness on the power button in the last BIOS revision, something tells me battery charge thresholds aren’t that far out.
As a layman, I want to see a good step by step manual for updating the BIOS. I also want to wait until the new BIOS update is official, not beta and more or less a bullet proof process. I have 03.0 on my DIY Framework and it needs updating, if not right this second.
Nick
I believe the Bios software should be open sourced so the community can work on programming in things that can be used by everyone, even if it’s not used as much.
The hardware is already modular so not everyone will have the same hardware configurations. Having a BIOS that’s configured BY the user and the community would be more fitting for this brand of laptops.
It is unlikely that Framework will be able to open-source InsydeH2O’s UEFI (which is the boot firmware they’ve licensed and customized); however, you can follow this thread for more information about open-source¹ boot firmware.
¹ Mostly–apart from some Intel binary blobs/the Intel Firmware Support Package
That’s ok. It was more of a suggestion.
BIOS/UEFI is now so complicated that some of us need a list of items that likely need attention.
I installed Ubuntu Studio 21.04 (based on Kubuntu) on a Batch 5 DIY from a USB stick. Installation failed until I disabled “Enforce Secure Boot.” That was a wild lucky guess on my part, and I am not certain that it was the right step. I have left “Enforce Secure Boot” disabled, and I am not sure whether that is correct, either. Based on the time sequence, I’m guessing that Secure Boot prevented the installation from writing some part of the boot code, rather than preventing the appropriate boot code from activating for boot. But that’s more wild guessing.
Nope. Secure Boot only allows “trusted code” to run when booting the system. Trusted by whom? Well, it verifies trust by looking to see who signed whatever code is running and whether that key is trusted by the UEFI. By default, most UEFI systems come with Microsoft’s keys built-in, which means that unless people go out of their way to add custom keys, bootloaders and other such things will need to be signed by Microsoft’s key in order to boot on a Secure Boot-enabled system.
In general, people have fewer issues on Linux systems with Secure Boot disabled.
Ubuntu is signed using Microsoft’s keys
Fedora is as well I think and one other I believe
Perhaps Ubuntu Studio is not however idk
Yup, so is Debian. It’s why I didn’t even have to think about Secure Boot until I realized it disables hibernation (everything “Just Worked”).