cpu-microcode-intel: no matching update found on Intel Core i3-1215U

[BrandyWine]

I guess I would also do more digging on coreboot, because the more I look the more it sounds like more digging is needed, even if the bug list is indicating an issue.

If coreboot already applied the .40 then should we expect another load at OS level to fail? Perhaps yes?

Coreboot itself doesn't ship a fixed universal Intel microcode set — microcode blobs are added per‑board/ROM build. Whether a specific coreboot 0.9.0 ROM includes Intel microcode depends on the build/image you have:

    Official/coreboot project builds or vendor images commonly include the intel microcode blob (from the intel-microcode repo) in the ROM.
    Some distributions or projects (e.g., Libreboot/no‑microcode variants) intentionally remove those blobs.
    You can check a ROM with cbfstool: cbfstool <romfile> ls and look for entries like cpu_microcode_blob.bin or inspect coreboot's build config (BOARD//config) for CONFIG_INTEL_MICROCODE.

[fastboot]

Not every thread warrants a comment

Rest assured the firmware updates will be coming once they're available for FreeBSD

Awesome.

Good catch regarding the mobile vs desktop R0 variants. You are right, the i3-1215U is a mobile Alder Lake R0 CPU, so .40 should indeed be the correct platform variant, not .80.

So my original assumption about a missing .80 blob was likely wrong.

However, the interesting part still seems to be:

dmesg:
CPU microcode: no matching update found

combined with:

• installed cpu-microcode-intel package
• stale-looking revision 0x432
• newer revisions apparently existing upstream/Linux side

So there still appears to be some kind of matching/loading issue on this platform, even if the root cause is not the missing .80 variant.

I have opened a FreeBSD bug report for further investigation:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

You missed my other point. Did you 100% verify that your device has the exact CPU that is stated on the box, or did they somehow solder in a "desktop" variant.

On the working group page (https://reviews.freebsd.org/D57046), they call out affected cpu families, but the Alder Lake R0 is not named. And, if I am reading it right, it looks like the .40 is not being fixed in any way, but it does look like a fix for the missing .80 is there. So I am still curious.

Also possible, the coders flipped over .40's and .80's, perhaps they mapped the mobile variant to the .80 file and the desktop variant to the .40 file. A possibility that could explain what you are seeing. Or, my info regarding .40 for mobile and .80 for desktop was wrong, but if you go looking you should find same info as I did.

I only happen to know a bit about microcode updates in general. It was obvious that it was a packaging error in FreeBSD, because I happen to have a system based on an i5-1235U from the same family and I know that the current firmware version for that family is 0x43a when updated under Linux.

Your applied ucode is a .80, for a 1235U ?

You are correct that Alder Lake R0 is not explicitly listed in the review text itself, only "and others".

However, the proposed fix is directly linked to PR 295351, which is my report, so upstream FreeBSD at least seems to consider it related.

The fix itself is also fairly generic. It changes how ucode-split handles Intel extended signature tables, rather than adding handling for one specific CPU family.

So at this point I think the more important question is probably not whether the visible primary split file is .40 or .80, but whether the relevant signature/platform combination for this CPU is only present in the extended table and therefore currently ignored by ucode-split.

That would also match the observed symptom quite well:

CPU microcode: no matching update found

So I agree it is not fully proven yet that this specifically fixes Alder Lake R0, but the upstream patch and PR linkage make it look very plausible.