![]() ![]() ME region starts at offset 0x3000 and ends at 0x200000 (0x1FF + 1)* 0x1000, which is correct.ģ. GbE region starts at offset 0x1000 and ends at 0x3000 (0x02 + 1) * 0x1000, which is correct.Ģ. So, this region map says to us (and to chipset logic too, if flashed to SPI chip as is) that:ġ. Orange - upper bytes of BIOS region limitĭark-blue - upper bytes of GbE region limit If you don't familiar with structure of Intel descriptor region, here is an annotated HxD-screenshot of affected part: What Intel does from there on is unlikely to be a trivial change, and I would rather refrain from guessing, as they could even put some 0xF0000001 "extended" version and feel happy.During the debugging of strange behavior of using UEFITool with Gigabyte BIOSes, I have found either a bug or a special non-standard region map configuration in all recent Gigabyte BIOS images. For the good to the discussion it mostly matches your preferred naming, for the bad.Īs for versioning, currently all firmwares verify first and sixth dword against 1 very close to reset vector, so I will probably stick to the current code. I will probably go with Microcode.h from EDK II and update the names once again tomorrow. Perhaps, what we could do here is to stick to authentic Intel source file with the latest copyright year. I did a recheck on the names, and it is terribly messed up in the code as well. You can also find many good examples with register names being named differently in SDM and UEFI code. For example, not so long ago I faced I had to go through CPU frequency detection on Intel Xeon W and Xeon Scalable, and trust me, SDM helped least. Intel SDM and Intel Reference Code (which is now largely open source) are written by completely different people, and the former is, frankly said, full of out of date or misunderstood information. In my opinion, it is unreasonable to try to guess what Intel does before at least one change happens I've also noticed that 2 bytes are the actual revision and the other two are "flags" or similar. For example, the first bit (signed dword) shows whether the microcode is Production or Pre-Production. No, not really, just not documented officially. Even if Intel was calling it "Update Version" instead of "Header Version" (which they're not at the official documentation for MCU), it doesn't mean that we should use the wrong term as well. My objection was with the term "Update" instead of "Header" at the first and second dword. Even Intel as you can see from the "Loader Revision" above. ![]() Sure but most people don't know the difference and tend to use either one. Internal format detail is called versions, external format detail is called revisions In my opinion, it is unreasonable to try to guess what Intel does before at least one change happens.įrom Intel 64 and IA-32 Architectures Software Developer’s Manual Vol 3A, Ch 9.11.1: Internal format detail is called versions, external format detail is called revisions.Īs for values, given how much time it stayed like that, it is safe to assume that the change in the numbering will result in severe format changes with potential update of the fields. This value has always been named LoaderVersion or similarly. That's the thing read from MSR_IA32_BIOS_SIGN_ID ( 8Bh), and it actually represents microcode revision as present in all known documents and operating systems, not just Intel. It has always been named UpdateVersion or just Version. It makes not much sense to me as well, but it has been like this for years: Current is headers you will most likely have to accept the reality written by Intel. The MSByte of CPUID is always 0 because Intel won't need such a big number any time soon.The MSByte of DataSize and Total Size is always 0 because we won't see >= 16MB microcodes any time soon.The last 3 bytes of Loader Revision are always 0.The last 3 bytes of Header Revision are always 0.If you feel like it will make false positives appear again, here is a list of some extra things I do in MCE to avoid them: The first point by itself should be skipping a lot of valid microcodes at the current commit, based on my experience. In the meantime though, we might be getting false positives. I think checking/allowing Years 2030+ is overkill considering that these are at least 11 years away and at that point who knows what might have changed.For example, microcode cpu906E9_plat2A_ver0000005E_PRD_89811134 has a TotalSize of 0x17220 which has a non zero modulo 1024. TotalSize should work (POR) but alas, there are examples from 20 in which Intel has made mistakes and it is not 1K aligned. For DataSize, it is not POR and in fact fails at most microcodes. Unfortunately you cannot check if DataSize and TotalSize are 1024 multiples.Alright, my two samples do show properly now. ![]()
0 Comments
Leave a Reply. |