Ain’t nobody got time for that 
…especially since there is some research and tweaking involved to get there. Main timings are easy, and usually documented right on the RAM when you buy it, but all the gazillion obscure subtimings that no one even knows what they are? Yeah, no.
Yes and no. DDR2, 3, and 4 do training, but not for as many signaling parameters and with wider margins due to the lower clocks. So it wasn’t until DDR5 that it took long enough become a well known thing.
Training occurs in all DIMM installations. Just gets notably more involved and takes longer in DDR5 2DPC configs compared to everything else.
No. Training is required at JEDEC speeds and timings and JESD79-5 standardizes speeds from 3200 to 8800 MT/s in increments of 400 MT/s. I’ve seen also mentions of also standardizing DDR5 at 9200+ but, so far as I know, JEDEC hasn’t done that yet.
No. XMP specifies a clock, voltages, and a few primary timings. It’s not involved in training. Same for EXPO.
No. Succinctly, the main training operations relate to CA, CS, write leveling, ZQ, VrefCA, VrefCS, VrefDQ, and ODT rather than what you’ve described. Refer to the relevant 12 subsections or so of JESD79-5 for the details.
I lock them. It’s really no a big deal.
I don’t know of any BIOS flash which doesn’t do that. Which is stupid since many of us then reenter the same parameters after every update. Yeah, if a load line moves or Vsoc gets a lower cap or something then there’s some constraints and maybe some thinking and retesting needed. But for the most part it’s invariant stuff like reentering all the control points on the fan curves, DIMM clocks + voltages + timings, or disabling wifi so your wired box doesn’t have that pwnage route.
That’d be a spectacularly weird way of deserializing a data file instead of just pulling it into memory and invoking the usual code to serialize to flash if the user chooses to save the BIOS settings and restart. Since anybody with physical access to the machine can do whatever they want in the BIOS menus without needing to load a saved profile from USB it’s not like it’s worth worrying about a security model.
But, eh, don’t my decades of experience writing similar code and maintaining its tests stop you from being convinced this is much harder than it actually is.
It’s not new to DDR5, but with DDR5 on AMD, training takes a weirdly long time (minutes). There’s a feature called MCR that saves the training parameters so your subsequent POSTs don’t take for ever. Apparently with these new BIOSes this MCR data is cleared after some time.
Ain’t got no time to look at the values already displayed in BIOS and change them from auto to match what’s already there? You sound really busy. You should probably get off the forums and back to it.
It’s not a file. It’s a segment of memory stored in the BIOS. Again, coding is not the problem.
But that’s just it, it’s not invariant. It’s invalid.
How to read from SSD before BIOS is initialized? Pic is very relatable. 
Training has been around for many previous generations of DDR. Check the JEDEC specifications. DDR5 is just pushing the envelope of existing achievable signaling margins and now must be very precise in determination. This is similar to how PCIe Gen5 often requires re-drivers (re-trainers?) to establish a stable and reliable link.
MCR (Memory Context Restore) is not a feature, it’s a flag that determines whether the memory controller will initiate a full re-train or make use of existing parameters. This new “feature” added by MSI would simply clear this flag if set based on the specified periodicity, forcing a re-train.
Spot on. I would add that any change to memory timings or voltages forces a retrain as it is assumed modified parameters invalidate previous results and need to be confirmed good.
Just a theory here, but since many are claiming that the training time gets excessively long in max memory configurations, and there is a separate thread about trying to max out memory on AMD systems in ways that violate AMD’s specifications for 4 DIMM installations (a maximum 3600MT/s clock, other settings in regards to UCLK and FCLK limitations) I wonder if the reason this training is taking so excessively long for some people is that they are running things out of spec, and the memory is failing many tests, forcing it to try a large number of settings?
Many people don’t seem to realize that exceeding AMD’s specification on memory clocks and other settings IS overclocking, even if the motherboard and RAM say they support it.
I wonder if these excessively long training times are people:
1.) Running outside of AMD’s specs; and
2.) Using memory that isn’t explicitly on the QVL
There is nothing to say you can’t use memory that isn’t on the QVL, and that you cant tweak it and run it at overclocked settings beyond what AMD officially supports, but if you do, and if you have problems, that is on you.
Yes. When testing anything, you can only change one variable at a time, or you’re not testing, you’re fiddling. All these parameters must be checked and there is a range in which they will or will not function. Once one is found good, training may continue with the next parameters. If no value found, must go back and modify previous assumed good value and re-start previous phase. Long training means the system is struggling to find good signaling parameters and you will end up very marginal, to say the least.
Short training sessions are indicative of a well tuned system. This requires knowledge and understanding of how impedance matching, reflectance, frequency, load, voltage, jitter, and proper data eye shape and placement play into signaling. Overclocking is an art. Too many players think it’s just voltage and frequency.
So, let’s say there are just these 8 parameters. And they all have some degree of interlinked co-dependency, which is generally true as they form a complete “system”. Further, for the sake of discussion, let’s say they all have 16 step values for which can be set. How many combinations in total are there?
C(n,r) = n! / (n-r)! r!
n = number of items in the set
r = number of items selected from the set
n = 8 x 16 = 128
r = 8
C(n,r) = 128! / (128 - 8)! / 8! = 1,429,702,652,400
Whoa. Highly simplified for illustration purposes but we get the idea. Big number bad.
I suspect it’s mainly that BIOSes are badly coded. The DDR training space is well constrained with substantial information available via SPD, with the result levels, timings, terminations, voltages, and whatnot are readily predictable a priori. So it’s very likely a fairly convex and pretty simple multi-start optimization problem. Even if you’re doing single coordinate descent the limited number of steps means the parameter space for local searches isn’t that big. And I don’t know why you wouldn’t do block coordinate descent, stochastic gradient search, BFGS-L, or similar.
But from what’s actually happening I’m guessing AMD isn’t providing a lot of AGESA support and it wouldn’t surprise me if finding someone who wants to program a BIOS and who has a more or less introductory knowledge of optimization is pretty hard. It also looks to me like BIOSes are probably missing optimization basics like giving up on poor candidates and failing to set realistic convergence criteria.
That said, there is a poorly defined contract here about how much work the BIOS should at training time versus how much should be left for 12+ hour memory stability test passes. I think in some ways it’d be ideal if training always got it right, meaning it never let anything unstable through, but that’s incompatible with practical POST times.
Seems to me the whole thing’s gotten overdue for a rethink on mobos supporting overclocks. Like why not post off one channel at JEDEC default to bring up the BIOS UX, display progress while the other channel trains, swap channels, and repeat? That’d let people see what’s going on and you could implement basic stuff like cancel out to SPD defaults or a known good profile.
Moved to ignore as I’m not going to argue about whether a file on a USB stick is a file. Insisting a BIOS update invalidates fan curve control point locations that didn’t move because none of the hardware changed is equally silly.
You basically said the same thing. But to emphasize the key point: It takes longer than expected on AMD consumer platforms, which is why more people have been talking about training and why the MCR feature was added in later AMD BIOSes to alleviate this.
On Intel, DDR5 training seems to be much quicker and has caused no fuss by comparison. Most likely because the memory controller is more capable (or some combination of that and better firmware? idk)
Overruled! (Don’t be mad, I’m just playing with your words.)
How do you know the fan curve control point locations didn’t move? (By move, I mean didn’t move by memory location in BIOS, not that the control values didn’t change.)
We’re not talking about the register addresses for the hardware. We’re talking about stored values in the BIOS image, referenced by address for load.
BIOS modules are added, removed, re-ordered, modified, etc. The starting address for the saved profile is not guaranteed to be the same. You’ll load bad data if the saved profile is allowed to persist when flashing a new image because the new image will make use of a saved profile offset and structure corresponding to it, and not the previous image.
Why is it that the BIOS resets to factory default values when you flash and furthermore the motherboard vendor then goes on to stipulate a best practice is to load default values even after you’ve flashed?
Should a BIOS image flash not flash the whole BIOS, leaving the saved profiles intact? Why or why not? Considering these implications might help to understand why saved profiles cannot persist between differing BIOS versions.
Huh when did I say each boot and my experience contradicts what you just with regards to training time being linked to number of channels not dimm size so whatever.
I also used to think this is normal, since I only had ASUS mobos before.
I have Gigabyte and MSI AM5 motherboards that don’t do that.
You guys keep repeating this, like it is a fact, that it can’t be done.
When in reality others are capable of exactly doing that and proof you wrong.
You should seriously consider buying another brand from time to time. I am no different in that regard.
I used to think that 24Pin CPU cables suck, until I built a Seasonic for a friend and realized “ohh, not all 24Pin suck, that is just a beQuiet thing!”
It is not that hard really. Even Supermicro server boards can do it (but they don’t recommend it).
Either save the settings somewhere else or simply say that the BIOS update should only overwrite a certain part.
What is this?
Fan curve never destroyed on your MSI board after new BIOS version. Or the whole profile is preserved or can be loaded from file saved by previous BIOS version?
I think it’s not MSI, ASUS or other board vendors to blame. It’s Pheonix/Award. I think those guys sitting on their fat arse and have no motivation to improve user experience.
Also at the same time, we don’t want to implement a generic method of carrying profiles across BIOS versions. That might turn into another monster like the ACPI spec.
A limited implementation is still possible and can be quickly done where a profile from a previous BIOS version can be loaded in a new BIOS. I believe it’ll be useful 90% of the time. The other 10% users have to manually enter again.
You will stop using 86 and switch to what ?
I am just curious what did you try and found it to be better alternative desktop ? apple silicon a mac ?
Or maybe arm on windows ?
Neither. A BIOS update does not touch any settings and leaves everything as it is.
Like it should be.
Best solution is done by supermicro. Let the user decide if he wants to keep the settings or not.
On that note, I was negatively surprised that the 10 ASUS boards I have bought are not able to share a single profile from a USB stick.
Interesting. So that puts the settings reset matrix at something like
| ASRock | Asus | Gigabyte | MSI | |
|---|---|---|---|---|
| AM4 | reset | reset | ? | reset |
| AM5 | reset | reset | retain | retain |
I’ve got two Steel Legends to update to 3.40. I’ll have to check if the profiles roam.
Actually, this function is rather simple to implement.
Most business pc work like that. My thinkpad preserve bios settings after the bios update. My Dell Precission 3660 preserve bios settings after the bios update, too.
On custom pc side, I believe leaving this feature out is the results of pure laziness.
Beware: New AM5 BIOS updates add memory training expiration, which may cause longer boot times or retraining after hardware changes or power loss.
I think this is much easier to do on enterprise systems where the manufacturer controls the hardware used, and in an environment where next to no one goes in and tweaks performance related settings.
I don’t think it could work in a consumer industry where many spend countless hours tweaking voltage, clocks and timings to get the most out of them while stable.
It’s a whole different ballpark to keep things like boot settings and system clocks the same after flashing a new bios than it is to keep users custom core clocks, core voltages, memory clocks, memory controller voltages, memory timings, etc. etc. the same when you flash a BIOS, especially when that BIOS changes fundamental behaviors of the silicon, like when a new AGESA is pushed.
Each one of those voltage, clock, or timing settings could behave very differently when there is a new AGESA, especially in our era of performance/clock/voltage curves. This would have been a lot easier in the old days of static settings.