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.

[BrandyWine]

@fastboot
Your 1st post looks like you went looking for ucode w/o 1st verifying the actual cpu you have.
My suspicion is, UEFI already applied ucode. What's the date of the UEFI?

Is it possible that the split microcode file 06-9a-04.80 is missing from the package

100% is missing from the package !

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

Not 100% true. The R0 "mobile" variant is a .40, while the R0 "desktop" variant is a .80

The Intel Core i3-1215U, Alder Lake R0 is a mobile cpu, so the .40 should be correct one.

Conclusion
Intel Core i3-1215U (Alder Lake R0) is a mobile CPU, so its microcode variant is .40.
.80 variants are desktop-only and do not apply.

sysctl -a | grep hw.model
sysctl -a | grep hw.cpuid

# Install cpuid tool if you don't have it
pkg install cpuid
# Check your CPU's full CPUID
cpuid | grep -i "family\|model\|stepping"

Protectli VP6630 UEFI specifics
Based on reports and Protectli firmware docs:
The default UEFI firmware does include some Intel microcode, usually matching the R0 stepping of CPUs sold with that board.
However:
It might not include the very latest microcode (especially security updates released after the board was shipped).
Therefore, OS-level microcode loading is still recommended.
UEFI typically updates the CPU at boot, before any OS starts, but the update is only what the firmware contains.

Your ucode revision 432 does look stale though

Known latest revisions for 06-9A-04.40

From Intel microcode release notes (and mirrored in intel-ucode.bin for FreeBSD and Linux):

Revision (hex)    Revision (dec)    Release date
0x00000431    1073    2024-11-11
0x00000432    1074    2024-12-02
0x00000433    1075    2025-01-15
0x00000434    1076    2025-02-11

Also, the pkg has a date, but does the bin and 069a04.40 file have updated code as we expect?

#!/bin/sh
# List all microcode revisions in intel-ucode.bin

FILE="/boot/firmware/intel-ucode.bin"

OFFSET=0
while [ $OFFSET -lt $(stat -f "%z" "$FILE") ]; do
    # Read 48-byte block
    BLOCK=$(dd if="$FILE" bs=48 count=1 skip=$((OFFSET / 48)) 2>/dev/null | hexdump -v -e '"%08X " 4/4 "\n"')
   
    # Extract revision (1st 32-bit after header version)
    REV=$(echo "$BLOCK" | awk '{print strtonum("0x"$2)}')
   
    # Extract CPU signature
    SIG=$(echo "$BLOCK" | awk '{printf "%08X\n",$3}')
   
    # Extract date (assuming 32-bit BCD in 28–31 bytes)
    DATE=$(dd if="$FILE" bs=1 skip=$((OFFSET+28)) count=4 2>/dev/null | hexdump -v -e '"%02X""%02X""%02X""%02X\n"')
   
    # Print it
    printf "CPU Signature: %s  Microcode rev: %d  Date: %s\n" "$SIG" "$REV" "$DATE"
   
    OFFSET=$((OFFSET + 48))
done