My 12th gen had the issue where all cores would throttle down to 400MHz. Ultimately, I had to open the laptop and reapply the thermal paste on the cpu. Not ideal, but my CPU hasn’t been locked at 400 MHz since then.
Tried it, twice, on two different boards, didn’t help. (I’ve been having an intermittent back and forth with Framework support for quite a long time now… believe me when I say we’ve tried a lot of things.)
May I ask what thermal paste brand/model you used? Maybe that’s significant…
Edit: er, after posting I realize this is super OT for this thread. Sorry, y’all. @BigBoat, feel free to DM me or reply over on my thread about this.
2 Likes
My partner uses my old 12th gen i5 board. Just installed the the 3.08 update via the tool on Framework’s site. Completed without a hitch, and the system reports the bios as now being 3.08, it had come from the 3.05 beta previously.
EDIT: To clarify, my partner is running Windows 11.
1 Like
Download the windows msi file or the EFI update
the file is still up there on the server:
If the msi file complains about not being run on a Framework laptop:
I am sorry but I am going to join the chorus of people here and say that I’m deeply saddened by this state of affairs.
I’m one of the early adopters of the 3.06 beta BIOS update. I installed it, from Linux, and it worked, it was great. I was expecting this to come out of beta months ago. Now there’s a 3.08b available, and not only is it not available on LVFS/Linux, even the EFI option has been pulled.
Now, it seems the framework team has moved on to other things, and I’m left holding the bag, with a basically backdoored BIOS.
This is, quite plainly, unacceptable. I’ve been recommending Framework left and right, thinking you folks had our backs, but now it seems we (the free software community) are left holding the bag and will have to reverse engineer your stuff to get updates delivered properly.
For me, this clearly shows that Linux is a second-class citizen for Framework. This would never happen to the Windows or Chrome sides of the business. Can you imagine Framework coming out “oh yeah, poor windows users sorry you’ll have to boot a Linux OS to install that update?” Nevermind than that would actually be possible for windows users: Live linux distributions are actually a thing, and quite popular tools even for windows users to recover their mess.
In fact, why isn’t this the way updates are delivered? Linux is easy to embed in a thumb drive to deliver updates…
Anyways, having some word about a timeline on Linux support for the BIOS from the framework team would be much appreciated here. Maybe @Matt_Hartley knows?
4 Likes
This is the MSI installer only being “updated”. supposedly the firmware itself did not.
the EFI updater is still on the server. I can only agree on the bios should become release at some point. (and when to expect this “stable” efi variant, altho the efi version worked fine for me)
@Ray519 At this point with 3.08b released on the update page, the only major tripping point (aside from the lack of information during updates, no detailed info for aborted updates, etc.) is the ReTimer updates, correct? And that can be resolved by disconnecting the battery in BIOS for a few minutes and powering back on, right? So at this time we should be ok to run the update, assuming we’re ok with potentially needing to disconnect the battery in BIOS? Or was there something bad about the GOP driver that’s still worth holding off for?
From a stability point of view of the update once installed, I am aware of nothing. I concluded as much in February when I installed the beta on my mothers Framework assuming that Framework would be dragging their feet again (and after skipping the 3.06 beta, because that had issues with the USB legacy adapters).
The GOP thing and many other things I have commented since April are just about the way they describe or not describe things (like listing 2 different versions as same in the release notes, and in 3 months and for a release not having noticed this contradiction. So nothing directly about the quality of the update itself.
My main concern has long more been the way it has been handled. How if Framework had been getting private reports or I would have missed a user reporting another issue of the update here, they might have ignored them just the same as the other reports here. And what that says about FWs processes and ability to deliver updates and us being able to trust their PR-driven “opinion” that the update is ready. Especially if they intend to just ramp up speed without showing that they are making vast changes to prevent releasing the WRONG version ever again (and not noticing for months).
I think 3.08 itself, is probably of the same or higher quality as the factory version. And there is no solid testing, so there are probably still rare issues in there. But I don’t think the chance of that is higher than such issues being in the factory firmware from the same people or you hitting some of the known issues that are fixed with 3.08. And I do not see the quality and reliableness of the updates improving in the short term, so think 3.08 is still the better way to go.
3 Likes
Excellent, I appreciate the info! It’s funny, across here, Reddit, and the Ars Technica article comments, you’ve been the one keeping level-headed and providing good, solid info. I really appreciate that.
1 Like
I try to keep the anger down when writing things and remain fair and also acknowledge positive developments etc. In the hopes of getting Framework to change their stance and rethink things. And getting me the products I would like to have. Although I have been getting a bit more snarky over time.
Maybe we get lucky and the same or other authors actually pick up on the 3.08b release situation and how FW is again trying to keep that quiet.
Maybe that gets us even more transparency and hope for the future.
4 Likes
However, now with Linux, entering “deep” suspend (in the /sys/power/mem_sleep sense) consistently soft bricks the device. Once in this state, a mainboard reset is required.
Funny because I updated the bios last week to 3.06beta, and the issue you report is exactly what lead me to this thread. The poweroff is not working either.
I’ll contact support. My 2 rear USB ports are dead (except for charging) and this suspend issue are a blocker for me.
1 Like
OK, I tried the update to 3.08, and it completely broke my motherboard. The 4 usb ports are not visible even in the BIOS (boot selector) anymore. Contacting support.
3 Likes
Quick update - 3.08b update completed, Retimer issue doesn’t appear to have hit as all USB ports appear to be working.
1 Like
Sorry to stumble upon the flowers on the carpet, as we say in french, but did you really mean the 12th gen 3.19 update? I thought that was 3.08?
Also, you seem to be saying we can test the update now, is there an actual way to do the 3.08 upgrade now on Linux? (And no, install windows is not a way.)
Thanks.
2 Likes
Also, it seems relevant to mention there was a whole blog post about this very topic on the website now:
I found it’s pretty thin on actual contents. The only new thing in there is:
for Linux we’re developing a new updater to handle the specific firmware regions involved.
which, quite frankly, is actually pretty disappointing. I did the 3.06b update on Debian Linux through LVFS and it Just Worked. I understand this update is trickier, but I find it regrettable that we’re building a whole new way to update firmware instead of leveraging what the community has been working really hard on for years at this point, and that has been adopted by many large, much more commercial/proprietary vendors than Framework, including Dell, HP, Lenovo…
Really, I would love to hear more about what the actual problem is with LVFS and whether or not the LVFS people have to say about this… This really sounds an awful lot like what Purism and System76 ended up with, which is that they’ve basically given up on LVFS. I didn’t buy it from them, and I don’t buy it from Framework either.
Surely I must be missing something.
4 Likes
not to go far off topic here, but yeah, americans do love it, and seem to have rarely heard it. It’s pretty colloquial (in french!) where I’m from, but maybe not in France…
6 Likes
Same here. @pixelforest don’t reinvent the wheel, or have a case of “not designed here” let’s design something that in the long term is just one more thing we will support until we have to drop it…mir, upstart, unity same concept different projects.
2 Likes
Having unpacked both installers and run checksums on the actual firmware files: the firmware capsules / images themselves are identical. The only other thing that changed are the .cat files, which are just signatures etc. for Windows. Which is probably caused by how they automate packing the installer, that those are regenerated when building a new one.
I am curious: what driver could impact your Windows firmware updater? Only the ME Update runs from inside Windows, no?
Also, your driver bundles do not really have a name, only the date published on the release website (that we cannot see in Windows after the fact), because it is just a bundle of various other installers plus remapping the fn+F12 key to a webpage.
To my knowledge, there also has only ever been one driver bundle for 12th gen.
So the answer to this question can only by “i don’t know” or “the only driver bundle you ever had”. If particular drivers impact the parts of the update that run in Windows wouldn’t it be better to ask for those versions? Because we can see for example the currently installed Intel chipset drivers version easily. And other drivers may very well have been updated above what is in your driver bundle (iGPU, WiFi, BT).
Now this is a really curious point. The EFI installer you have released includes the ME firmware file (binarily identical to the one that is actually installed in the Windows installer, 10MiB) and the ME updater.
Are you saying you packed both of those in there, but it is never actually executed? Then, saying that would have probably been a good explanation for why you pulled that updater down again.
On the other hand, FWUpdLcl.efi looks to be a EFI commandline program, just like the other updaters that are run from your EFI Shell script. That would not look to be hard to run in an EFI shell, that you are already using, just like how it is run separately and before the other firmware updates are installed after the reboot with the Windows installer.
Or are there deeper problems, and the official Intel installer you packed in there would fail to run, if it ever were executed?
What about the capsule update process you have been using from Windows and Linux/LVFS. Is that sth. Framework is planning on improving to the point where Framework can simply also ship ME updates or the special logic for standalone boards through the capsules and the OS agnostic updater that applies those updates?
Or will there only ever be a Windows and a standalone, bootable update process and no more Linux/LVFS updates for everything that has ME firmware? Do you have control over the Capsule updater and could enhance that to also update ME firmware (similar to how other manufacturers update everything through that process, precisely because it is OS agnostic)?
5 Likes