Framework Laptops are now Thunderbolt 4 certified

Totally is! No worries :blush:

I’ve said this in another post but FW isn’t known to release any details until it’s literally already out. They’re pretty secretive about stuff. I don’t really like that approach but I totally get why! :orange_heart:

Hope this helps~

2 Likes

Take heart, we have avx512 unlike those unfortunate 12th genners

3 Likes

Intel fused off avx512 in alder lake so disabling the E cores is no longer a work-around

5 Likes

Since battery time / power consumption changes were mentioned regarding the 12th gen firmware, are 11th gen users going to get the firmware update that improves the battery drain situation during sleep mode? (Not hibernate, i.e for me, I’m on FreeBSD and we don’t have hibernation so this wouldn’t be a workaround). I remember earlier in the year there was activity regarding this issue but the 3.10 update didn’t include those changes since there was still some development work left for those updates.

As the announcement is older than 2 weeks now, I’m just wondering when we will get the update?
I’m not asking for a specific ETA, I’m just interested if we may get it this year or not? (this year only lasts a few more weeks ^^)

So no stress from my side, this is just an informational question.

6 Likes

@fearedbliss, the battery drain issue, as well as other battery fixes, were mentioned in the update notes for the 3.09 release.

Here are some issues that were supposed to be fixed:

  1. Fix bios menu options for battery charge limit and CPU flex ratio setting cannot change value using F5/F6.
  2. Fix battery cycle count is not valid in battery info reported to OS.
  3. Reduce main battery drain in off state by turning off analog reference in charger IC.

Were these fixes not actually fully implemented?

I am about to install Ubuntu 22.04 on my new 12th gen Framework, I hope the battery issue that plagued some early reviews is fixed for everyone.

Back to the topic on hand - congratulations Framework team on getting Thunderbolt 4 certified!

1 Like

@Kris_Keillor I don’t believe so. I did post this on August 12 asking a similar question:

Hi Everyone, We are still working through a few issues with the various installers for this update to make sure that everyone gets a good update experience across Windows/Linux and other OS’s.
This update requires updating a few additional components of the system that we have not had to update before, and have created our own updater/installer packages to support this.

21 Likes

So according to this post, this Thunderbolt certification includes a firmware update:

However, while there’s lots of talk in this thread about firmware and LVFS, there’s no official thread for BIOS version 3.05 on the site that I can see. The knowledgebase also says “The Factory-Installed BIOS (3.04) is the latest version”. Can we get a thread, or at least confirmation here, of the new BIOS - as welll as it being added to the knowledge base?

I am new to LVFS and the discrepancies in this information are making it harder for me to learn. Thank you Framework team!

On that note, if I have the fwupdmgr command I therefore have the fwupd daemon i.e. LVFS, right?

Yes fwupdmgr and fwupd use LVFS. fwupdmgr is also capable of installing local files if available.

1 Like

If you need them, I am sure many people on this forum would be more than happy to be beta-testers for this, I certainly would be happy to test on Debian testing (AKA Ubuntu, if you will).

No official because it hasn’t been officially released, although apparently the newer 12th gen Laptops are being shipped with 3.05 (like my own 3rd Batch). So just another strange behavior from Framework.

1 Like

I find this statement a little odd, I think as mentioned in :

updates to the latops that are already in the hands of users are delayed because there does not exist a reliable update mechanism across operating systems yet. As such upgrades can potentially brick components, Framework must ensure reliability and ease-of-use of the upgrade tools. Otherwise the resulting support tickets, cost for potential replacements parts will just turn out to be an economic nightmare for them.

I think especially because they listen to the community and do not only provide windows based update software, we should be a little patient here.

At the factory this is a different story, you have access to each individual component potentially to direct interfaces and if something goes wrong you don’t have to pay for shipping costs or support agents. Also your users don’t have any downtime because their device is not in a functioning state

1 Like

Hi all,

Why not do the upgrade process the old school way: with a bootable USB image ?
This should be easier to control, free of any interactions and OS agnostic.

5 Likes

Hey Framework team,

Is there any chance that the new firmware helps with BitLocker issues?

I use a TB4 dock and also a TB3 eGPU and booting up with one of these hooked up makes the computer thinks I made signifiant changes to the computer and thus triggers BitLocker safety mode.

If the new firmware helps about this that would be even greater news.

Thanks in advance!

2 Likes

It’s pretty unlikely.

TL;DR: No, it is a security feature that protects you from rootkits. Fortunately, you can turn it off yourself.

BitLocker binds its encryption key to some platform registers (specifically, TPM "PCR"s) that are used to track what code is running during startup. Since an external graphics card quite likely has a UEFI driver–or an Option ROM–that runs during boot, adding and removing one materially changes the value of that register.

It’s this same register that would signal whether your machine was compromised due to the installation of a malicious bootloader, firmware image or PCIe device.

If Framework Computer were to make changes to the configuration of this register to resolve this issue, it would simultaneously wipe out BitLocker’s ability to detect things like firmware rootkits.

Fortunately, you can change which PCRs BitLocker cares about if you’re adding and removing Thunderbolt devices often enough that this becomes a problem.

7 Likes

Thanks for the answers!

Let me share what information I gathered so far about this. Not to say you’re wrong in any way!

First, I have read that the behavior depends on the BIOS implementation. Basically, whether the PCIe devices over TB are connected before or after the BitLocker verification. I read that apparently some manufacturers made it that way, plugging the PCIe devices after the BitLocker verification and thus enabling their laptop to work flawlessly with BitLocker, TB dock connected or not at boot.

Second, I never got to successfully change the PCRs BitLocker cares about after following many tutorial. I ended up finding that this requires the “pro” version of Windows, which I did not pay for. Maybe I should upgrade… In any case this is worth noting for other people, I mean I literally spent a few hours trying many things before noticing this “little” detail.

3 Likes

Ah! I was definitely not aware of those things. Thanks :slight_smile:

1 Like

Can we get a beta release already? A bootable USB option would be good enough.

2 Likes

The change they would need to make is, to add a BIOS option to “disable booting Boot-ROMS behind USB4”, as other TB/USB4 hosts have. Then the eGPU does not boot and TPM is not affected.
GPU Boot-ROMs are only needed for BIOS output through that GPU. The OS does not need it, as it loads its own drivers. It just would mean, that the OS cannot use the eGPU during early boot and it will only start working at the login screen. For a notebook with builtin display, not a huge problem. And if you are using the FW standalone you are not likely to unplug the eGPU (and can leave the option on / turn it back on). I think this would solve most usecases and results in the same behavior as just plugging in the eGPU after the BIOS finishes booting, just automatic, with less hassle.

Fyi, booting NVMe drives behind USB4 will not be affected, as they do not have/need Boot-ROMs anyway. That would be another option of “disable booting any device behind USB4”, that would just be against drive-by attacks were some foreign OS is booted to manipulate / take over the device or extract data. Something that should be much less relevant with TPM-based security like bitlocker and secure firmware.

3 Likes