Question Motherboard Firmware

Mar 11, 2023
2
0
10
A general question: Is firmware to run fundamental motherboard functions such as, control & the timing clock for data busses baked in by the board manufacturer or are these functions included in UEFI?
Thanks!
 
A general question: Is firmware to run fundamental motherboard functions such as, control & the timing clock for data busses baked in by the board manufacturer or are these functions included in UEFI?
Thanks!

Firmware refers to software that is resident in a read only memory location. When the firmware is used to initialize and control basic computer functions it's called a BIOS. UEFI is special sort of firmware BIOS used in modern PC's.

So a UEFI BIOS may have the code to initialize and operate the computer during the booting process but most of those functions are taken over by a modern OS, such as Windows 11 and Linux, after the boot-up is completed.

During the boot-up the UEFI BIOS may tell a bus clock to operate at a specific frequency but after boot the clock just operates at that frequency, no further instructions needed. In some cases you may be able to change the clock frequency after boot-up through the OS with an appropriately coded application.
 
Last edited:
Firmware refers to software that is resident in a read only memory location. When the firmware is used to initialize and control basic computer functions it's called a BIOS. UEFI is special sort of firmware BIOS used in modern PC's.

So a UEFI BIOS may have the code to initialize and operate the computer during the booting process but most of those functions are taken over by a modern OS, such as Windows 11 and Linux, after the boot-up is completed.

During the boot-up the UEFI BIOS may tell a bus clock to operate at a specific frequency but after boot the clock just operates at that frequency, no further instructions needed. In some cases you may be able to change the clock frequency after boot-up through the OS with an appropriately coded application.

Thanks for your timely reply.

The focus on my inquiry is on the control and clock components of the board's data busses. Thanks for the clock feedback. I'll consider that part of my question resolved. How about the control component? Is that also part of UEFI or is that baked in by the board manufacturer?

~Phil
 
Unified Extensible Firmware Interface (UEFI) is a specification for a software program that connects a computer's firmware to its operating system (OS). UEFI is expected to eventually replace basic input/output system (BIOS) but is compatible with it.

UEFI is a middleman. Software is so varied, as is a pc's firmware, that UEFI is used as the go-between to create compatibility where none would otherwise exist. So UEFI doesn't actually 'control' anything, but only facilitates control via other input. So if you want to change bus speeds, the software used in bios that you can use/see uses UEFI to translate your instructions (the clock settings) to something the bios code can understand.

It's why undoing an OC manually, by manually changing settings back to 'auto' etc doesn't always work, because there's settings in the bios code that often get changed, but are still in 'spec', that aren't listed by the software, and you get instability. Resetting to 'factory default optimised' resets All settings, hidden and visible.

Some bios software lists more settings than others, the settings are there in all, but only accessible by some. Big difference between an Asus ROG Extreme and Asus Prime. Same bios, different accessibility. So control over certain things will be determined by the board, which has certain software limitations built into its bios, UEFI just being what enables you to change the code according to what settings are available to be changed.
 
Here's the short of it without explaining every bit of firmware/bios/etc.. which there are numerous articles and wikis on.

Firmware/BIOS is a "If it ain't broke, don't fix it" thing. Unless you have a specific technical issue or compatibility issue, you shouldn't update it.

Any functions that are available will either be in the bios or won't. An update is unlikely to add features. Sometimes there are AMD or Intel tools to tweak from Windows but YMMV.
 
Last edited:
Here's tbe short of it without explaining every bit of firmware which there are numerous articles and wikis on.

Firmware/BIOS is a "If it ain't broke, don't fix it" thing. Unless you have a specific technical issue or compatibility issue, you shouldn't update it.

Any functions that are available will either be in the bios or won't. An update is unlikely to add features. Sometimes there are AMD or Intel tools to tweak but YMMV.
Not really and not every time, New BIOS versions are mostly about compatibility with new HW like CPU, PCIe RAM etc, but also to fix bugs or make things easier and better on auto or even for netter compatibility with OS version. Just one example. latest BIOS version for my MB brought me about 10% better CPU performance and over 20% GPU by optimizing PCIe bus. to use RAM as VRAM and VRAM's direct access to NVMe SSD, Part of AMD's BIOS is AGESA code which has direct influence on RAM and general behavior of CPU.
Modern MBs have BIOS with SW to safely update/upgrade BIOS version and some even to do it with "wrong" CPU some even without it. Quite safe when you follow instructions and takes couple of minutes.
Doesn't take any special skills except for reading skill to follow instructions.
 
I feel like people think UEFI does magical things to the base system, but, as complicated as it can appear to be, it's not like that.

So to start, I've looked at a couple of instances of boot-up code, that is the absolute first thing the CPU runs when it's either powered on or the reset pin was asserted. While one of them was much more simpler (and I had to modify it to look to see how the CPU woke up), another one I would argue could basically be that system's version of BIOS or UEFI. It's just that it was much more simpler and all the settings were hard-coded because it wasn't meant to be a user-facing system. Rather, a system to support a much larger system.

In any case, the idea of boot-up code is simply the following: configure the system in a way that makes it usable for something else to take over. In the case of say a PC's UEFI, it could be the following:
  • Configure the clock speed of the CPU
  • Configure speed the RAM should run at
  • Check if there's anything connected to the SATA ports
  • Check if there's anything connected to the PCIe lanes
  • Initialize the USB controllers and check if there's anything on their ports
  • Configure the peripherals that responded or the UEFI is supposed to know with whatever settings was saved off
Once all of this is done, that's it. UEFI is mostly done and hands control over to the OS. I say mostly, because there are several services that UEFI provides to the OS that are beyond the scope of the OS. These include system management features (which is a whole can of worms), ACPI (the thing responsible for shutting off your computer automatically when you initiate a shut down, among other things), and real-time clock timer functions.

The one thing I keep seeing that people seem to believe regarding UEFI is that UEFI has a role to play in the overall performance of the system. I argue, it doesn't. If the configuration settings are correct, then once the OS starts booting, UEFI is no longer running except for those services I mentioned earlier which do not affect how the rest of the system behaves, as most of them are outside of the scope of the system itself. And I saw this with one example of boot-up code. Once it was done running all the hardware initialization and configuration, the last thing it ran was basically "run the OS." Everything after that are returns to an infinite loop. While I can't say for certain this is how UEFI behaves, I can't imagine UEFI being any different than any other boot-up code in the general scheme of things (and if someone wants to argue otherwise, 1. have you actually looked at boot-up code? and/or 2. Have you actually looked an implementation of UEFI?)

Now people may point out microcode updates through UEFI. The thing is, those primarily meant to patch hardware bugs. And they may not provide a performance benefit. The easiest example are all those Spectre/Meltdown changes. Another one was on the Phenom to basically kill the TLB to avoid a TLB bug. The really annoying thing though, at least with AMD since I've used the AM4 platform for about 5 years now, is nobody documents the changes these updates are supposed to bring unless their hand is forced. Hardware represents the foundation of how the rest of the system runs, so I kinda want to know what's going to change with my hardware if I do the update.

In any case, the tl;dr is UEFI's sole job is to configure and initialize the hardware to a basic state. The OS will take care of the rest.
 
Thanks for your timely reply.

The focus on my inquiry is on the control and clock components of the board's data busses. Thanks for the clock feedback. I'll consider that part of my question resolved. How about the control component? Is that also part of UEFI or is that baked in by the board manufacturer?

~Phil
Control of what, exactly? If you mean control of the FSB (Front Side Bus) clock it is controlled by whatever generates it: a PLL (Phase Locked Loop) controller, for instance, which may be a part of the CPU, chipset or even a discrete PLL circuit. CPU clocks are controlled by micro-code in the CPU itself and what might be called it's "boost algorithm". CPU clocks (and memory clocks as well as most others including PCIe and SATA bus) are frequently fixed multiples of the bus clock so they will also increment in step with changes to the FSB clock and it's controller.

During boot, the BIOS (UEFI) will initialize the FSB clock PLL controller, CPU and memory, etc. clock multipliers based on settings stored in CMOS or coded in BIOS. Again, once the boot is complete BIOS is out of the picture. The PLL controller is responsible for maintaining stability of the FSB clock which keeps each device (CPU and memory, etc) stable. The CPU does it's thing internally, boosting and reducing it's own core clock multipliers as needed based on temperature, processing needs and other factors.

You can make changes to some device clocks, by changing mulitipliers, through the OS using an appropriate application: AMD Ryzen systems use RyzenMaster for this. But the BIOS is out of the picture until it boots up again.

Modern computers can also control, in a limited way, the CPU's "boost algorithm" through the Windows OS Power Plan settings. It can have effect on how often or long it boosts a core to maximum clock, a core's idle clock and how often it puts individual cores into a deep sleep state when it's clock is completely turned off.
 
Last edited:
It doesn't have to be "technical issue" But just to make it better. If everything was hanky-dory they wouldn't release new BIOS,
Better in what way?

Compatibility for new CPUs? That doesn't matter to me if I don't plan on upgrading the CPU
Compatibility with RAM? I've never used RAM from the motherboard's QVL document and had basically zero issues, so I don't even know what that's talking about (and they never say what changed anyway so...)
Bug fixes? Which bugs? If they really affected my system, then how come I wasn't seeing odd behavior?
Features, like say PCIe Resizable BAR? Well if I don't have hardware that doesn't take advantage of it, then it doesn't matter
 
Newly discovered vulnerabilities.
Which may not be a problem if I don't use some feature that the vulnerability targets anyway. The only place where these vulnerabilities would matter is in the runtime services, but if I already don't use most of, say for example, system management mode features/services, then how much of a concern is it really?

Plus again, these are never really disclosed anyway unless the company's hand was forced. It's funny how Microsoft provides a detailed list of what security fixes the Patch Tuesday update brings, but these companies that push out firmware updates can't do something better than "Improvements"
 
Which may not be a problem if I don't use some feature that the vulnerability targets anyway. The only place where these vulnerabilities would matter is in the runtime services, but if I already don't use most of, say for example, system management mode features/services, then how much of a concern is it really?

Plus again, these are never really disclosed anyway unless the company's hand was forced. It's funny how Microsoft provides a detailed list of what security fixes the Patch Tuesday update brings, but these companies that push out firmware updates can't do something better than "Improvements"
I'm just saying....that might be a reason for a new firmware update.
Even if you do not use that particular function right now, you might later.
Or some function that is vulnerable to a drive by exploit.
 
I didn't and wouldn't say it's am must to update but...
Please read descriptions for each BIOS version for own MB and decide from there. Here's last one (as an example) for my MB.
https://www.asus.com/motherboards-c...-pro/helpdesk_bios/?model2Name=PRIME-X470-PRO
PRIME X470-PRO BIOS 6061
Version 6061 Beta Version 15.32 MB 2023/02/09

"Beta BIOS
  1. Update AGESA version to ComboV2PI 1208
  2. Mitigate the AMD potential security vulnerabilities for AMD Athlon™ processors and Ryzen™ processors
It not only brought what it says but also side effects with better performance as I outlined in previous post.
I know updating BIOS was and is scary to for some and it really was in the past but now it's quite easy and safe with safety features like dual BIOS, external button and SafeBios with Asus, where it only takes to insert original CD which came with it or place BIOS file in Fat32 formatted USB and it will install it if BIOS was corrupted.
So now, I didn't have to update as it was working with previous ones but not as good,
It's 4th BIOS update since last one that had to be installed because of compatibility with new 5000 series Ryzen. Each one brought something new and improved and fixed some bugs.
 
Last edited:
I'm just saying....that might be a reason for a new firmware update.
Even if you do not use that particular function right now, you might later.
Or some function that is vulnerable to a drive by exploit.
Well after digging around I did finally find the security vulnerabilities that AGESA 1.2.0.8 (the latest one for AM4) is supposed to mitigate. But 1. it shouldn't have been that hard to find (I found it on Reddit) and 2. some of the aspects of the page, like how it's titled, is probably throwing off the search engine spiders

It not only brought what it says but also side effects with better performance as I outlined in previous post.
And for science I updated my motherboard's UEFI from 2.40 to L2.62, and the only reason why I went to 2.40 was because I upgraded to a GeForce RTX 40 card. People were saying AGESA 1.2.0.8 would bring about performance improvements. Okay, so I ran 3DMark Time Spy, Raceway, and the CPU Profile, along with Cinebench R23. The new update effectively brought about zero improvement. Or at least, no overall general improvement.

It's 4th BIOS update since last one that had to be installed because of compatibility with new 5000 series Ryzen. Each one brought something new and improved and fixed some bugs.
Bug fixes don't generally improve performance. A bug is a fault with the logic. And I don't buy "Improves performance" if nobody's done any A-B testing on it. There's also the question of if updates from the original gradually caused performance to drop from implementations that just needed to happen and get shipped without doing another pass to clean up or optimize the code, and any semblance of "improves performance" was really just doing code cleanup to get the performance lost after the baseline.
 
'improves performance' is both generic and highly subjective. All the update has to do to qualify for 'improves performance' is to do just that, even if it means ram times decrease from 10.67ns to 10.65ns. That's increased performance. It performs better, faster. But there's absolutely no wording added to 'improves performance' that's any guarantee of anyone actually seeing a visible difference in fps, boot times, processing times etc.
 
A general question: Is firmware to run fundamental motherboard functions such as, control & the timing clock for data busses baked in by the board manufacturer or are these functions included in UEFI?
Thanks!
The firmware that runs fundamental motherboard functions, such as controlling and timing the data busses, is typically included in the motherboard's BIOS (Basic Input/Output System).
The BIOS is a type of firmware that is stored on a chip on the motherboard and is responsible for initializing and configuring the hardware components of the system, including the CPU, memory, and storage devices. It also provides a basic set of input/output routines that allow the operating system to interact with the hardware.
UEFI (Unified Extensible Firmware Interface) is a newer type of firmware that has largely replaced the older BIOS system. UEFI provides a more modern interface and additional functionality, such as support for larger hard drives and faster boot times. However, UEFI still includes the basic functions that were previously handled by the BIOS, such as controlling the timing and data busses.
So, to answer your question, both the BIOS and UEFI include the functions necessary to control and time the data busses on a motherboard, with UEFI being the more modern and feature-rich option.
 
  • Like
Reactions: Karadjgne
'improves performance' is both generic and highly subjective. All the update has to do to qualify for 'improves performance' is to do just that, even if it means ram times decrease from 10.67ns to 10.65ns. That's increased performance. It performs better, faster. But there's absolutely no wording added to 'improves performance' that's any guarantee of anyone actually seeing a visible difference in fps, boot times, processing times etc.
However even something like that can be muffled by something else later down the road. Sure you might've decreased the latency, but if the other bits of hardware still lag behind such that it doesn't matter, then there's no actual performance gain. It's about as good as claiming a monitor has 1,000,000:1 contrast... in very specific settings that nobody really uses said monitor in.

Bugs should be fixed even if they don't impact performance. Shouldn't tolerate them even in a toaster.. In a car or gun they can kill you.
Sure, but humans only have so much bandwidth to take care of problems. If there's a bug in blinking a cosmetic LED, that's going to be so low on the priority list because it doesn't affect any core part of the system. Or more to your point, maybe there's a bug that trips the empty tank light at 24% full rather than 25% full. Is that necessary to fix?

And yes, I've worked on safety critical systems before. Issues are categorized based on their severity. If it's anything other than "the system as a reasonably high chance of blowing up", it's given a lower priority.