If none of those strings changed I would say it’s likely not getting loaded. Check the file structure you put the new files in matches properly.
1 Like
My wi-fi just dropped again too, which is consistent with my perception that the new firmware isn’t running. @Loell_Framework, I know Mario is the expert on Linux on AMD, but I don’t want to keep leaning on him for support that Framework should be responsible for.
1 Like
The commands below ran without error in /lib/firmware, which shows that the new binaries are at the paths shown.
diff mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin updates/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
diff mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin updates/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
diff mediatek/WIFI_RAM_CODE_MT7961_1.bin updates/mediatek/WIFI_RAM_CODE_MT7961_1.bin
The output confirms that the new binaries are different from the old ones.
I’m on 11th gen, but I swapped out the Intel AX210 for the Mediatek 7922. I am running Arch, but it looks like the firmware that shows in my dmesg output is newer than what your output shows.
[<user>@<host> ~]$ sudo dmesg | grep mt7921e
[ 29.157948] mt7921e 0000:aa:00.0: enabling device (0000 -> 0002)
[ 29.163236] mt7921e 0000:aa:00.0: ASIC revision: 79220010
[ 29.244238] mt7921e 0000:aa:00.0: HW/SW Version: 0x8a108a10, Build Time: 20231120183400a
[ 29.259450] mt7921e 0000:aa:00.0: WM Firmware Version: ____000000, Build Time: 20231120183441
You could try backing up/renaming the existing firmware files and moving the new ones where the old ones were, then running the update-initramfs command as Mario noted. I would expect that to cause the new firmware to be loaded. In the unlikely event that you can’t at least get to a shell, you could boot from a usb and move the files back.
It’s great to have confirmation that dmsg can distinguish firmware versions.
You could try backing up/renaming the existing firmware files and moving the new ones where the old ones were […]
I’ll try this as a last resort, but I really don’t want to touch the existing firmware if I can help it, since that gives me an even greater chance of breaking my system with a typo. Does anyone know a way for me to check my system’s firmware search path? I don’t know where to look for things that could modify the default search path. The file
/sys/module/firmware_class/parameters/path
exists, but is empty.
Oh, it looks like the firmware search path was changed in Debian 8 (“Jessie”). Is there some parameter I can set to get /lib/firmware/updates back on the search path?
I understand the caution, but it would be something along the lines of:
sudo mv /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.bak_20240207
sudo mv /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin.bak_20240207
sudo mv /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin.bak_20240207
sudo cp /my/cool/path/BT_RAM_CODE_MT7961_1_2_hdr.bin /lib/firmware/mediatek/
sudo cp /my/cool/path/WIFI_MT7961_patch_mcu_1_2_hdr.bin /lib/firmware/mediatek/
sudo cp /my/cool/path/WIFI_RAM_CODE_MT7961_1.bin /lib/firmware/mediatek/
sudo update-initramfs -u
Reboot. In the unlikely event that the machine will not boot:
sudo rm /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
sudo rm /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
sudo rm /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin
sudo mv /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.bak_20240207 /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
sudo mv /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin.bak_20240207 /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
sudo mv /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin.bak_20240207 /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin
sudo update-initramfs -u
Reboot, and you are back where you started.
As an aside, concerns like this are where I really like timeshift.
Welcome to the community!
As Mario has indicated, this is a known Ubuntu bug that is in process to be sorted out.
It’s also worth noting this does not affect all router connections, as it does not affect my own for example - this makes duplication very tricky. That said, it is a known bug and it is coming out as a fix in future updates.
If after following the suggestions provided by Mario, you’re still having issues, you may open a ticket where we can provide additional detailed steps to work through after reviewing your logs at length. When doing so, please link this thread into the ticket to provide additional context.
Linux will present bugs from time to time, so we work through them as we can as fast as we can.
Unofficially: Some folks who have found the MediaTek card isn’t something they wish to work through have opted for the Intel AX210 wifi card as a fallback while these issues are worked through.
Thanks for getting to this!
If after following the suggestions provided by Mario, you’re still having issues […]
As we’ve been discussing, Mario’s proposed fix doesn’t work as written, possibly because of this change in Debian’s firmware search path. I’d very much appreciate either a way to modify the search path or, as a last resort, someone at Framework testing lbkNhubert’s riskier suggestion before I try it on the machine I’m currently using.
[…] you may open a ticket […]
I opened a ticket on Monday. (I wasn’t given a ticket number, but the submission time was around 05:30 GMT.) The initial support request linked to both this community thread and the parallel one that I opened. So far, I haven’t seen any substantive support from anyone labeled as a Framework support team member, either on the community forum or by e-mail.
As Mario has indicated, this is a known Ubuntu bug that is in process to be sorted out.
Since this is a known bug, and the Laptop 13 (AMD Ryzen 7040 Series) ships with a MediaTek wireless card, I’m confused about why the compatibility guide says that wi-fi and bluetooth work out of the box under Ubuntu 22.04 on this machine.
After this issue is resolved, I’d appreciate a better understanding of the testing routine that Framework’s compatibility guides are based on. This will help me calibrate my expectations for the guides’ accuracy.
Getting things setup on my end now for replication and eyes on it.
However, at the time of the guide, yes, it worked out of the box. This may shift if the patch is held up too long. But I just connected to my wifi router just now without any issue.
The issue affect some routers, not all (and not that I have access to). So right now, I am focused on path differences and getting the correct firmware sorted. I will then examine the state of the patch release, determine if we need to adjust the works out of the box state of wifi from there.
Works with workarounds generally means when I go to connect, it does not. This has not been the case. The issue is the dropping - which has not happened in our testing, and recently, has shown itself to the surface. So we’re going to laser focus on resolution for that. 
This has been released to Noble, now we are waiting for this release of Ubuntu.
1 Like
This has my focus the rest of the day as others are affected as well. Please stand by, should have steps forward shortly.
1 Like
Getting things setup on my end now for replication and eyes on it. […] The issue affect some routers, not all (and not that I have access to).
If there’s anything I can do to help you replicate, please let me know. I’m using networks on these two routers:
- TP-Link Archer C4000 (both 2.4 GHz and 5 GHz networks)
- Ubee UBC 1322 (router chooses between 2.4 GHz and 5 GHz for each connection)
I haven’t been able to maintain a stable connection on either of them.
The issue is the dropping - which has not happened in our testing
Most reports of this and similar issues describe drops happening “after a few minutes” (this thread) or “about every 20 minutes,” which is consistent with my experience. The laptop has sometimes maintained a connection for as long as a few hours, but I don’t think it’s ever gone more than eight hours without dropping.
1 Like
Appreciate it. I am digging into Ubuntu 22.04.3 using the /lib/firmware/mediatek directory path found for this release. This is path for Ubuntu and we have another individual who has had success here. So working this out now.
You did indicate something about path as /lib/firmware/updates for Debian - I cannot speak to this as with our tiny team, we have not touched anything with that distro. If I followed this correctly, seems you indicated Debian in this instance?
In any case, I will have something for Ubuntu shortly to be crafted as a one an done, although it may be a temp stop gap until the Noble fix rolls into LTS.
Tested this manual approach, rebooted without any issues. I will need to aquire a 6E compatible router to make sure all remains well as my older config may be misleading.
Ubuntu 22.04.3
OEM D kernel 6.5.0-1024-oem
Dropped in:
into /lib/firmware/mediatek
Please wait for the beta of the one liner coming shortly, this is for detailed informational purposes only.
cd Downloads && sudo mv *bin /lib/firmware/mediatek
Reboot
Seems to be good. But I lack the 6E+ wifi. But on my wifi 6 router, smooth as butter.
Since I have static bin files I can pull down, I’m going to toss together something for folks to beta test for me until I get a newer router setup here. It will be a one liner script:
Once I get it tested here.
- Copy, paste, run, reboot.
This will buy us time while we wait for the Ubuntu team.
1 Like
You did indicate something about path as
/lib/firmware/updatesfor Debian
Like Max_Power, I’m running Ubuntu 22.04. I wanted to understand why update-initramfs wasn’t loading the new firmware from /lib/firmware/updates, even though that directory is on the generic Linux kernel firmware search path. I suspect the answer is that Ubuntu, being a Debian-based distribution, uses the Debian firmware search path, which apparently—as of Debian 8—only includes /lib/firmware.
Thanks for testing! For the benefit of any new users who might follow these instructions in the future, I want to quickly flag a problematic one:
# [don't do this] cd Downloads && sudo mv *bin /lib/firmware/mediatek
This can have unpredictable effects, which depend on the contents of the Downloads directory. I’d recommend editing your post to specify only the names of the binaries we want to move.
1 Like
Can you confirm that just replacing the binaries in /lib/firmware/mediatek and rebooting—without calling update-initramfs—was enough to get the new firmware running? I just did this, and I’m still seeing the same build times 20221227123243 (for “WM Firmware”) and 20221227123154a (for “HW/SW”) in my dmesg output, suggesting that the new firmware still isn’t running. What does your dmesg output look like?
Checking now - Okay, I am seeing the same.
driver: mt7921e
version: 6.5.0-1014-oem
firmware-version: ____000000-20221227123243
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
I will have to circle back to this on Monday when I return to the office.
Here’s what I’m seeing when the updated firmware is loading:
mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20231120183400a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20231120183441
(Note: I’m on Noble (24.04) on this system for looking at other newer kernel bugs, so it came directly from the linux-firmware package for me)
I’m not sure why the /lib/firmware/updates search path isn’t working for others though. But at least when it’s working you can reference the above versions.
2 Likes
Thanks for confirming the build times for the new firmware!
I’m not sure why the
/lib/firmware/updatessearch path isn’t working for others though.
I’m pretty sure it’s not working for anyone, because that directory hasn’t been on the Debian search path in over a decade. I can’t find any documentation about the Ubuntu firmware search path, so I’m guessing it’s taken from Debian.