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

[fastboot]

Hi,

I checked IA32_PLATFORM_ID:

cpucontrol -m 0x17 /dev/cpuctl0
MSR 0x17: 0x001c0000 0x00000000

Using bits 52:50:

(0x001c000000000000 >> 50) & 7 = 7

So this CPU appears to have platform ID 7, which corresponds to platform mask 0x80.

That means the relevant file should be 06-9a-04.80, not .40.

The .80 file is now present after cpu-microcode-intel-20260512_1, but the system still stays on microcode 0x432 and reports:

CPU microcode: no matching update found

[Patrick M. Hausen]

Are you sure there is a microcode update applicable to your CPU? Is there any way to check this with e.g. Intel docs?

[fastboot]

Are you sure there is a microcode update applicable to your CPU? Is there any way to check this with e.g. Intel docs?

I do not have Intel documentation directly mapping revisions to this specific CPU.

However, there is fairly strong evidence that newer microcode exists for CPUID 06-9a-04:

- Linux systems with the same CPU (Intel i3-1215U) have been observed running microcode 0x43a.
- My system remains on 0x432.
- After upgrading to cpu-microcode-intel-20260512_1, the package now provides both 06-9a-04.40 and 06-9a-04.80 split files.
- Reading IA32_PLATFORM_ID yields platform ID 7, which appears to correspond to platform mask 0x80.

For reference:

# cpucontrol -m 0x17 /dev/cpuctl0
MSR 0x17: 0x001c0000 0x00000000

which decodes to platform ID 7.

So at this point there seems to be strong evidence that a newer microcode should be applicable to this CPU, although I have not yet found Intel documentation explicitly confirming the exact revision mapping.

[Patrick M. Hausen]

However, there is fairly strong evidence that newer microcode exists for CPUID 06-9a-04:
[...]

OK. That's all I was asking. :-)

[BrandyWine]

I agree with fastboot.
Everything points to cpu variant fusing ID 7 (0x80 mask)

The iucode testing I did shows the newer rev code for this cpu(ID 7). It's listed in the bin and in the .80 file.

Here's some new info, please verify.
According to some docs the klm cpuctl needs to be loaded BEFORE a microcode can be installed by cpucontrol utility.

1) boot normally, try kldstat | grep cpuctl , is that klm loaded?
1a) if that klm is not loaded, then kldload cpuctl (it may not actually be loaded at boot time, or in time for cpucontrol)
2) then try cpucontrol -u /dev/cpuctl0 /boot/firmware/intel-ucode.bin
3) then verify it installed on that cpu
cpucontrol -m 0x8B /dev/cpuctl0
expecting to see MSR 0x8B: 0x00000000 0x0000043b
microcode revision = 0x043b

remember, you have /dev/cpuctl0 and /dev/cpuctl1

If this manual process fails, then something else is preventing the install of the code onto the device, bios/uefi is likely culprit.

[BrandyWine]

although I have not yet found Intel documentation explicitly confirming the exact revision mapping.

100% Intel has it. meyergru was right, that cpu is a 0x80. I was likely provided bad info for the mapping of desktop vs mobile variant (see below).
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commit/b24397c3611f5b0a7ccb3071df99ba596721d82b#diff-1dfe853ac13a3d80cb5ef06b3c030342fb367f6f6ad6bdb2328e48c47ec16e08



Apparently, the i3-1215U is a "mobile" cpu package, period. However, the fusing is different, notice they call the 0x80 the "desktop" fusing and the 0x40 is the "mobile" fusing.

(for this i3-1215U)
mask = "package"/"fusing"
0x40 = mobile/mobile
0x80 = mobile/desktop

/////////////////////////////////////////
Why there are multiple platform IDs (.40 vs .80)
From Intel microcode layout:
The same CPU model (06-9A-04)
can run in different platform configurations
selected via MSR IA32_PLATFORM_ID (0x17)

So Intel splits microcode into:

Platform ID mask   Meaning
0x40                          mobile / low-power configuration
0x80                          desktop / higher-power configuration

///////////////////////////////////////

A good read
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html

[BrandyWine]

Some more reading about alder lake with bios/uefi with freeBSD.
loader.conf may be too early to try and push a ucode update.

as a test, remove the load entries from loader.conf (or change to cpu_microcode_load="NO")

rc.local
#!/bin/sh
sleep 10
/usr/sbin/cpucontrol -m /dev/cpuctl0 /boot/firmware/intel-ucode.bin
/usr/sbin/cpucontrol -m /dev/cpuctl1 /boot/firmware/intel-ucode.bin

chmod +x /etc/rc.local