Intel Raptor Lake voltage problem

I think you should post your source for where Intel said the microcode changed the temperature readout. And then I think you should post where you're getting your information about how microcode updates work.
Ugh, so I went through about a hundred documents when this story first broke, and I swear I found something about the eTVB bug including a misreport of a thermal junction temperature which permitted the overvoltage. I can't find it now, at least partially because "intel" "eTVB" "temp" search terms in Google come up with about one hojillion hits versus what it came up with two months ago. Bleh. I wish I would've just posted the link. So, for now, I suppose take it with a grain of salt? I'll keep looking.

The firmware / microcode thing is old BIOS workstation admin knowledge. Intel CPU microcode goes hand-in-hand with the Intel Management Engine firmware. If you've got Windows and a modern-ish Intel processor, you'll find the Intel Management Engine drivers are what expose the microcode update path in Windows -- Microsoft's own driver repository provides the IME drivers to make life easier, but you can trace it via the provided INF file. The IME firmware is disconnected from the BIOS in a general sense, however it can all be bundled together in the same flash file to simplify an end-user's life. If you've ever done firmware upgrades OTA via Windows, you've probably dealt with the discrete update modules of the IME and the CPU microcode.

All that to say, in my experience the motherboard firmware can usually be rolled back (modern boards are better at this than older ones) however this doesn't automagically always roll back the IME firmware, which is also linked to the CPU microcode. The overall behavior would be unique to the manufacturer of the BIOS update tool; Intel provides mechanisms to do this work as I mentioned in my prior post. If whoever wrote the BIOS upgrade (downgrade...) utility wanted to, there's no reason they couldn't write the additional logic to roll back multiple firmware images in a single command.
 
I'm pretty confident there's no such temperature readout issue, as you and this thread is the only place I've heard it or can find through google.

In regards to the microcode update, my understanding is that it's something that's applied on each and every startup of the system. There's no nonvolatile store for it on the CPU itself; it's just a bank of SRAM that gets populated. As such I'm squeamish of even using the term "downgrade", as it implies something on the CPU is being changed in a persistent way. Maybe there'd be some potential issue with compatibility between the microcode version, the ME, and the OS; but I don't see any evidence of that in this case where we're talking about jumping between 0x123, 0x125, 0x129, 0x12B all released in the span of a handful of months (the ME firmware version hasn't changed across those BIOS+ucode releases, at least for MSI.)

 
Last edited:
At this point, we know those microcode versions are all interoperable on the same CPU sets anyway, so I wouldn't forsee any specific problems with upgrading and downgrading. We also know the various microcode versions aren't cumulative, so skipping straight to the 0x12B means you'll get all four fixes.

I know every CPU has a Microcode ROM component which can never be updated; I believe newer versions of microcode updates are stored in a sort of EEPROM state however I know there are versions (I was under the impression these are older CPUs) which had a RAM region for storing microcode patches, which were refreshed as you describe. Here's a cool paper that briefly touches on the microcode patching via patch ram embedded into the CPU here: https://misc0110.net/files/cpu_woot23.pdf Most of the paper is actually about reverse engineering Intel microcode and microcode patches for Intel Goldmont (Atom processors built circa 2016.)
 
No, the CPU is not being flashed. It's loading a config file on startup. The motherboard in this case is what's being flashed to store the new config file.
 
I could go in the back and flash a CPU right now. I'd have to turn off the cameras so nobody reports me to HR but I could do it. It would take a while though since these pants have double buttons.
 
I could go in the back and flash a CPU right now. I'd have to turn off the cameras so nobody reports me to HR but I could do it. It would take a while though since these pants have double buttons.

Removing the heatsink and thermal paste could take a while too, right?
 
Back
Top