Better BIOS

It’s great. I haven’t had any … noticeable issues.

Seems to be a bit weird of an interaction with the entire “standalone mode”. The first time(s) I turn the thing on, it never did the “press power button to bypass” despite me not having any input module or even the cover. But the last two times it did.

Anyhow the initial setup is now more than complete, I don’t think I will call that an issue.

Anyhow. Feature Requests. Somewhat organized by importance.

I don’t like how the TDP of my system is jumping up and down. I can be pulling a consistent 30W doing Cinebench, but then I go do something else (3D modeling), and the thing go to 42W.

Can we have TDP settings exposed in BIOS? Since the AC power mode just seem to be “send it until 100 degrees”, I don’t see why reliability is a tremendous concern, should a user choose to go full-send.

Then are some of the "nice to have"s. Right now we have to restart once we apply any setting in the sub-menu. Can we have it so we can change settings in multiple menus, and then save and reset? No other BIOS I have ever used behave like this. It’s not … a tremendously big problem.

Then is … mouse support? I don’t care. But it would be nice. Or just go back to text based. It’s odd having like, an entire UI, then don’t implement mouse.

Battery charge limit is great. The scheduled charge thing on Dells is a bit crazy, but it’s also kind of cool. Also options for fast/slow charging.

And uh … a self-test. We have blink code, it’s nice. But Dell and Lenovo both have a hardware diagnosis built into BIOS. Though I have never seen them actually … hmm.
They can catch more advanced stuff, like GPU not working.

Unobtrusive Mode. Fn+F7 to turn off all light emission, and all sound. I don’t know how that would be, since Framework don’t have a built-in keyboard (topologically; it’s all USB).

Oh oh and the “full screen logo” thing. It’s hilarious.


I’ve been finding media to try to graphically illustrate what I meant instead of producing walls of text, but apparently publication on this is rather scarce.

There are several third-party software which can you can use to limit the TDP on Windows such as x86 tuning utility. I think it’s better to have that setting on the OS as you can easily change it without needing to rebooting to get into the BIOS.

I do like the idea of TDP limits or modifiers within the BIOS but not the dynamic adjustment which is best in OS. For instance when 240 watt PD adapters become more available the FW16 platform might be able to support the 7900 xt mobile dGPU assuming you can control the platform TDP to 50 watt (GPU would take up to 190 watts). Yes dynamic allocations would be best (see Steam Deck) in OS [since you can use the workload itself to adjust TDP limits], but it would be nice to expose reasonable platform limits/splits as this is often the first step to getting a proper dynamic setup going which requires tight integration between ECs, platform, PD, CPU, component, etc controllers. (luckily for AMD platform a lot of this work is getting into Linux and Windows thanks to Valve). This might be an interesting tool for future development of the module bay since you could expose the usage of said module bay components. (say a 5G LTE module, FPGA dev module, nested dev platforms, etc)

The main diagnostics that would be useful is: keyboard tray (already kind of implemented), modules, USB-C related stuff.
Being able to get the PD EC information displayed and attached device information would be interesting. Having information about attached modules, components, PD IC readouts, USB-C negotiation information, etc might be interested.
Example: You attach a thunderbolt Dock…

  1. What PD profiles are detected and available…
  2. connected device information (e.g. 2 DP over USB-C, 1 USB 3 hub, Thunderbolt 3 4X lane available, whitelisted in PEs (many bios have settings that can whitelist devices or block in the firmware/pre environment before you get to the main OS and would be useful in troubleshooting)
  3. MISC info (that I am not thinking of atm)

This could make troubleshooting of dead/damaged modules and OS issues by allowing you to see and diagnose directly with the embedded controllers, retimers, etc, etc. The CPU/Memory/Disk/etc tests are often better with dedicated PE/linux/etc diagnostic suites. Its really hard for PE/boot diag style environment to do PD, thermal, etc diagnostics since it cant really tell whats an issue with half dozen to dozen controllers (thunderbolt itself often has 4+ modules alone) built into modern laptops and the underlying OS/environment.

I had thought about this.

I own a GPD Win Max. Based on totally different principles, they are trying to, basically, make the smallest laptop possible.

I remember asking for a “unlocked” bios in their discord, because I don’t want hyperthreading and I don’t want TPM. So they sent me the file.

But before we get to that. TDP is a adjustable value, sane as PL1, 2, and on different modes.

So, the unlocked BIOS. It’s quite literally “unlocked”. Everything visible. From clock ratio and voltage (on i5-1135G7) to USB operation mode. The saying is “so long as you don’t blow up the device through bad settings, it’s on us”.

I had photos, but I don’t know where I put them.


But that’s GPD, and this is here. Well, I think Framework is more interested in making computers that work, rather than being mere play things. But then, why go the step, and have a literal header so people can flash EC firmware?

Megatrends and Insyde differences aside, I will say this is a better BIOS. It has battery percentages, TPM things (quite a lot of that actually), and “boot from file” is wild. No EFI shell, though.

1 Like