It’s not unusual for BIOS version numbers to skip versions. Sometimes it’s due to internal beta builds. Or wanting to align versions. I’ve often seen on my desktop board the ‘gap’ between version numbers be +4, sometimes even +5.
Look at the previous release - we had multiple buggy builds that were held back and the effective stable delta was 3.05 to 3.09. What’s the difference except that intermediate versions were de facto ‘public beta’?
Honestly, it’s completely irrelevant, the only thing that matters is satisfying {nextVersion} > {prevVersion}. It’s just numbers… Calling it a mess is a bit silly.
No. What I’m saying it it doesn’t matter if there was any specific reason and I see no reason why anybody should care. The only thing that’s relevant to an end user, and dare I say the system itself, is to validate if {nextVersion} > {prevVersion}. The base is irrelevant.
From a curiosity perspective I can certainly stand behind this question. I’m not too familiar with Windows, but I wouldn’t be surprised if raw values reported to the OS are hexadecimal, while the “human-readable” values would be reported as per whatever is encoded as the "version string”. This would explain why the value under Firmware device in Device Manager would show as 310.
Does it also read 310 / 3.10 in other places where there is a text-readable version? If so, that would be more peculiar. In general, I see “3.16” everywhere where the returned value is plain text.
So I don’t think it’s a discrepancy, as somebody else suspected above, or Framework trying to “visually” match between bases. I think the most likely scenario is what you already alluded to, i.e. unpublished intermediate builds. Or just skipped builds, for whatever reason.
Edit: Sorry, I just came across FW’s explanation for the jump, not sure how I missed this earlier in the thread.
Not familiar with the specifics here, but I still see it as a rather benign reason.
Not sure if it’s actually consistently reproducible, but I would suggest unsetting the supervisor password before the upgrade.
NOTE:
I’m located in Taipei, so if Framework people like to check it out in person, feel free to reach out to me. I will resist the temptation to do a full mainboard reset for a couple of days.
UPDATE: A certain incident at my workplace forced me to do the BIOS password reset procedure on my system, as a result, I can no longer reproduce this problem.
It doesn’t matter: the new firmware version is specifically chosen to avoid the ambiguous interpretation by the software (no 03.10 version ever existed, so no one will confuse it with the 03.16 version).
Some software may still treat the string as a sortable version string(e.g. fwupd), so the field shouldn’t be treated as a free-form string.
On that note, I also have a BIOS supervisor password and upgraded to 3.16 yesterday through LVFS. I did not encounter any such issues and entering BIOS set up works just fine.
$ doas ryzenadj -a 43000
detected compatible ryzen_smu kernel module
Sucessfully set stapm_limit to 43000
$ doas ryzenadj -c 43000
detected compatible ryzen_smu kernel module
Sucessfully set slow_limit to 43000
$ doas ryzenadj --apu-skin-temp 43000
detected compatible ryzen_smu kernel module
Sucessfully set apu_skin_temp_limit to 43000
Did you select performance mode? This should set both stapm-limit and fast-limit to the maximum of 53W.
Happy to hear though that the slow limit still works. I don’t think its an intended feature to run the low power U skew at 43W instead of 28W all the time and it wouldn’t be the first time that a CPU manufacture takes away feature after purchase…
powerprofilesctl set performance sets stapm-limit and fast-limit to 46.0 for me. I was still unable to manually set it however.
Probably not. These were just his requested test settings from the last bios thread. I have unfortunately never had the time to look into putting together a set of ryzenadj configs for my purposes; I just have it installed from back when I discovered it and thought it useful.
Via the AMD PI update? That would be disappointing.
after running fwupdmgr update on my Framework 13 (AMD 7040 series) to upgrade to version 3.16, my external monitor stopped working correctly in Ubuntu 24.04.
The monitor now appears as “Unknown Display” in display settings.
It is limited to 640x480 resolution only.
This issue started immediately after the firmware update.
Kernel version: 6.14.0-28-generic
Has anyone else seen this problem after the latest firmware update? Does anyone know how I could address this issue?
Many thanks in advance for your help!
EDIT: I tried booting into the 6.8.0-1032-oem kernel, and with that version the external monitor works normally again — it is detected correctly and full resolution is available. So this seems to be a kernel/driver compatibility issue rather than a problem with the 3.16 firmware itself.
Argh! Only recently did I solve a problem whereby LibreOffice’s Impress would hard hang the system when displaying some particular slides onto an external monitor. (See here.) And now . . a BIOS update messes up external screens (and might also lock one out of the BIOS)? Lord above!
Currently I am on kernel 6.8.0-1032, non-OEM, on Linux Mint 22.1 (which is based upon Ubuntu . . 24.04). How, please, does one get the OEM kernels?
Thank you. I appreciate your taking the time to supply that information. Perhaps I will use that information at some point; for the moment, I shall wait in the hope that Framework provides a less buggy BIOS.
