Полезные статьи (автор: CodeRush)

Софт




Сохраненные статьи с Win-Raid Forum:

• Intel (Converged Security) Management Engine: Drivers, Firmware and Tools
• Intel (Converged Security) Trusted Execution Engine: Drivers, Firmware and Tools
• Which are the "best" Intel AHCI/RAID drivers?

Другие интересности по теме:

• Отключение BIOS Lock (Error 280 при прошивке)
• CPUID - CodeName Intel процессоров
• CPUID - CodeName AMD процессоров
• Добавление NVMe module в BIOS (6-8 Series)
• Включение ReBAR на платах без официальной поддержки
• Модификация материнских плат 100/200 для поддержки процессоров Coffee Lake 8xxx/9xxx
• FAQ по прошивке и редактор индивидуальных данных BIOS плат ASUS P8xxx и их ROG-аналогов
• FFS. Считаем контрольные суммы сами
• Потрошим структуру меню Aptio BIOS
• ASUS Flashback

Доска объявлений
от 20.06.2020

Соблюдайте Правила конференции и используйте поиск по теме. Мешающие чтению картинки и видео убирайте под спойлер.
Сообщения с избыточным цитированием могут исправляться или удаляться без уведомления их авторов.

jjxaker, окомка IRST 16 туточки
https://www.win-raid.com/t7f13-AHCI-amp ... dules.html
ВБИОС 1054 в коллекции по переносу настроек.

Добавлено спустя 6 минут 11 секунд:
Разберусь с определением и распаковкой, начну потихоньку подклбчать обноления оромок.
Проблемка, что надо пихать цикл в цикл, а оно в бантике порой пашет не так как нужно. Так что пока ручками.
Кстати, тебе не показалось, что новый муму как то медленнее работает, чем предыдущий?

MMT реально медленнее стал работать, UBU в целом и так не быстро сканировал а сейчас так вообще капец.
Я тебе ничего не говорил так как от тебя это никак не зависит. но так то в целом конечно долго то всё, ладно когда комп слабый но он на любом железе отрабатывает с одинаковой скоростью.

Добавлено спустя 23 минуты 9 секунд:
Я вот не пойму что сейчас с GBE твориться? непонятно зачем каждый из производителей с появлением плат на z170 начали по своему настраивать его, в итоге имеет разные названия сетевой карты. например:
Intel(R) Ethernet Connection (7) I219-V это ASRock имеет версию GBE 0.4
Intel(R) Ethernet Connection (2) I219-V это Asus имеет версию GBE 0.2 и тд...
Вот нафига это нужно, ведь замена GBE от одно платы на другую не даёт отрицательного эффекта. должна же быть какая та логика, не просто же так Intel это сделали.

jjxaker, ну да сканирование идет медленно, паииернов то до хохота надо проверить, заием вытащить для получения версии. Для обновления тоже надо лишний раз всё проверить, так что режим ожидания, но не сна.
Я тут как то ради прикола засёк время, получилось почти одинаково что через бантик, что ручками в УТ.
Ну во всём есть свои плюсы и минусы.

За GbE ничего сказать не могу, кроме как - каждый мутит, что хочет.

Кстати, я говорил про новую оромку вбиос CoffeeLake 1007.
Так вот у нее VBT совпадает с 1054 от SKL/KBL. Хошь попробовать?

Ты ещё не учитываешь что это если рука набита, а так то медленно всё проходить вручную будет)))


Ну просто был стандарт так нет же, начали фигнёй заниматься.


Я только обновился и всё настроил, раньше не мог что ли сказать))) давай уже когда новые микрокоды на проц завезут что бы за одно было.
У Asus сейчас же проблема что нельзя профиль настроек биоса сохранить на флешку и потом их восстановить, сволочи уже 3 года не могут починить! тупо GUI зависает сразу после применения профиля. а в ручную каждый раз это ппц просто.

jjxaker, аха, набита. Еще бы паттерны в голове держать.

Лады, я ее пока почищу, а то bsf к ней нема, от 1054 вроде подходит, но что то не совсем.
Попробую VBT перевклеить, если CS в одном месте установтся в 0, тогда хорошо, если не установится, то облом.

DeathBringer The bits are important for everyone, including UBU users. The CPUID relates to a given microarchitecture, not a single CPU. As recent as 2017, check the example of CPUID 906E9.

#77

Most people look at these microcodes and think that the latest update for their CPU is 58 from 2017-03-09. Their mistake is the assumption that the Platform bitmask must always be the same. Wrong. If the same and/or more platform bits are supported, the update is compatible and should be used/selected. In this case:

22 = 1,5
2A = 1,3,5

CPUID 906E9 is for KBL desktop microarchitecture which now works with LGA1151, LGA2066 and BGA1440 (platform 2A = 1,3,5). But before X299 (supports KBL-X, a glorified copy of KBL) was released, CPUID 906E9 worked with LGA1151 and BGA1440 only (platform 22 = 1,5). Thus, 2A supersedes 22 and that is only apparent when the bits are analyzed.

plutomaniac
I know it. Platform field aren't used by CPU, but only BIOS. Microcode are loaded into CPU (by IA32_BIOS_UPDT_TRIG) without a header (0x30 byte size) .
And 22 and 2A aren't platforms, they are only bitmask for Platform IDs. These IDs correspond MSR_PLATFORM_ID[52:50].
BTW: CPU with Kaby Lake core for LGA2066 can start with old version of microcode. But microcode header modification is required.

Добавлено спустя 15 минут:
No bitmask - no mistake

DeathBringer Yes, such can be seen at Intel 64 and IA-32 Architectures Software Developer Manual Vol 3A, Ch 9.11. But it doesn't matter how the BIOS and/or the CPU apply the updates (instructions, patch w/o header and so on). UBU deals with the BIOS microcodes themselves. UBU (or the user when choosing manually), need to know what is compatible with what, otherwise the BIOS won't detect what it needs for the installed CPU and halt initialization (brick).


No bitmask - brick, in some cases. Examples:

#77

Should the user with CPUID 406E2 and Platform F2 (1,4,5,6,7) apply a "newer" by date or version update with CPUID 406E2 and Platform C0 (6,7)? No.

#77

Should the user with CPUID 006F9 and Platform 80 (7) apply a "newer" by date or version update with CPUID 006F9 and Platform 40 (6)? No again.

So the CPUID by itself is certainly not enough, for both the BIOS/CPU and UBU. Not showing the Platform IDs is thus a mistake.


Interesting as it further proves how much of a KBL copy KBL-X truly is but that was only an example. The same rule applies to all Intel microcodes.

plutomaniac
There is no CPU with CPUID=0x406E2 and Platform ID=1,4,5 or 6.
Only with 7. It's ES CPU with core Skylake-U (BGA1356) and Skylake-Y (BGA1515).
Don't know about 0x6F9.

Добавлено спустя 17 минут 37 секунд:
I think that for all modern processors:
Platform ID is
0 - SoC (Atom, Celeron, Pentium etc)
1 - Desktop CPU
2, 3 - High-end CPU
4, 5 - Mobile CPU without PCH
6, 7 - Mobile CPU with PCH

Добавлено спустя 13 минут 36 секунд:
LS_29
Разобрался почему так mmtool распух - он теперь содержит внутри библиотеки Python.

There is. You can find it at the gitub CPU Microcode Repository too. The ucodes above are all real of course. Maybe some early sample which is PRD marked for some reason, but real nonetheless.


No, it doesn't seem to be that generic. For example Gemini Lake SoC has CPUID 706A1 and Platform 01 (0). Also, Canon Lake desktop (CNP PCH) has CPUID 60661 and Platform 80 (7). Both contradict the above list and there are a lot more such examples, modern or older.

Intel's official microcode documentation is very vague and somewhat outdated so it doesn't actually explain what these Platform IDs truly are, other the fact that they represent "slots" (a.k.a sockets) and are needed to properly update the microcode.

#77

The BIOS converts those three MSR bits to a Platform ID (011 = 3, 111 = 7 etc), which can then be checked against the microcode update which needs to be pushed to the CPU.

I said about CPU, not about microcode.
CPUs with core Gemini Lake are Desktop CPU. E.g., https://ark.intel.com/products/128984/
CPUs with CPUID=60661 are ES version of unannounced Cannon Lake-U (i3-8121U & i3-8130U) and Cannon Lake-Y. So it's Mobile CPU with PCH.
All OK
But if you want I can separate SoC into a separate class.

Ah, wrong CPUID for CNL. I meant 906EA which is 1 & 5. Never-mind, one could find countless other valid examples though:

#77

Since this is getting slightly off-topic now, I'll restate my initial point of view. From what I see at Intel's official documentation (no inside info), "Platform" does indeed indicate the supported "slots"/sockets (in coded form, 1 = LGA1151, 2 = etc) and these are relative to each generation/CPUID (as do sockets), so not generic. Maybe there is a pattern similar to the table above (usually 1 for desktop sockets etc) but one cannot assume it's always the rule. Also, more importantly, Intel clearly mentions that these are used to select the correct microcode update. So back to UBU & MCE, it is my humble opinion that Platform should be there in hex & binary form.

In the end, it is Oleg's choice but I would be interested to see what others have to say as well.


Ok but that's another story. OEMs leave all kind of microcodes in their BIOS. We don't have info for a lot of those CPUIDs because they related to CPUs which were only used for testing. No argument there.

plutomaniac
CPUID=0x906EA have CPUs with Coffee Lake core: 1 - LGA1151 (Desktop CPU), 5 - for unannounced Coffee Lake-H (Mobile CPU without PCH).
Intel use a platform mask in microcode for ES CPU with many unused bits.

Добавлено спустя 16 минут 10 секунд:
I'm not against that But I'd like to see a separate table for hex->binary platform's correspondence. But as you wish.

I'm sorry but I cannot understand this sentence. Can you re-phrase?

At the previous picture with CPUID 406F1, do you think it makes sense that it has so many Platform IDs (all apart from one)? From what I can see at cpu-world and Intel's ark, it has to do with Workstation CPUs which are Producton (non-ES/QS) so at least 6 & 7 don't fit.

Regarding whether the Platform IDs matter, from what I've seen, sometimes they do whereas others are just for visual/book-keeping purposes. An example for each case:

#77

Here the Platform ID difference is useless (only header, data same)

#77

Here the Platform ID difference matters (header but, most importantly, also data)

In both examples I found microcodes which are identical (CPUID, Version, Date) but differ at the Platform IDs.


So that it doesn't require horizontal space? I can't see any other valid reason for that and it will look bad & lengthy when you scan microcode.dat files with ~150 entries. I'm certain that it will also confuse MCE and UBU users. However, that's the good thing with open source code, you can fork and customize it as you like.

plutomaniac
If platform mask in microcode has non-zero bit then it doesn't mean that you can find real CPU with corresponded Platform ID and CPUID. Such bits in mask I named "unused".
A platform mask in microcode for ES CPU usually has many unused bits. Sometime a platform mask microcode production for CPU has such bits too.

Microcodes with the same CPUID and version have the same body without reference to a platform mask.

Добавлено спустя 2 минуты 23 секунды:
This was the main reason

Yes of course. Noone expects to have a CPUID for every possible Platform ID combination. That would be absurd. The CPUID & Platform IDs are different things as the first targets microarchitecture whereas the latter targets socket compatibility for said microarchitecture.


It seems you are right! The difference is just encrypted padding, which has been proven to be ignored by the CPU Microcode Loader. This can be verified by looking into the UpdateSize field of the Intel Microcode Extra Undocumented Header which starts after the main header (0x30) and ends at the end of the patch data before any encrypted padding. I tested three cases:

cpu1067A_plat44_ver00000A0E_2015-07-29_PRD_A3107D75 (Update Size = 0x1244)
cpu1067A_platB1_ver00000A0E_2015-07-29_PRD_59BF808E (Update Size = 0x1244)

cpu30678_plat01_ver00000832_2015-02-09_PRD_875B494A (Update Size = 0xC804)
cpu30678_plat02_ver00000832_2015-02-09_PRD_85F50DBF (Update Size = 0xC804)

cpu006F9_plat08_ver00000084_2006-10-12_PRD_6BADD6B5 (Update Size = 0xB44)
cpu006F9_plat40_ver00000084_2006-10-12_PRD_6BADD67D (Update Size = 0xB44)

In 1067A and 30678 cases, the first difference was found at 0x30 + Update Size. In 006F9 case, both files have the same patch data and also the same encrypted padding. That proves your point that microcodes with the same CPUID & Version always have the same actual patch data (excluding the usually different encrypted padding used to confuse tamperers), irrelevant to the Platform IDs. That is very interesting and will require MCE changes, thank you very much.

So in the end, you're saying that the Platform IDs are just for book-keeping purposes? Meaning, they are only there to signify the platform type but don't actually define/change the patch data in any way? In such case, the Platform bitmask is useless and should not even be shown in MCE and of course UBU should not care about it.

But, why does Intel advise BIOS manufacturers to verify it against MSR[52:50] 3-bit value? If we (UBU) ignore it and update freely based on CPUID & Version/Date, is it possible that the BIOS won't be able to match (in some cases) the MSR[52:50] to any microcode binary Platform ID and thus not start the system? For example: if a user replaces cpu006F9_plat08 with a hypothetical newer cpu006F9_plat40, is is possible that the BIOS won't recognize (and thus push to CPU) platform 40 because the MSR[52:50] reports 011 (08 = 3) and not 110 (40 = 6)?

Maybe a long time ago when microcode has 0x800 size only, Intel makes different microcode for different platform. But I don't know...
Yes, it's possible because all BIOS check MSR_PLATFORM_ID[52:50] and a platform mask before microcode loading. But many systems can boot without any microcode.

So in the end nothing changes, we still need to mind Platform ID when updating microcodes because the BIOS does via MSR_PLATFORM_ID[52:50], even if the bitmask is useless, data-wise. The last I didn't know and learned today, thank you again.

In such case, I don't have to change something at MCE, people should mind Platform and should pick a newer microcode which has the same or more bits, that way the BIOS will never fail. What I can change, is what's printed when used from within UBU. We concluded that Platform should be there. Arguably, UBU users don't need to know about the microcode size & offset, which can be very useful to more advanced users who use UEFITool or manual modding via hex editing. Thus we go back here. What's your opinion on A or B? Both can easily fit even at 80x25 cmd.

I prefer A, but I don't like a word "Patch"...

Yes I have already changed that back to "Version" (7 characters). It can also be "Revision" (8 characters, same as max int dword length).

So far there is 1 vote for A and 1 for B. What do you think LS_29?