I don’t know how far you want to go with your program, but since I also have a script/tool named… Extractor (so original that I should register this name and sue everyone else), I believe I can help with some fixes. Here are some screens and observations:
- Some microcodes are missing due to size or CPUID handling. AMD implemented a joke of a header, leaving OEMs to add any amount of padding. To handle this “feature”, you either always use the original AMD size, or you check the padding for some predefined sizes. I went for the second case, as I wanted to have a clear picture on every BIOS file I’m working, without spending extra time with manually checking the padding. The issue is restricted to 0Fh-14h families, where I have found the same microcode to be padded to 0x400, 0x800, even 0x1000 in mc_update dll. Check the official AMD release for getting the sizes, also compare with multiple sources for the missing ones. I already have all the known sizes in my Extractor, but why should I spoil all the fun? The latter families are not so much affected, as they are part of AmdProcessorInitPeim and also have an extra hook ($UCODEVS, $UCODE2K, $UCODE4k) for size. Only seen the first one used (Variable Size), but I have read about the other ones (2K, 4K) in some public sources, possible Coreboot.
- there are some old microcodes that don’t have the middle 0F byte in the CPUID. They should have the CPUID 5xx, 6xx, Fxx - but I haven’t yet researched the distinction, neither do I know where to find them.
- the program is not DPI-aware, check green boxes.
- some unknown fields. It took me a while to figure the message “File already exist!”. Having no control over this function is confusing to say the least. If the extraction or the location can’t be changed, at least make the folder next to main exe or have a clear message on what happened.
For the other things you wrote:
- you can indeed replace the microcodes in Aptio 4 or Aptio V. I assume you already tested and I also received successful reports.
- you can replace AGESA in AWARD, as it is inserted as a single module.
- you can not replace AGESA in AMI, no matter if it is AMIBIOS, Aptio4 or Aptio5. It is compiled with the rest of the source code, there is nothing you can do to replace it. In AMIBIOS it is part of System BIOS (1B module), but also in E1/E2/E3 modules. In Aptio it is spread across many files, but the important code is in AgesaDxeDriver, FchDxe, FchSmmInit and AmdProcessorInitPeim. You can try to replace those modules and you might even get lucky to have a bootable board, but what you have obtained is a franken-board and not a fully operational one. Would you replace parts from your car with others from a totally different car? Not to mention that besides the initialization of important hardware components, those 4 ffs files also contain SMU and PSP firmware, another “wonderful” place to experiment with different code parts.
- I can give you at least 5 different AGESA OrochiPI 1.5.0.5 files that will light like a Christmas tree in a comparison tool, but feel free to test this on your own.
- I see that you mention replacing MEMINIT in AWARD. Why?? It stands for memory initialization, the core of a bootable machine. The only time I would think of doing that is when you know a certain board has some fixes/support for a certain memory kit AND you have that kit AND you desperately need that fix/support. And even then I wouldn’t recommend anyone doing that. Are you sure about MEMINIT not being a sensitive module? Read this message and read the reply two posts bellow. I assume that HT comes from HyperTransport, so MEMINIT seems more likely to have caused that issue. And since the three modules are often added one after the other, I don’t know how you could touch MEMINIT without disturbing the others.
Attached Agesa_OrochiPI_v1.5.0.6 from that Dell file. Obviously, you won’t be able to use it. I hope you won’t try.
Agesa_OrochiPI_v1.5.0.6.rar (177 KB)
