Asus Z9PE-D8 WS bios request/question

@ghost82 - Great to hear it’s working now! And even better to hear your actual edit is OK and working too, all very nice!
About your move file test, if you open BIOS in UEFITool NE Alpha (such as 51), you will see that this module is NOT “Fixed” over on right side info, so should be able to be safely moved

If you take the BIOS I sent you and extract the entire mod module from the BIOS As-Is, then you will have the “new FFS” I made
And then you can edit stock BIOS (extracted from capsule) and replace that new FFS (entire module as-is in this context) with UEFITool 25.0 or 28.0 and you wont get padding added.

Making the new FFS is all I did, then simply “Replace As-Is” The new FFS creation is the key!
I recently had to teach myself about making these for Asus X79 too, it was breaking BIOS no matter how we inserted some updates without using a new FFS.
And padding wasn’t be added or removed in that case either, but no matter what/how BIOS = Brick!

First, you need FFS tool >>
https://github.com/pbatard/ffs
https://github.com/pbatard/ffs/releases

Then with UEFITool NE Alpha 51, or whatever version you want to use for extraction, extract the following from the stock BIOS - how I outline
1. AMIboardInfo >> Expand and select >> DXE Dependency Section >> Extract >> AS-IS >> Save as >> depex.sct
2. Expand Compressed section and select >> OemPir section >> Extract AS-IS >> Save as >> OemPir.sct
3. Need your Modified PE32 section BODY ONLY (Starts with 4D 5A) >> Name to PE32body.efi (file names I give here, such as PE32Body.efi or OemPir.sct only matter for the outline below, you can use any names you like once you know how to make)

Put all that into folder with FFS tools >> Now you are ready to make new FFS
Run commands below, and on final CMD, you will have new FFS to simply “Replace As-Is” and it wont make padding issue

1. gensec -o name.sct -S EFI_SECTION_USER_INTERFACE -n “AmiBoardInfo” // This creates the “UI” section of the compressed module, and makes a temp name.sct file //
2. gensec -o pe32.sct PE32body.efi -s EFI_SECTION_PE32 // This creates the PE32 section of the compressed module, and makes a temp pe32.sct file //
3. gensec pe32.sct OemPir.sct name.sct -o comp.sct -S EFI_SECTION_COMPRESSION // This compresses PE32.sct, OemPir.sct, and name.sct into a temp compressed section names comp.sct - FYI, sections are compressed in order used in command, in case you need to swap things around in other edits //

4. genffs -d 1 -g “9F3A0016-AE55-4288-829D-D22FD344C347” -o AmiBoardInfo.ffs -i depex.sct -i comp.sct -t EFI_FV_FILETYPE_DRIVER // This creates the new FFS module giving it the original GUID //

So this makes new FFS (As-Is) Module >> Depex (DXE Dependency section) + Compressed section, which we made previously that contains >> (PE32 >> OemPir >> UI) >> output >> AmiBoardInfo.ffs (NEW one )

You can run genffs or gensec with no parameters and it will give you the help/info for all possible flags/options to be used.

Thank you very much for such information! I will try to replicate soon.

UPDATE: the following spoiler doesn’t work!

I was able to do all with only uefitool I think (I did not test yet the final rom, but I’m quite confident it will be ok).
1- Extracted all modules "As is" from the original cap file (naming 1.ffs, 2.ffs, …, 161.ffs)
2- Extracted as body the PE32 inside AmiBoardInfo and save as AmiBoardInfo-PE32-body.bin
3- Edited the dsdt table inside AmiBoardInfo-PE32-body.bin with an hex editor
4- Saved the new edited file as AmiBoardInfo-PE32-body-MOD.bin
5- Replaced body of PE32 image inside AmiBoardInfo in the original CAP file with AmiBoardInfo-PE32-body-MOD.bin
6- Saved the modified CAP as Z9PE-D8-WS-ASUS-5802-PE32-MOD-inserted.CAP
7- Extracted "As is" the whole AmiBoardInfo of the Z9PE-D8-WS-ASUS-5802-PE32-MOD-inserted.CAP and saved as AmiBoardInfo-PE32-AsIs-MOD.ffs
8- Opened the original CAP file
9- Deleted all modules after AmiBoardInfo (AmiboardInfo included), AmiboardInfo module was previously extracted as 11.ffs, save the image as build10.CAP
10- Inserted AFTER last module AmiBoardInfo-PE32-AsIs-MOD.ffs and saved the image build11.CAP (all ok)
11- Inserted 1 module at a time always after the last module in the volume and saved the image after inserting 10 modules (to check everything was ok), saved image as build20.CAP, build 30.CAP, etc.
12- Removed capsule to have the final rom

The structure is identical (including positions of modules), no additional pad-file added, hex comparison with your rom shows differences but this should depend on different method…I’m quite confident it will work, I will try this too.

Of course your method is a lot faster and less prone to errors, extracting/inserting 151 modules can cause some distraction/error ahah




This is confirmed by the above spoiler (which doesn’t work, pad file not added, all seems good but unbootable bios)

Again thanks for the time you dedicated to this, now I know something more about bios!

@ghost82 - Spoiler is confusing??!! Why extract ALL modules?? Yes, that is way too much effort, and too easy to mess up since this is all the way at the beginning of file
And some modules should be inserted via direct hex only not UEFITool/MMtool >> any PEI module, such as last module, one above it, and a few throughout
Due to PEI modules inside DXE volume, this may be why rebuild of this volume is “often” an issue, or at least adds to the overall issues here.
PEI modules can be a pain sometimes and really should be only by itself in their own volumes (!!ASUS!! )

If you’re doing this as a “test move of AMIBoardInfo” experiment, then this would be ideal/easy way, this way you are not messing with any “Fixed” module and you’re not messing with any PEI module >>

1. Take file from #7 (AS-IS MOD AMIBoardInfo module - mod FFS, but not “newly created” one)
2. Using UEFITool 25.0 >> Delete original AMIBoardInfo >> Save file as Interim.bin
3. Open Interim.bin with UEFITool 25.0 >> Insert Mod AMIBoardInfo under last DXE module in original volume (ASTGOP_DXE)
4. Save as mod.bin >> Insert into original capsule for USB Flashback.

If that fails, and you want to repeat this test to confirm the “Move” is OK in general but the mod FFS vs New FFS is the issue
Do the same with the module as-is from the BIOS I sent you (ie use the new FFS/Module as-is and move to end).
If you want me to make either one of these “test move” BIOS, let me know!

Sorry, not sure what your last bold comment is “Confirming”?

This may be BIOS Like I mentioned about the Asus X79
Not all modules had issue, but some no matter how they were replaced during update >> if not new FFS = bricked BIOS.

Did you make your own new FFS module yet?

oh yes, sorry…I didn’t pay attention to fixed modules/PEI so my post above is really a non sense!
Thanks for explanation

Thank you Asus to make things easier for all of us :smiley:

@ghost82 - You’re welcome! Fixed module may be OK to redo like you did, provided same order, I’m not sure if “Fixed Yes/No” is by offset or order. Only @CodeRush could answer that one for us
But yes, PEI module often cause issue on rebuild, but this normally is if you edit them, I’m not sure what would happen in scenario you presented.
Anytime I touch PEI I do it via direct hex only (may need to make interim build w/ tools, to get new checksums, but then redo on mod BIOS via straight hex).
In this case, interim build for checksums etc would not be needed, since you are not modifying the PEI’s

Sorry you put yourself through all that hassle, I know it’s a major exhausting thing to do, I used to do it back in the day for some old non-UEFI BIOS with only 20-30 modules and even then it was major pain

Do you want me to make those two test “move” BIOS for you to test and see what happens, or will you make them and test (or you don’t care now? )

I care I care!as I wrote understanding is more important than a working file for me.
Give me some time and I’ll report results

No worries, I simply meant it like “do you not care?” about testing the “move” x2 to see, since it’s really not needed anymore I wasn’t sure if it mattered to you or not now…
You know, since we now know what is actually working properly without having to move the module to the end anyway
I only considered it thinking you might want to test to find the answer no matter what, since you put in all that work doing one by one extracting/adding back etc.



This one works!



Just to confirm, yes, no padding is added