| ▲ | anthonj 6 hours ago |
| I really don't understand how in 2025 a competent company can't implement a trival A/B flash update. Do they depend on some obscure contractor for the firmware and have no power here? |
|
| ▲ | benjojo12 5 hours ago | parent | next [-] |
| As with many things, "It's complicated" but effectively, yes Such system firmware is generally provided by AMI / Insyde / Phoenix and similar. There are a few vendors who decide to go their own way (notably google using a fork of Coreboot for their chromebooks), but it's generally list of vendors that you can count on a single hand. If it means anything I'm pretty sure AMI provides A/B updates on most products i've used with their stuff. |
| |
| ▲ | Gormo 5 hours ago | parent [-] | | But that's always been the case. Phoenix and AMI have been the dominant BIOS providers for over 30 years. Both have always provided modular tookits for OEMs to customize their own ROM images, write their own ACPI tables, etc. UEFI gives even more control to the OEMs. If Framework isn't doing that properly, that's on them. | | |
| ▲ | mananaysiempre 5 hours ago | parent [-] | | It appears that Framework contracted out the development of their (Insyde-based) firmware to somebody who, to put it mildly, does not treat them as a priority. Either way, Framework’s firmware is really bad, and that’s entirely on Framework; you can look around on the forums for the horror stories in the (open) EC code around power delivery for instance. As another example of a vendor low-key screwing Framework in a way that I think it’s entirely appropriate to blame Framework themselves for, the first couple 13-inch models could charge off 5V chargers. The newer ones still have the necessary hardware, but whoever they get their power circuitry from cut that bit from the firmware on a newer chip version, and Framework obediently went “welp, guess we don’t have that feature anymore”. | | |
| ▲ | craftkiller 18 minutes ago | parent | next [-] | | In addition to no longer charging off 5V chargers (their first laptop could literally charge off a USB type A with no USB-PD), on the AMD 7040 I've got ~10% chance every time I plug it in to my dock that it will simply not start charging. Everything else will connect (display, USB) but power won't flow. Resolving that is as simple as unplugging and replugging in my laptop but if I don't notice until I'm in a video conference then it is a problem because my webcam, microphone, and headset are also going over that cable. Oh how I miss the OG 11th gen framework charging. | |
| ▲ | anthonj 5 hours ago | parent | prev [-] | | I heard a lot of talk about porting to coreboot (they even sent some motherboard to some coreboot developers I think).
Not sure what is stalling there, but sounds like a priority. For the EC, I feel like a team of a single developer could arrange something there? |
|
|
|
|
| ▲ | allenbina 5 hours ago | parent | prev [-] |
| I know some higher end gaming motherboards that were targeted towards the overclocking community had two bios chips for exactly this purpose and switching between them was trivial from what I remember. If you overclocked too far, you wouldn't brick your system. It seemed like overkill to me. I'm guessing this is less common than it's worth to fix in software, but then at least continue to give support for the issue. |
| |
| ▲ | drdexebtjl 5 hours ago | parent [-] | | If you overclocked too far, you could remove the CMOS battery or hold the CLR_CMOS button that these high-end boards probably had. Two BIOS chips was supposed to protect you from bad BIOS updates or a bad BIOS mod, just like the scenario from TFA. | | |
| ▲ | quantum5 5 hours ago | parent | next [-] | | Original author here, and I agree. When overclocking, the most important feature is probably resetting the CMOS with one easy to reach button. I was testing ECC previously in https://qt.ax/ecc and was trying to overclock the RAM to induce faults to confirm ECC was fixing them. Since I was using a cheaper board, I had to use keys to short the CLR_CMOS header and that got old really quick... I didn't ultimately succeed in creating a barely stable overclock that generated a ton of ECC errors, but that was a very awful experience. Having some sort of BIOS recovery is definitely the baseline I'd expect these days, and having two BIOS chips so you can just keep using the device as if nothing had happened is the best solution. | |
| ▲ | jorvi 4 hours ago | parent | prev [-] | | Possible they're thinking of certain OC editions of GPUs. Some of them have 2 BIOSes you can switch between with a little slider. Some even 3. | | |
| ▲ | drdexebtjl 4 hours ago | parent [-] | | Isn’t that just a gimmick? I was under the impression that GPU overclocking,
overvoltage and fan curve settings were not persistent across reboots. | | |
| ▲ | quantum5 3 hours ago | parent [-] | | It's not a gimmick when the serious overclocking people do custom VBIOSes. Similarly for miners. That's when you need the recovery switch if things go wrong. | | |
| ▲ | drdexebtjl 3 hours ago | parent [-] | | TIL about custom VBIOSes. Why don’t the OEMs of GPUs aimed at OCing just ship with a BIOS that exposes more tweaks through software though… |
|
|
|
|
|