Arrow Lake Retested with Latest 24H2 Updates and 0x114 Microcode

[phanbuey]

In an era where 3D cache and memory latency are dominating, Intel's big move seems to have been to put the memory controller on the other side of the processor away from the die.

 

[efikkan]

Very true, the hardware is present, and there are ways to make code with AVX512 instructions not crash on an E core. Maybe MS didn't want to implement, test and support that.

There have been some talk about a software solution to stall threads and move them, but it's probably too optimistic to expect the OS to handle that reliably.
I find it so ridiculous that Intel went ahead and designed this hardware without a proper plan for the most obvious problem. And they could easily have solved it in hardware, have the E-cores use a "double-pumped" version like Zen 4 did, it wouldn't require a lot of extra transistors.

Refining? You mean (potential) security improvements? Because performance wise, the 32-bit mode has been more than good enough for the longest time.
Besides, Intel has just cancelled the X86S project.

They have replaced their x86S project with the x86 ecosystem advisory group, and the effort is expanded, not stopped.
There is also the work with AVX10, hopefully that will be cleaned up in the end.

What kind of security issues on ISA level are you thinking about?

 

[FreezingPC]

Surprisingly they still haven't appreciably dropped the pricing of it much since launch...

Not like they could do such thing, at least, not to the same extent has AMD...

 

[Mr_Engineer]

It's more than clear that Tom's Hardware was right about Arrow Lake suffering from a hardware flaw. Moving memory controller out of compute tile imposes 20-25ns memory penalty and mixing P/E cores (to improve temps) increases L3 cache latency. AMD chiplets handle memory latency better, but not frequencies. Now imagine performance boost that AMD could achieve by moving IMC into tile with cores along with releasing new improved IOD. I'd say Zen 6 does not require any significant changes to core architecture (as introduced with Zen 4 vs. Zen 5) to increase performance, only changes to IMC location and IOD bandwidth are required.

Also, AMD should not drop SMT, as it is delivers much more performance than Intel's HT and produces no power draw increase.

Agreed. I do believe that the new tiled approach that Intel used, while practical, especially when building smaller and larger CPUs, is the main cause of the degraded ARL performance.

Even Zen 5 does suffer from the old IOD/IMC that was reused from Zen 4. But AMD has more experience using tiles, and they made up for a that by having a higher bandwidth cache subsystem, and the much larger L3 cache (on x3d parts).

For Zen 6 (Desktop) I do think that AMD will keep the same IOD/IMC approach but with a:
1. Monolithic 16-Core CCD (2/3nm) and (4nm) IOD/IMC/RDNA3-4. Of course they can add more CCDs for higher end models/Threadripper/Epyc server CPUs etc.
2. All Zen 6 desktop CPUs would have L3 V-Cache (below the CCD tile). And larger L1/L2 on the CCD tile.
a. This approach means that all 16 cores share the same large L3 V-Cache pool (probably at least 128MB)
b. The large V-Cache somewhat mitigates the latency caused by the IOD/IMC being on a separate tile
c. More efficient, practical, and higher performance as all cores share the same L3 cache (no need to worry about which CCD has the V-Cache)
d. AMD can disable some cores/cache for lower SKUs. Example, the same die with 12 cores and 96mb L3 cache, 8 cores and 64mb L3 etc

These are just guesses from my side, but it seems like a good approach that AMD could take.

 

[Talon]

Attached here, if that helps. The exe is digitally signed by Intel, and I doubt the ME files will flash if they have been tampered with


Didn't test, no time and no point given these minimal differences

I don't think that is the correct ME version. It's 1854, but you need 1854v2.2. Asus rep stated "Phase 2" beta BIOS will be rolling out soon. 1203 and that version of 1854 ain't it.

 

[W1zzard]

I don't think that is the correct ME version. It's 1854, but you need 1854v2.2. Asus rep stated "Phase 2" beta BIOS will be rolling out soon. 1203 and that version of 1854 ain't it.

Aha.. thanks. guess we’ll wait a bit longer for this update then… do you have a link by any chance?

 

[Talon]

Aha.. thanks. guess we’ll wait a bit longer for this update then… do you have a link by any chance?

Overclocking "Arrow Lake" - 285K, 265k, 245k...

www.overclock.net

Hopefully soon before they shut off the lights for holidays.

 

[HueSplat]

I don't think that is the correct ME version. It's 1854, but you need 1854v2.2. Asus rep stated "Phase 2" beta BIOS will be rolling out soon. 1203 and that version of 1854 ain't it.

Let me add to the confusion, ME firmware is a group of firmwares packaged together, hence it being referred to as a firmware kit by Intel.
I wish they would just show the full firmware list or changelog, what is V2.2? is the update package on the Asus ROG forums already V2.2 or newer?

I could be wrong but AFAIK the main firmware version will just show 19.0.0.1854 no matter if its "v1.0" or "v2.2", I believe that is how it was in older ME versions.

Spoiler: Current ME firmware on ROG forum

Firmware : 19.0.0.1854 [27/11/2024]
PMC Firmware : 1900.21.0.1054
PCHC Firmware : 1900.21.0.1009
SOCC Firmware : 1900.25.0.1009
ACE Firmware : 20.40.1483.0
PHY S Firmware : 13.0.1.7093
PHY N Firmware : 19.2.0.7014
IOM Firmware : 49.20.0.0
TBT Firmware : 19.0.0.1301

Aha.. thanks. guess we’ll wait a bit longer for this update then… do you have a link by any chance?

@W1zzard Source is Intel itself by looks, probably using the wording field/phase interchangeably. https://community.intel.com/t5/Blog...re-Ultra-200S-Series-Performance/post/1650490

This fifth and final category of performance update requires a new firmware image that is currently undergoing Intel validation prior to customer release. We expect user-facing BIOSes to be released in the first half of January 2025. Exact availability will depend on the test and release schedule for your specific motherboard. The correct BIOSes will be identified with Intel microcode version 0x114 and Intel CSME Firmware Kit 19.0.0.1854v2.2 (or newer).

And old mate Hallock

 

[blu3dragon]

So basically the combination of everything fixed performance on 24H2 so that is is no longer slower than 23H2.

That's good, and was needed, but obviously does not fix the regression in gaming performance from 14th Gen.

 

[Dawora]

i did buy Intel usualy, even now 13xxx and 14xxx series are great and 13900/14900 are still intel flagship models so very good deal if bought one.

This Ultra series just sux, i sometimes play 1080p mode(med/high settings) and i like to get around 200fps thats not hapenin if using new intel Cpus.
Also Ultra series is overprice

 

[Max Mojo]

@HueSplat
You seem to be part of the ROG Forum as well. Maybe our forums should merge as like posted in the updated thread a lot of information is already here:
https://rog-forum.asus.com/t5/intel-800-series/arrowlake-resources/td-p/1051570/page/14
And what 'Hallock' concerns I could not listen to him any longer than 1 minute. It's similiar to the experts of Intel Forum. They never answer a question but are always very thankful for asking.
So all in all there is no gain in upgrading what is not that regrettable.

 

[Talon]

i did buy Intel usualy, even now 13xxx and 14xxx series are great and 13900/14900 are still intel flagship models so very good deal if bought one.

This Ultra series just sux, i sometimes play 1080p mode(med/high settings) and i like to get around 200fps thats not hapenin if using new intel Cpus.
Also Ultra series is overprice

What game?

 

[Max Mojo]

So if this is true no need to defect:
https://hardforum.com/threads/most-...ng-benchmarks-but-i-found-some.2037755/page-8

 

[raysinbisket]

Doesn't the fact that Intel is matching/beating the 9950X with fewer threads prove the fact that having smaller, carefully designed single-threaded cores provides better results than bigger cores with SMT in fully multi-threaded workloads? Which is exactly my point? Adding little cores that take up less space and power is the way to go for multi-core workloads, and everyone agrees. Yes, AMD still has the same core architecture and HT in their little cores for now, but Intel's showing obvious advantages in changing that by having superior IPC.

And for Intel having to run Windows, you completely ignored my point that Zen had THESE EXACT SAME issues. Radically new CPU architecture provided outstanding multi-thread performance by boosting core count with the dual-CCD design, but faced lots of issues with Windows and apps and games not knowing how to handle thread assignment. Exact same issues Intel is facing now. And those issues haven't even been fully solved yet. As I pointed out, even the Zen 5 launch was compromised by Windows not handling the new architecture properly because 24H2 is trash.

But in hindsight, AMD absolutely made the right choice with Zen and the chiplet design. And in 8 years, I'm sure we're going to look back at 12th gen and Core Ultra and say the same thing about e-cores and removing SMT.

And once again you're missing the point. Sigh.

I'm struggling to see the point you're trying to make? That having more (24) cores perform roughly the same as 33% less (16) is meant to be impressive somehow?

You never remotely addressed my flipping of the statement to talking about cores, and again chose to focus on threads.

For starters, you're comparing E-cores to SMT, which these are not mutually exclusive concepts - they can coexist. Secondly, SMT provides good MT value for die space area, something even Intel discussed when announcing Arrow Lake despite it not having it. SMT largely reuses existing core hardware to implement a second thread, the additional footprint of SMT isn't massive - plus you're more likely to maximise core resource utilisation under SMT. Whereas, adding an E-core is literally just adding an entire extra core.

An SMT thread may not be as strong as an E-core thread, but it also correspondingly takes up much less area than an E-core.

The only sensible justification for removal of SMT/HT from the P-core is if removing it enables optimisation of the architecture which results in better ST, which to be fair I do think we see in ARL.

I don't think anyone is disputing that having high performance and low power/area cores is the way to go, just that Intel has jumped the gun with a solution that Windows isn't designed to take full advantage of.

Plus, Intel's P-cores are so big they literally need E-cores to compete with AMD at all. AMDs standard cores are already reasonably sized, the c cores more so.

The fact that we may end up with a solution in "8 years" that aligns to Intel's approach doesn't change the pitfalls of Intel's approach now.

 

[TechBuyingHavoc]

Honestly, I feel like Intel is getting too much flak for Arrow Lake. While they obviously need to improve things like thread assignment with the new architecture, I feel like most of the blame needs to be assigned to Microsoft. 24H2 is absolutely broken in every single way. Every day a new article comes out about how 24H2 broke a certain feature, or gaming performance, or a software. I work in IT, and we've had to roll back 24H2 on multiple computers because it breaks multiple unrelated pieces of software that are absolutely business-critical for us, so it's not just an issue with a single feature or part of Windows.

I'm very bullish on Intel overall, even with Arrow Lake. The big-little architecture was absolutely the right move for consumers (which AMD immediately copied), they've adopted the chiplet design after seeing how well it worked for AMD (and let AMD handle much of the "teething issues), and they've moving to drop native support for x86, which I think will pair very nicely with moving to single-threaded cores and allow them to simplify core design immensely.

The key concept here is goodwill. Intel has squandered years of goodwill with stagnant products, bad pricing, and a lot of security and quality issues. No one is willing to give Intel a pass anymore. You notice that when AMD has a software issue with Microsoft, AMD usually gets the benefit of the doubt. It is because AMD has more goodwill vs Intel with their Zen products.

Also, I don't let Intel off the hook here. Microsoft has been messing up their software for years now, Intel should have taken this into account either during the product planning process or in the QA process working with Microsoft. The truth is that Intel took some risky business bets, pushed their release ahead in spite of technical issues and problems to meet a marketing deadline, and it all blew up in their face.

Yeah, Intel deserves all the blame it is getting. That is not to excuse Microsoft's incompetence here in any way.

 

[raysinbisket]

The key concept here is goodwill. Intel has squandered years of goodwill with stagnant products, bad pricing, and a lot of security and quality issues. No one is willing to give Intel a pass anymore. You notice that when AMD has a software issue with Microsoft, AMD usually gets the benefit of the doubt. It is because AMD has more goodwill vs Intel with their Zen products.

Also, I don't let Intel off the hook here. Microsoft has been messing up their software for years now, Intel should have taken this into account either during the product planning process or in the QA process working with Microsoft. The truth is that Intel took some risky business bets, pushed their release ahead in spite of technical issues and problems to meet a marketing deadline, and it all blew up in their face.

Yeah, Intel deserves all the blame it is getting. That is not to excuse Microsoft's incompetence here in any way.

Also some of the Microsoft related issues were caused by Intel literally setting the go-live date for Windows Updates for Arrow Lake to the consumer launch date rather than a week earlier for reviewers...

 

[notoperable]

Public traded corporate body and "goodwill", you sure you teleported into the right Universe?

 

[_roman_]

There have been some talk about a software solution to stall threads and move them, but it's probably too optimistic to expect the OS to handle that reliably.

My opinion: That is the part the scheduler has to do for the kernel. the linux kernel has many changes to that part. A kernel is a part of the operating system.
Months ago I wanted to find specs for those E-Cores. There are none. I just wanted to know which code they can execute and which they can not. From the viewpoint of cpu instructions. I stick to the claim - those E-Cores will not be able to execute my code. If I want to run optimised general purpose i686 code from year ~1995 I can use windows 11 also (please look up when i686 went public ...).

 

[TechBuyingHavoc]

Public traded corporate body and "goodwill", you sure you teleported into the right Universe?

A reply to a post complaining about too much flak going towards a company that mentions goodwill? Yeah, you bet I am in the right universe.

 

[efikkan]

My opinion: That is the part the scheduler has to do for the kernel. the linux kernel has many changes to that part. A kernel is a part of the operating system.

It's not like the scheduler sees what instructions lies ahead, nor which one is executing at this moment. The suggestion I saw mentioned after Alder Lake released was using some kind of detection in the core, stall it, and let the scheduler request to move it. I don't remember the name of the feature, but if its accurate, then it probably didn't work reliably, considering Alder Lake did actually release with AVX-512 enabled you know.

The only software solution I can come up with that would be reliable would be to analyze the binary at launch and scan every page of code for unsupported opcodes, and if so flag the binary for P-core only. But this would probably add a few ms to the launch of any binary, which would lead to horrible performance when launching applications and doing calls to libraries, even with some kind of cache.

Months ago I wanted to find specs for those E-Cores. There are none. I just wanted to know which code they can execute and which they can not. From the viewpoint of cpu instructions.

Have you looked up the Intel® 64 and IA-32 Architectures Optimization Reference Manual?
If there are things developers need to know about Intel archtectures, it should be listed there.

I stick to the claim - those E-Cores will not be able to execute my code. If I want to run optimised general purpose i686 code from year ~1995 I can use windows 11 also (please look up when i686 went public ...).

I'm under the impression that E-cores will run anything except AVX-512 that Alder Lake supports, you can see the compiler targets that Intel themselves have added for GCC. Whether the code runs on E-cores or P-cores should be transparent to the developer.

If you happen to find any information that suggest otherwise, please let me know. I will eventually be getting one of these CPUs myself for the sole purpose of making sure my software detects cores/threads correctly and scale appropriately.

 

[Wirko]

There have been some talk about a software solution to stall threads and move them, but it's probably too optimistic to expect the OS to handle that reliably.

That, or software emulation of non-existent machine code instructions. The Linux community (that Intel is an important member of) could implement that. MS ... not so sure.

I find it so ridiculous that Intel went ahead and designed this hardware without a proper plan for the most obvious problem. And they could easily have solved it in hardware, have the E-cores use a "double-pumped" version like Zen 4 did, it wouldn't require a lot of extra transistors.

Or quad-pumped or anything that's cheapest to make. If the goal is compatibility, not performance, then any kind of performance above zero is acceptable.

They have replaced their x86S project with the x86 ecosystem advisory group, and the effort is expanded, not stopped.

No, these are two different things.
X86S = how can we make the 32-bit parts a little bit leaner (Intel only)
Advisory group = how can we still extract money from our IP when our most important patents expire (Intel and AMD, and I'm not sure what others are doing here)

What kind of security issues on ISA level are you thinking about?

Nothing specific, but 32-bit boot mode/protected mode/ring-0 is an attack surface that X86S would remove. These capabilities also have to be integrated into every new architecture, which is a process that can create new security cracks.

There's another thread about X86S currently alive on TPU:

Intel proposes x86-S, a redux of the x86 architecture

I don't think the people who decide on this drastic change care about old games. Far more important is legacy code of industry/financial services and military. These types of large organizations need to know if their code can run on new hardware in case of expansion, replacement or tech...

www.techpowerup.com

 

[negfuz]

Hello - I have a few questions for the clearly more techy folks here please.

On the z890 AsRock Aqua download page - https://www.asrock.com/mb/Intel/Z890 Taichi AQUA/Specification.asp#BIOS it says microcode 0x114 and New Intel ME version (but doesn't say which) ?
I know Hallock's updated stream said the "new toolkit" will come in January but I cant seem to nail down which one is even on this bios
More confusingly - if you switch from the BIOS page to their download page, I can't even seem to match any of their Intel ME versions? For example there they have: "Intel Management Engine driver ver:2435.6.36.0_CONS" released on Nov 11... ?

So first question is primarily to know for sure when the "Firmware CSME Kit from January" is live (for this board) so that I know the Combo of 0x114 + this now is fixed as much as it can be.


My second question is extremely niche. Currently have a 13900k. I also have a Brand new 285k sitting (awaiting the fix with the above z890 Aqua Asrock board), along with a R9-9950x sitting (awaiting my indecisiveness).

I play primarily in (DQHD) 5120x1440 or (DUHD) 7680x2160 on a 4090, a resolution where the game is not bottlenecked by the CPU anyways. So I'm not too concerned about benchmarks showing a 5-10% performance regression in 1080p benchmarks as they're kind of meaningless. What I genuinely am more concerned about is the power draw as the computer room is small and heats up pretty fast (13900k doesn't help - obviously). This isn't only a gaming PC so the 7800x3d and 9800x3d are out of the question due to not high performing enough for other workflows. So with that said, if my primary concern is reducing the heat output while getting as much "power" as possible. The 285K takes the crown right? I seem to have difficulty finding metrics such as FRAMES PER WATT or something like that to confirm this guess, particularly from the current fixes (not looking at Launch benchmarks as they were obviously flawed with all the PPM and Balance power mode and stuff not working, which would have skewed results).

Even some of those YouTube benchmark videos where they test like 5 games side by side showing me the current FPS along with the CPU power draw would let me make my own conclusions, but again, don't want launch date data, because obviously there have been fixes since then.

On the other hand, I know the 9950X doesnt pull as much power as the 13900k, but it's still up there, so switching over might not yield the big boost I'm thinking of for my specific needs.

I'm not too concerned with "Future Upgrade Path" so I'm not really factoring that into the choice. Just trying to gauge based on the above (the lower heat output, while still getting the best bang for the power draw in multi workloads (not just gaming) - what the better processor would be. And yes, I'm aware the 9950X3D may be coming out in the near future. Trying to compare the 13900k vs 285k vs 9950X only.

Thanks for any insight all you super tech bros can provide!

 

[HueSplat]

@W1zzard MoKiChU has added a little more detail on their ME firmware on the ROG forum.

Re: [FIRMWARE] Intel ME (Z890)

Hi, v2.2 is an Intel release versioning, this only indicates sub-firmware update and/or Intel SSE (Silicon Security Engine) plugin sub-firmware (knowing that I do not show you the Intel SSE plugin sub-firmwares usually in the thread/update post which are also updated over the versions) since the...

rog-forum.asus.com

Hi,

v2.2 is an Intel release versioning, this only indicates sub-firmware update and/or Intel SSE (Silicon Security Engine) plugin sub-firmware (knowing that I do not show you the Intel SSE plugin sub-firmwares usually in the thread/update post which are also updated over the versions) since the initial 19.0.0.1854 release (so v1.0).

The version I offer in my thread is the most recent to date available for the motherboards manufacturers with the PR5 Kit (Planning Release 5), I cannot tell you which Intel release versioning it corresponds to or if Intel plans another update of the sub-firmwares and/or the SSE plugin sub-firmwares by January 2025 (but don't expect any improvement with a sub-firmware update, only bug fixes). I myself offered 2 different versions of 19.0.0.1854 in my thread (in red the updated sub-firmware/SSE plugin sub-firmware) :

First one (which does not necessarily correspond to version 1.0 according to Intel versioning) :

- Intel ME Consumer Firmware :
Firmware : 19.0.0.1854 [27/11/2024]
PMC Firmware : 1900.21.0.1054
PCHC Firmware : 1900.21.0.1009
SOCC Firmware : 1900.25.0.1008
ACE Firmware : 20.40.1483.0
PHY S Firmware : 13.0.1.7093
PHY N Firmware : 19.2.0.7014
IOM Firmware : 49.20.0.0
TBT Firmware : 19.0.0.1301
ESEP SSE Firmware : 1100.0.0.1823
DMUP SSE Firmware : 33313.49.0.17296
PUNIT SSE Firmware : 545.49.0.17296
SOC SSE Firmware : 1001.0.0.1812
SOC PMC SSE Firmware : 1900.25.0.1055
SOC PHY S SSE Firmware : 19.2.0.7034

Last one (current) :
- Intel ME Consumer Firmware :
Firmware : 19.0.0.1854 [27/11/2024]
PMC Firmware : 1900.21.0.1054
PCHC Firmware : 1900.21.0.1009
SOCC Firmware : 1900.25.0.1009
ACE Firmware : 20.40.1483.0
PHY S Firmware : 13.0.1.7093
PHY N Firmware : 19.2.0.7014
IOM Firmware : 49.20.0.0
TBT Firmware : 19.0.0.1301
ESEP SSE Firmware : 1100.0.0.1823
DMUP SSE Firmware : 33313.63.0.17536
PUNIT SSE Firmware : 545.63.0.17536
SOC SSE Firmware : 1001.0.0.1812
SOC PMC SSE Firmware : 1900.25.0.1055
SOC PHY S SSE Firmware : 19.2.0.7034

 

[Launcestonian]

Hello - I have a few questions for the clearly more techy folks here please.

On the z890 AsRock Aqua download page - https://www.asrock.com/mb/Intel/Z890 Taichi AQUA/Specification.asp#BIOS it says microcode 0x114 and New Intel ME version (but doesn't say which) ?
I know Hallock's updated stream said the "new toolkit" will come in January but I cant seem to nail down which one is even on this bios
More confusingly - if you switch from the BIOS page to their download page, I can't even seem to match any of their Intel ME versions? For example there they have: "Intel Management Engine driver ver:2435.6.36.0_CONS" released on Nov 11... ?

So first question is primarily to know for sure when the "Firmware CSME Kit from January" is live (for this board) so that I know the Combo of 0x114 + this now is fixed as much as it can be.


My second question is extremely niche. Currently have a 13900k. I also have a Brand new 285k sitting (awaiting the fix with the above z890 Aqua Asrock board), along with a R9-9950x sitting (awaiting my indecisiveness).

I play primarily in (DQHD) 5120x1440 or (DUHD) 7680x2160 on a 4090, a resolution where the game is not bottlenecked by the CPU anyways. So I'm not too concerned about benchmarks showing a 5-10% performance regression in 1080p benchmarks as they're kind of meaningless. What I genuinely am more concerned about is the power draw as the computer room is small and heats up pretty fast (13900k doesn't help - obviously). This isn't only a gaming PC so the 7800x3d and 9800x3d are out of the question due to not high performing enough for other workflows. So with that said, if my primary concern is reducing the heat output while getting as much "power" as possible. The 285K takes the crown right? I seem to have difficulty finding metrics such as FRAMES PER WATT or something like that to confirm this guess, particularly from the current fixes (not looking at Launch benchmarks as they were obviously flawed with all the PPM and Balance power mode and stuff not working, which would have skewed results).

Even some of those YouTube benchmark videos where they test like 5 games side by side showing me the current FPS along with the CPU power draw would let me make my own conclusions, but again, don't want launch date data, because obviously there have been fixes since then.

On the other hand, I know the 9950X doesnt pull as much power as the 13900k, but it's still up there, so switching over might not yield the big boost I'm thinking of for my specific needs.

I'm not too concerned with "Future Upgrade Path" so I'm not really factoring that into the choice. Just trying to gauge based on the above (the lower heat output, while still getting the best bang for the power draw in multi workloads (not just gaming) - what the better processor would be. And yes, I'm aware the 9950X3D may be coming out in the near future. Trying to compare the 13900k vs 285k vs 9950X only.

Thanks for any insight all you super tech bros can provide!

In response to your first question - you'll have to wait for those who are into the finer techicalites of Intel firmware to answer as I'm only aware of the AMD side of things more.
To your second question - because you play at very high resolutions & need the rig for tasks apart from gaming, my suggestion is to go with the Ryzen 9 9950X with the precision boost overdrive maxed out to whatever level it can be proven to be stable with & that is with a negative offset on the voltage curve in order to reduce heat & power consumption. Of course that will depend on the silicon lottery & what you have in its capability here, but no one knows that until actual testing is done. Performance can be further improved by adjusting the FLCK value beyond stock & with a good RAM configuration applied as well. Other variables come into play here though when those other 2 factors are in the mix because of the various combos of motherboard, RAM kits & agesa releases.

 

[HueSplat]

Hello - I have a few questions for the clearly more techy folks here please.

On the z890 AsRock Aqua download page - https://www.asrock.com/mb/Intel/Z890 Taichi AQUA/Specification.asp#BIOS it says microcode 0x114 and New Intel ME version (but doesn't say which) ?
I know Hallock's updated stream said the "new toolkit" will come in January but I cant seem to nail down which one is even on this bios
More confusingly - if you switch from the BIOS page to their download page, I can't even seem to match any of their Intel ME versions? For example there they have: "Intel Management Engine driver ver:2435.6.36.0_CONS" released on Nov 11... ?

So first question is primarily to know for sure when the "Firmware CSME Kit from January" is live (for this board) so that I know the Combo of 0x114 + this now is fixed as much as it can be.

This is the frustrating part, it may be easier to think of the firmware kit Hallock mentioned as a source a manufacturer can build an ME firmware from, if the current 19.0.0.1854 is not "Kit V2.2" even when the "19.0.0.1854V2.2" releases it will still report "19.0.0.1854" in software checks as the actual main ME firmware remains the same, only the sub-firmwares change. See my above post for more info.

The Management Engine driver versions are completely different to the firmware versions, I have not seen a specific driver mentioned as being required YET. Best to keep an eye on it and update it whenever updates are available from the manufacturer.

Spoiler: The latest ME driver pack or bundle I know of is on the ROG forums

The "ME driver" is usually a driver pack, the version number is usually an installer or package version and not the actual driver version.
See below for an example:

ROG FORUM Intel MEI Drivers (Drivers Only) :
Drivers : 2433.6.3.0 WHQL [15/08/2024]
DAL SoftwareComponent Driver : 1.46.2024.221 WHQL [31/03/2024]
ICLS SoftwareComponent Driver : 1.74.210.0 WHQL [01/08/2024]
WMI SoftwareComponent Driver : 2436.6.5.0 WHQL [03/09/2024]

ASROCK VERSION: 2435.6.36.0_CONS
MEI: 2433.6.3.0 [15/08/2024]
DAL: 1.46.2024.0221 [31/03/2024]
ICLS: 1.74.210.0 [01/08/2024]
WMI: 2428.6.4.0 [10/07/2024]

ANYWAY, with the Z890 Aqua 2.26.AS02 [Beta], it contains microcode 114 and ME firmware 19.0.0.1854, no way to tell if this is "Kit V2.2" or older or newer, I'll say older.

To answer your first question, you will know for sure when its live by Asrock mentioning it on their download page or some other update, I expect once the bios leaves beta.
However, it would also be best to wait for Intel's update or "Field Update 2 Of 2" to be completely certain.