@frankr2994
Since your main questions have been already answered within the first post of this thread, I have moved your request here.
Generally I do not recommend to insert a complete DXE driver module, which has been taken from a BIOS of another manufacturer as *.ffs file (with GUID header), into a Dell BIOS. The chances are high, that the modded BIOS will either not be accepted (better option) or not work (worst option).
Before you start with the extraction of the “DXE Drivers” from the Supermicro BIOS, I recommend to check
a) the GUID header of them (first 8 bytes should match your Dell BIOS) and
a) their content and fuction (more than 1 DXE driver with the same function within a BIOS may induce problems).
Question: What is the sense of your project? Which benefit do you expect by doing that? Is it worth despite all the risks of a bricked Dell system?
Good luck!
Ive bricked my bios 3 dozen times last couple years. I don’t care about recovery lol.
So the purpose is to add a XTU dxe driver and a cpuPerfTune dxe driver. I have unlocked the bios to the point where windows XTU can change clock speed and voltage. XTU will not write any settings back to nvram andI have no access to ICC overclocking. Any attempts to modify ME using Intel FIT result in hard brick.
So I’m hoping to fully integrate XTU at which point the software should show icc overclocking, all available voltage adjustments and be able to write back and save to nvram.
Real purpose is just to do this. I like playing with bios mods and that’s about it.
You’re adding a DXE driver to a bios, used on EFI/PEI initialization only, that has no instructions/calls to load it and ICC is fused on PCH.
My pov only… but i doubt that will gain any access to ICC OC options.
Anyway, good luck.
Icc overclocking is a 98 percent chance of failure. There is only a standard profile in ME with frequency locked down to 99.8mhz.
Regardless I have a copy of the XTU development kit and it’s looking for the SMI address. Supposedly the interrupt address is provided through device int 3394 which is the XTU driver for the bios.
If you or anyone else has any ideas on modifying ME to create an icc overclocking profile without bricking the board automatically let me know and I’ll make a new thread.
@Fernando
I followed your guide to insert @Kuri0 's ReBarDxe.ffs in my bios, dump but I am getting the pad file corruption issue. There are 3 pad files in the DXE volume and there’s also a module “volume free space”. Firstly, I tried the simplest method using the UEFITool but it removed one pad file completely and altered the size of another pad file. Next, I used MMTool but it not only changed the pad file size but also the contents and location, interestingly the “volume free space” also expanded when I used MMTool to mod the bios. In the third method i used HxD Hex Editor to manually insert the ffs file into the dump, the file was 0xA12 in size but I added 6 bytes of 1s after the ffs module to make it 8 byte aligned and then removed 0xA18 bytes of 1s from the “volume free space”. This time, all the pad files are okay, there is a reduction of 0xA18 bytes from “volume free space” but I get a different error: “FfsParser::parseFileHeader: unaligned file” for two files in DXE volume, I checked in HxD they look aligned to me. Is there anything to make it work or am I missing something? Any help will be appreciated.
P. S. pictures of comparison attached
Comparision.zip (632.3 KB)
@Ahmad_Salal
Welcome to the Win-Raid Forum!
As the thread title indicates, this thread is just about the usage of the UEFITool, because this tool - contrary to AMI’s Aptio IV/V MMTool versions - is
a) free available for all users and
b) works with all AMI Aptio IV/V UEFI BIOSes.
You can find a Guide about the usage of the AMI Aptio IV MMTool v4.50.0023 within the start post of >this< thread (Step 2 of the Chapter “This is what you should do:”), but the related thread has nothing to do with your specific problem.
To be able to help you, you should
a) give us information about your in-use mainboard (manufacturer/model) and
b) attach the original BIOS file (or link to it).
Good luck!
Dieter (alias Fernando)
@Fernando
I am using a Lenovo ThinkStation P500 (30A6), the BIOS is AMI Aptio V and the motherboard is Lenovo scorpius rev1.0. Here’s the BIOS dump:
BIOS_Dump.zip (7.8 MB)
@Ahmad_Salal
After having tried to get the ReBarDxe.ffs module properly inserted into your Dump file by using various BIOS modding tools I gave up. No matter which AMI MMTool or UEFITool version I used, I got unwanted impacts on other BIOS modules.
Conclusion: I am not able to help you.
The bios may work without empty paddings, but the one that is non-empty must be fixed.
You should better ask Lenovo.
Since several years many mainboard manufacturers are trying - more or less successfully - to prevent the flashing of a modded BIOS.
Maybe a BIOS modding expert like @Sweet_Kitten can help you. His last post looks as being promising.
@Sweet_Kitten
Can you look at this file and tell if it will work or not, I manually inserted the Rebar module and removed 0xA18 bytes of 1s from “Volume Free Space”
BIOS_ReBar_HxD.zip (7.8 MB)
Don’t know if it will work. If you can easily recover the motheboard from bad flash, give it a try. Also try this one.
Can I ask what modifications you did with dump?
I just rebuild the file with uefitool. One pad completely removed and two altered.
I see, with old engine? When I inserted the module with UEFITool 0.28 same thing happened, one pad file removed and other altered.
Is it a desirable outcome? Is it safe to flash? I am struggling with the same problem, made a post under Kuri0’s Resizeable BAR thread regarding the issue.
I thought for a Pad-file to be deletes it needs to be done properly (meaning the BIOS’s company itself should do it so it won’t break the motherboard).
Would appreciate it very much if you have an idea.
Nobody is able to answer such question. Each BIOS flashing is somehow risky, even with an untouched original BIOS (e.g. if a sudden power breakdown happens during the flashing produre).
If you are unsure to flash a modded BIOS, where one or more Pad-files have been moved/removed/added by the UEFITool, I recommend to use another tool (e.g. a suitable AMI Aptio UEFI MMTool version, if you have access to it).
The mainboard manufacturers will not help you. Quite the contrary they try to prevent any BIOS modification done by the user.
Right, I wasn’t clear enough then. I meant is it going to work?
Also, I tried both MMTool and UEFITool as I elaborated in the post I linked. Sadly does not work.
Of course, I meant that there are some BIOSes out there that come from the manufacturer as Raw > Pad-file > Raw (which is supposedly corrupted) and not Pad-file > Raw > Pad-file > Raw. So I meant to ask is there a chance the BIOS is going to function properly even after deleting a Pad-file if the manufacturer itself didn’t do it?
Thank you very much for your time and will to help!