To be fair, that is how the process works. You version your stuff. If in the validation pipeline you disqualify a specific version, it’s on to the next version. So an update that was disqualified from final release in the beta stage, can have nothing else happen than be abandoned. You could only have a further subversion that you increment, but the same version cannot ever release if it is not fit for release. That is the whole point of versioning. Create an explicit relationship between version number and build.
The problem is the timeline, the vague promises and serious lack of any acceptable communication. Like I said, if there is a public beta and the version IS disqualified or even pulled, that should come with an explanation for what issues this happened and what the risk is/was. And some rough commitment to how it is intended to be solved. Or the beta should come with a hell of a lot more warnings.
And then there are the patterns of many if not most 3.06 Windows-based updates crashing in the middle repeatedly and the EFI installers failing on other things. These seem to be the exact same issues with 3.08, the EFI installer has now even been pulled, without communication. Known issues were never edited. They never were on the 3.06 beta that was obviously discarded but is still up. Canceling, or significantly holding back the release does not fit with no known or suspected issues. And FW chose to announce their timeline for that to placate owners when they stretched “soon” to mean a year the last time.
While on the 11th gen, the EFI installer has never even released at all, “because its not ready”, with FW listing this as “soon” since like september / october.
All the while users have been using older 11th gen updaters to install it anyway, so clearly its not that it could not work but just not reliable enough?
The issues with 11th gen seem suspiciously similar to ours and I’d bet that most of the update process is similar and both are affected by similar issues. (and who wants to bet that 13th gen just is not apparent yet, because it has never made it that far).
The Linux updates have been missing, because apparently Intel does not provide an updater for the ME firmware for linux, but just an EFI and a Windows one.
For the other things, the Windows updater uses EFI-capsules (1 BIOS, 1 for each ReTimer for 12th gen. Don’t know where the PD controller firmware is packaged in that the EFI updater installs separately).
EFI Capsules mean they are just handed over to the BIOS to update itself. And bad self-update functionality seems to be the reason for the terrible/lack of progress report or even error messages when it fails. Seems like solving this might be a prerequisite for getting more frequent updates rolling. So that nobody has to correlate the issues to expansion cards or plugged in USB devices. Seeing which component causes the updater to crash should really help with that.
EFI Capsules is what Linux seems to support just as well as Windows. But we also know that the ME update is a separate executable, even under Windows. It is the one thing the “installer” manually forces the update on before the reboot, even if the version is already up-to-date. You could easily update everything but the ME firmware from Linux with a process that should work very similarly to what happens in Windows. The fact that the Windows-updater installs the ME firmware update first and only then even proceeds trying the other updates, shows, that like with other Intel boards, the ME firmware can be updated separately. It might not be tested, it might not be perfectly stable while the versions do not match what is intended. But is likely enough to reboot and allow installing the rest.
The 11th gen users repackaging their own EFI-updater are not updating the ME firmware at all, for lack of an updater for it and they still report no issues with that (as I understand it, unless the ME firmware introduces breaking API changes or new features that the new BIOS relies upon, it should only solve bugs and security issues inside ME, but not otherwise endanger the stability)
Just using the EFI installer for the ME firmware should be much less to script and automate (and could even be given to those users as EFI command lines instead of an automated script that fails. It is mostly intended for those that chose to run Linux, which officially comes with a ton of commands from FW to get it into a supported state anyway).
The only situation that that probably would not solve is the battery-less installations, where only the EFI-updater seems to have the specific handling of updating the way the notebook powers itself without a battery in a way that ensures it not killing its own power during the update.
But that’d already support a lot more people than now. And FW seemingly finds the Windows updater stable enough, even though on 2 separate devices updating the ReTimer firmware got it into a crash-loop for me and a lot of other people.
I haven’t even talked about, how they still have not managed to update their download link to point to the fixed 3.08b installer that already fixed a bug in the installer refusing to start on some boards. Again, no mentions of additional risks of the 3.08b installer and not even bothering to finish what you started, even though it would only take them like 2 min.
Without any serious communication or visible effort, this just seems like FW either is incapable of solving the firmware update problems or does not care to.
Happy to be wrong on any of this btw, FW pointing this out would be being more transparent instead of stonewalling on this issue.
There was another contractor in between FW and Insyde (Compal) that is probably more involved in the FW specific parts of the updating. Isn’t Compal also involved in designing the boards?
Given how Insyde seems to use basically standard bundles of firmware that include a bunch of stuff that is not needed, I would expect them to also have reliable solutions for everything that is their business when it comes to updating (seeing as 3/4 of LogoFail was completely unnecessary, because FW does not use those fileformats for logos, but the parsers are there anyway, together with stuff like PXE booting. All attack surface with no benefit to FW other than Insyde can reuse a more generic image. If they then do not have that base image handled that’d be pretty embarrassing for them)
