To (flash) BIOS or not to BIOS

Topic

New Reply

At the end of the day, this one is for me to decide.  But, any thoughts would be helpful.

I believe in the “don’t fix it unless it’s broke” way of thinking.  That’s why I’m on W10-1809 and happy about it on my ThinkCentre M920s.  Some 5-6 months ago I updated the BIOS per Lenovo’s recommendation, however, as I found my computer a bit sluggish (relatively) thereafter, I down-flashed the BIOS back to its previous state.  All good.

As I’m now behind several BIOS updates (all cumulative), I’m not sure what to do.  Here is a list of the updates recommended (the top is current; bottom one is where I am now):

CHANGES for M1UKT59A
– Enhance HDD password support.

CHANGES for M1UKT57A
– Enhancement to address security vulnerability.
– Update CPU Microcode.

CHANGES for M1UKT56A
– Enhance C State support.

CHANGES for M1UKT55A
– Enhancement to address security vulnerability.
– Enhance BIOS SETUP support.

CHANGES for M1UKT53A
– Enhancement to address security vulnerability.
– Update UEFI DIAG to 4.12.001

CHANGES for M1UKT52A
– Enhancement to address security vulnerability.
– Update CPU Microcode.

CHANGES for M1UKT50A
– Enhancement to address security vulnerability.
– Enhance NVMe SSD detection.

CHANGES for M1UKT4FA
– Enhancement to address security vulnerability.
– Update UEFI DIAG to 4.11.

CHANGES for M1UKT4EA
– Fix some TIO multi display issue for M920x.
– Enhancement to address security vulnerability.
– Update Setup layout.

All recommended and not listed as critical.  I could of course update and in case of trouble revert to where I was.  Any suggestions?  Thanks.

Reply | Quote

Replies

I tend to support the “if it ain’t broke, don’t touch it” approach.  However, I also believe in avoiding security risks.  So, IMHO, updates that reduce security vulnerability should be installed.  (You have previously “downflashed” successfully, so I suppose you could always do it again if the latest update adversely affects performance).

My Rig: AMD Ryzen 9 5900X 12-Core CPU; ASUS Cross Hair VIII Formula Mobo; Win 11 Pro (64 bit)-(UEFI-booted); 32GB RAM; 2TB Corsair Force Series MP600 Pro 2TB PCIe Gen 4.0 M.2 NVMe SSD. 1TB SAMSUNG 960 EVO M.2 NVME SSD; MSI GeForce RTX 3090 VENTUS 3X 24G OC; Microsoft 365 Home; Condusiv SSDKeeper Professional; Acronis Cyberprotect, VMWare Workstation Pro V17.5. HP 1TB USB SSD External Backup Drive). Dell G-Sync G3223Q 144Hz Monitor.

Reply | Quote

I believe in the “don’t fix it unless it’s broke” way of thinking.

Im the same. To be honest, if I upgraded BIOS, it always worked.
But I try to do this only if I have some problems. If PC is malfunctioning or similar.

It should be upgraded, if there are newer versions, but my opinion is to stay until problems occurs.

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

1 user thanked author for this post.

Biiljoy

Reply | Quote

I agree with doriel flashing ROM isn’t worth it for me unless the system already doesn’t boot.  I wouldn’t want to brick it especially without a reason to be upgrading in the first place.  I’d leave it alone, you’ve been lucky so far.

Reply | Quote

[EP]

@CBA

if your ThinkCentre M920s have been recently purchased, you don’t have to flash update the BIOS.

also unless you are thinking of installing/upgrading to newer or faster CPUs onto those ThinkCentre PCs (hence the “Update CPU Microcode” messages in the bios update changelogs), it’s best to keep the BIOS version as it is

btw, support for Win10 v1809 home & pro ends on November 2020; you will need to upgrade to at least 1903 or higher (though support for 1903 ends on December 2020)

• This reply was modified 4 years, 8 months ago by EP.

Reply | Quote

Interesting replies, thanks.  Well aware of the fact that I have to upgrade 1809 by 11/20, I was thinking about the need to have a current BIOS version ahead of that.

I gather Lenovo has offered (recommended) 10+ BIOS updates since I got my M920s in 05/19 (with 1809).  I have flashed the BIOS 2-3 times via Vantage downloads.  Lenovo’s (and IBM’s) flash update procedure is generally straightforward and quite good.

Don’t think it’s a good idea to wait until the system won’t boot.  That’s asking for trouble.

The “Update CPU Microcode” reference, afaik, plugs security holes in the Intel CPU.  The code is normally provided by Intel to Lenovo, again, afaik.

 

Reply | Quote

Firmware update was made for reason, these changes were made, cause there were errors and holes in the code or something was malfunctioning.
You definatelly should update your BIOS since manufacturer recommends, there is no doubt about it.

But as I stated before, I update BIOS rarely. When problem occurs to be exact.

Don’t think it’s a good idea to wait until the system won’t boot. That’s asking for trouble

Thats right. On the other hand..

That’s what I used to do until the introduction of CPU Microcode Updates, which I think, in my, case caused a noticeable slowdown.

Whats the golden rule of technician? Do not change something that works reliably.
Just my opinion.

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

Reply | Quote

I always flash new versions of BIOS as they come out.
The BIOS (UEFI) is the main component on the motherboard and should be,
in my opinion, up to date.

Reply | Quote

[CBA]

That’s what I used to do until the introduction of CPU Microcode Updates, which I think, in my, case caused a noticeable slowdown.  No way to know for sure what caused it though and maybe it was fixed in later versions.  Hope so…

• This reply was modified 4 years, 8 months ago by CBA.

Reply | Quote

[Ascaris]

As long as the ability to go back is still there, I would at least give a new firmware revision a try. There are often other changes that are not listed in the patch notes, and they’re often things you’d want, like stability or bug fixes. But there’s also those that go the other way.

A couple of years ago, I installed a firmware on my Swift that caused a problem (bugged display of which UEFI bootloader is selected, with the entire list of up to 13 bootloaders consisting of blank spaces where actual bootloaders with names are installed, and the rest of the list consists of multiple entries for two of the bootloaders). Not only that, but legacy BIOS boot mode is not selectable despite being a visible option.  I’ve tried to go back to the previous firmware, but Acer blocks it, and my attempts to get around it failed. I use UEFI mode anyway, and once it’s set up, I don’t need to change the bootloader options, so it’s not a huge deal, but it will factor in my purchase decision if I ever ponder buying another Acer, or any other PC with Insyde firmware.

Fortunately, that update for the Acer’s firmware did not contain what is now the most recent microcode, as that thing is a disaster for stability. When I was installing Fedora on the Acer the other day, and after its first update after its first official boot,  it locked up several times within an hour, and it was obvious at that point that the update must have pulled in the new microcode. That microcode is a disaster… it hard locks without warning, and there is no way to recover it other than to hold the power button to force it off.  It can go a day without having one (the maximum) down to having it fail repeatedly, with each failure within minutes of the previous.

If that microcode had been in the irreversible update, I’d be stuck with it unless Intel decided to release a fix, and we’re coming up on 9 months now since the broken one was released.

When the microcode is updated by the OS, though, it’s reversible. Microcodes are stored in volatile memory on the CPU, so it has to be loaded from the firmware at each power-up. If the OS has a newer one than is already loaded, it will unload that one during the boot process and replace it with the newer one. If you get rid of the one the OS has, it can’t do that. On Linux, it’s easy to swap the newest one with a slightly older one that actually works, which is what I did. The microcode driver, though, won’t replace a newer microcode with an older one, as far as I know, since the assumption is (as with firmware itself) that newer is always better. Quite evidently, that’s not always the case.

Unlike the Acer, my Dell G3 has a checkbox in the settings for “allow firmware downgrades,” which seems rather definitive. The key word being “seems.”

Not long ago, I found that the most recent update for the G3 had the effect of disabling undervolting, which resulted in a pretty hefty performance decrease, and it was all an unnecessarily heavy-handed fix for the purpose of getting rid of a security issue in a thing (SGX) that I don’t use, care about, or have enabled. It would be nice if undervolting was only disabled if SGX was enabled, or if the OEMs that disabled it via software provided an option in the UEFI to do it from there instead, but the norm has just been to eliminate this much-used and popular feature across the board.

I tried to roll the firmware back, and at first it seemed to be working, but when the actual flash was taking place, it failed with a message about it being an unsupported downgrade. Man, do I hate the use of “unsupported” to mean “prohibited.” I didn’t ask them for support! I merely asked that if they have a checkbox for “allow downgrades,” it should actually allow downgrades.

I did find a hacky method online to downgrade the firmware, and performance is back to where it should be, but now I am even more cautious. I would not install any more updates until I knew that they were reversible in the normal way (without hacks).  I’d do much as Woody recommends with Windows updates, which is to say to wait for a bit to let others install the update first and wait and see if there are any cries of pain (at the hardware vendor’s site, perhaps) before taking the plunge myself. As I found, even having an option to allow downgrades enabled doesn’t mean that they will actually be possible.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

• This reply was modified 4 years, 8 months ago by Ascaris.

1 user thanked author for this post.

doriel

Reply | Quote

I keep BIOS’s current unless there’s a good reason not to.  Only once, in decades of managing computers have I run into a reason, a stupid one at that, to not upgrade.

We have a Dell T30 Xeon used as a home server.  It’s capable of using a nvme ssd as primary drive, has a semi-hidden slot for one.  The original few BIOS versions supported nvme, updated versions don’t.  The reasons given by Dell are gibberish, truth is likely that one can configure an excellent desktop or server for far less than anything comparable, oops!

The T30’s BIOS utility is very comprehensive, typical server stuff, screen after screen of settings, some rather inscrutable, nothing about enabling/disabling nvme support, though.

As I recall, their BIOS upgrade isn’t reversible unless you have a saved copy of the old BIOS which Dell no longer provides.  Of course an underground user based BIOS repository spawned to support those whose nvme’s boot drive suddenly disappeared after upgrading.

An unusual situation, devious at that, but stuff happens.  Download a copy of a functioning BIOS if there’s doubt about new versions.

Reply | Quote

Thanks!  The consensus (?) seems to be 50/50 “if it ain’t broke don’t fix it” and BIOS updates are offered for a reason and “one should keep it current unless there’s a good reason not to”, with the proviso that “one can always down-flash” if it doesn’t work.

As I said, at the end of the day, this one is for me to decide.  I’m checking with Lenovo too, to see if the 50/50 holds up.  As I’m fine as-is right now, this is a dry run for the future.

It goes without saying that a copy of the old BIOS software is needed for a down-flash.  In my case, I just ran the old software (BIOS level of my choice) and I was warned that this is older than the current and asked if I wanted to proceed.  I say “yes” and that was it.

Note: this may differ and you may need downloaded copies of both the current and old BIOS software to down-flash.  But that’s a different subject.

Reply | Quote

Interesting update from today experience:
I had Dell technician in our company today to replace our bulging batteries. Nothing serious, three batteries on Dell Latitude 5580 were defective, he said that this series has often problems with it.

And he said, that in order to prolongue battery life I should uprage BIOS. Because there is some update in microcode, that is improving charging. To tell the long story short, the update prevents from “micro-charging” – if the battery is 99,8% full, no charging is done. When the battery level drops to 95% for example, then it starts to charge again.

So.. I change my opinion to update BIOS regullary. Lesson learned.

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

Reply | Quote

doriel wrote:

And he said, that in order to prolongue battery life I should uprage BIOS. Because there is some update in microcode, that is improving charging. To tell the long story short, the update prevents from “micro-charging” – if the battery is 99,8% full, no charging is done. When the battery level drops to 95% for example, then it starts to charge again.

While it is possible that any given firmware update could contain tweaks that slightly improve the battery’s longevity, it’s not likely to make a really noticeable difference unless there was a pretty massive bug in the code before that. It’s been the norm for decades for laptops to stop charging the battery when it reaches a certain threshold (so they’re not being continuously charged even after they’re full).

My Dell G3 has several battery charging strategies available within the UEFI setup. There’s one intended to maximize the battery service life by never charging it all the way up, which also would have the effect of reducing the available run time on battery. I have it set for “mostly AC use,” since I seldom use the G3 on battery, and never for more than a few minutes.

The microcode has nothing to do with the charging circuit or its strategies. A firmware update contains a lot more than microcode, though, and changes to the charging strategy may well be among those.

If a battery is bulging, it’s not because of a non-updated firmware (again, unless there was a pretty major bug in the charging logic in the old one, which is unlikely). You would not have been able to prevent it with a firmware update… at best, you may have delayed it a small amount.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

doriel

Reply | Quote

doriel wrote:

he said, that in order to prolongue battery life I should uprage BIOS. Because there is some update in microcode, that is improving charging.

I’m usually in the “if it ain’t broke…” camp, but I check what’s being fixed to determine if mine’s “broke”.

In the case of doriel’s 5580 laptops, at least three recent BIOS updates — 1.17 (2020-04), 1.12 (2018-09), and 1.11 (2018-08) — mention “Updated the Power Delivery firmware”, which I’m assuming is in reference to the battery. Those are updates I’d consider worth installing.

The rest of the in-between updates (1.13-1.16) appear to involve CPU microcode vulnerabilities, such as Spectre and Meltdown. Those are updates I wouldn’t deem to be vital for a home user.

In doriel’s case, though, I gather he’s supporting his company’s machines, so he necessarily has to take a different point of view because those machines may well have a different exposure to threats than my personal machines.

 

1 user thanked author for this post.

doriel

Reply | Quote

Verify firmware signature first hahahaha, this seems ripe for a bad actor to replace the code with malicious code that could ruin the battery among other things (kaboom!).  Not worth it to me still but I know that is contrarian and paranoid but I would at least wait until the bios update had been out for a while to make sure I wasn’t first one on hold with rma support explaining why I done burned up.

Reply | Quote

Ascaris wrote:

If a battery is bulging, it’s not because of a non-updated firmware

It is if the charging scheme is too aggressive. LIon batteries are great but need to be charged very carefully.

cheers, Paul

Reply | Quote

Maybe it was too aggressive. It was Li-ion battery. Screws were literally ripped out.
If I prolongue battery life (even slightly) and if it can reduce the risk of fire or damaging laptop, this BIOS update is worth for me. I updated all Latitude 5580 BIOSes in our company today.

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

1 user thanked author for this post.

Ascaris

Reply | Quote

Wow, that’s pretty awful looking. Do you have any idea over what time period this bulging took place? My Dell does not use that particular battery, but it’s quite possible that it was sourced from the same supplier. I don’t want the first sign of the battery bulging to be damaging something else or ripping screws out!

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

Hello.
We have approx 40 NTBs in company, all Dell. I have the oldest one Latitude E6530) from year 2012, gave it SSD and it still works like charm! Never had a performance issue!

The problem started after more than three years. I can gladly give you exact manufacturing (shipping) dates of failing batteries:
March 2016 (Latitude E5470)
March 2017 (Latitude E5470)
July 2017 (Latitude 5580)
I had to replace these three batteries, because they were bulging.

I already replaced three other batteries in the past:
April 2011 (Latitude E6520) – already gone
May 2013 (Latitude E6530) – already gone
February 2016 (Latitude E5570)

because user were complaining about battery capacity. But this could be because of their user attitude. I mean somebody has their NTB connected all the time to power supply. It is good to let the battery empty sometime. Lets say once a week and unplug the notebook from powersupply/docking station before you go home from work.

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

Reply | Quote

The full sentence I wrote was:

If a battery is bulging, it’s not because of a non-updated firmware (again, unless there was a pretty major bug in the charging logic in the old one, which is unlikely).

If it was so aggressive in charging that it made an otherwise decent battery bulge, that would be a major bug.

A non-defective battery not going to bulge from aggressive charging alone– and by “aggressive,” I mean fast charging within the rated current, voltage, and temperature limits of the battery. Charging that goes outside of those limits is more than aggressive. It’s defective, both in terms of the logic that pushed that excessive voltage to the battery, and in terms of the battery’s onboard protections against overcurrent, overvoltage, overcharging, and/or overheating failing to do as they were meant to do.

Conversely, if the battery bulged after being exposed only to charging voltages, temps, and current levels that it is rated to handle, it’s the battery itself that is defective (and this is my guess as to what happened). If the battery fails to perform to the standards it was rated for, it’s defective.

A vendor could (and I am not necessarily saying Dell did this; I don’t have enough evidence to say one way or another) attempt to put a band-aid on a series of known defective batteries by artificially limiting the charge voltage (and thus current and heat) to well below what they were rated for, but even if that worked, it would not mean that charging within the rated limits of the battery as designed “caused” problems. The cause would be poor battery quality (which can include being overrated by its manufacturer), and the hypothetical firmware update in this example would be an attempt to fix it on the cheap (at the expense of the laptop owners, who now have to put up with much longer charging times) rather than fix the actual problem, which would mean replacing the battery with one that can handle being operated within its own engineering parameters. That can sometimes be more easily said than done (as Samsung would attest), but ultimately, a battery that bulges from conditions it was rated to handle is defective.

 

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

doriel

Reply | Quote

As the OP, my concluding comments: I finally updated the BIOS to the latest version.  So far so good, but only time will tell if there are performance (or other) issues.  Hope not!

What made me go ahead?  An impending update of my W10 1809 to 2004 before 1809 goes EOL.

If the BIOS has anything to do with this update, I have no idea.  But one never know!

Reply | Quote

Alex5723 wrote:

I always flash new versions of BIOS as they come out.
The BIOS (UEFI) is the main component on the motherboard and should be,
in my opinion, up to date.

Just updates my Lenovo Y530 with new BIOS which fixed some critical security bugs :

Modified

1) Disable memory OC feature;

2) Enhancement to address security vulnerability CVE-2020-0528;

3) Enhancement to address security vulnerability CVE-2020-0543/0548/0549;

4) Enhancement to address security vulnerability LEN-27433 BIOS Update Utility – DLL Hijack Vulnerability.

Reply | Quote