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

[fastboot]

Hi @Franco,

I may have found a microcode packaging/split-file issue on OPNsense.

System:

Protectli VP6630
Intel Core i3-1215U, Alder Lake R0
coreboot 0.9.0

Installed packages:

Code Select Expand

cpu-microcode-intel-20260227
os-cpu-microcode-intel-1.1
Current microcode after boot:

Code Select Expand

x86info -a | grep -i micro
Microcode version: 0x0000000000000432
Boot message:

Code Select Expand

dmesg | grep -i micro
[1] CPU microcode: no matching update found
The package only provides this split file for CPUID 06-9a-04:

Code Select Expand

/usr/local/share/cpucontrol/06-9a-04.40
but for Intel Core Gen12 / Alder Lake R0 I would expect platform 06-9a-04/80, not /40.

Full relevant output:

Code Select Expand

pkg info -x microcode
cpu-microcode-intel-20260227
os-cpu-microcode-intel-1.1

pkg info -l cpu-microcode-intel | grep -E 'intel-ucode|06-9a-04|microcode'
cpu-microcode-intel-20260227:
        /boot/firmware/intel-ucode.bin
        /usr/local/share/cpucontrol/06-9a-04.40

find /usr/local/share/cpucontrol /boot/firmware -iname '*06-9a-04*' -o -iname '*intel*ucode*'
/usr/local/share/cpucontrol/06-9a-04.40
/boot/firmware/intel-ucode.bin



Is it possible that the split microcode file 06-9a-04.80 is missing from the package, so the Intel microcode plugin cannot update this CPU and keeps the firmware-provided 0x432?

Thanks!


FB

[meyergru]

It really looks like this is the case. There should be two more files, namely .10 and .80 if the full binary was split correctly. Under Linux, where full binaries are in use, the file is three times as big as the .40 version. Your CPU should have a 0x43a firmware.

To carry over the correct files is a little complicated, because on boot, intel-ucode.bin is used and that lacks the relevant parts as well.

You should probably create a bug report for FreeBSD.

[Greg_E]

Due to availability and tariffs, I'm looking at a similar Protectli device, so watching this.

[BrandyWine]

Lets look at:

cpucontrol -i 0 /dev/cpuctl0

grep microcode /boot/loader.conf

sysctl hw.model

[meyergru]

And then what? I already verified that CPU to use the 06-9a-04.80 variant under linux with the current firmware version at 0x43a.

As I said, the single-type files in FreeBSD contain only one subtype of each man type (like 06-9a-04) with ~100000 bytes, whereas the single files in Linux have all in one (so .10, .40 and .80 for this type 06-9a-04) with ~300000 bytes. For some other types, you can actually see that there multiple subtypes for some other types in FreeBSD.

That being said, the "full" file intel-ucode.bin on Linux is also much larger than the FreeBSD one, so I would argue that the subtypes .10 and .80 were forgotten in the FreeBSD packaging.

[BrandyWine]

So, online docs do mention .40 does cover some versions of that CPU.
I think the missing .80 is already documented.


But, what's installed (full list)?
ls -al /usr/local/share/cpucontrol/*-*-*.*

But yep, looks like .80 went missing

Why .80 isn't in FreeBSD 14's package
The FreeBSD 14 package cpu-microcode-intel-20260227 includes only .40 for 06-9a-04
.80 platform mask exists on some Alder Lake desktop CPUs (like yours) but was not included in the packaged blobs at the time
This is a known coverage gap / erratum in FreeBSD 14's Intel microcode package (see PR 268584 / PR 268975)


Options if you want .80 applied
Manually extract Intel's .80 microcode from the Linux microcode repository:
Repository: Intel Linux Microcode
Find the blob for 06-9a-04.80
Place it in /usr/local/share/cpucontrol/ and reboot

[meyergru]

That will probably not cut it, as I already said: For the boot phase, the intel-ucode.bin ist used. Only for the user-space (later phase) does cpucontrol use the single files. Therefore, I am unsure what procedure could be used. If cou wated to be safe, I would use the 300000 byte file from Linux and name than .80, plus I would copy the Linux intel-ucode.bin.

AFAIU, the tools will extract whatever they need from the files, so strictly speaking, you do not need the single files, but that I do not know for sure, so I would not risk to break anything going forward and leave it to the experts. The best way to proceed is probably to wait for FreeBSD to fix it - it there already is a bug report, then fine.

[BrandyWine]

Something perhaps relevant on org site.
https://forums.freebsd.org/threads/cpu-microcode-not-updated-during-boot.95641/


Having proper uCode is interesting, for some cpu, for other reasons too.

https://forum.opnsense.org/index.php?topic=48343.0

https://lists.freebsd.org/archives/freebsd-current/2025-January/006984.html

But at this writing it's unclear to me where the issues and fixes are at.