The original BIOS is in the attachment.

1. I am using Kingston A2000 NVMe PCIe SSD 1TB.
2. I used AFUWIN to flash the modded BIOS. Using AFUWIN again to extract the current BIOS gave me the same file I flashed (I compared MMTool reports). Is there any other way I could use to check that it was flashed properly?

Zitat von Fernando im Beitrag #5908

---

@Lost_N_BIOS:
You are right - it is nearly impossible to keep a very popular thread like this one strictly on-topic, but I do not 100% agree with your statement, that the recent discussion with MKS-DXB has been completely topic-related.
This is what I have written into my guide (= start post of this thread):

Zitat von Fernando im Beitrag #1

---

If you do not know how to prepare a modded UEFI BIOS or how to get it properly flashed, please read the start post of >this< thread. Since the BIOS flashing procedure itself is not the topic of this thread, you should post all the BIOS flashing related questions/problems into the linked thread.

---

Nevertheless our Forum Member MKS-DXB started the recent discussion with this post:

Zitat von MKS-DXB im Beitrag #5895

---

Have a similar mother board. Have been unable to do a usb flash after bios mod as its a .rom file.

---

It turned out, that he didn't know how to flash an ASUS *.CAP BIOS by using the ASUS USB Flashback feature.

---

hi to all, thanks for the support, you can help me? i have an error when i reopen modded bios on UEFITool, error says "parseFile: invalid data checksum 5Ah, should be AAh"

i attach the bios file that i created, my motherboard is a z77a-g43

@Matiux14 - That is normal for your BIOS, stock BIOS says same, I checked version 2D
* Edit - I checked your BIOS, and I would not flash that, it may brick! NVME is inserted in wrong location (should be at end, after last DXE entry - MFlash) and padding file is missing at end of main DXE volume (volume you are editing in)
You need to redo the mod, using a different tool (ie use MMTool 4.50 instead). Once done, rename back to stock name.extension and M-Flash it

Hi, I followed your excellent instructions, used MMTool and was able to modify my BIOS and get my NVMe drive to boot on my MSI B85M-G43 motherboard. I sent you 5 euro.

One slight error I found is that you show a picture of how the screen should look when you verify that the NVMe drivers are present in the modded BIOS. That picture was captured immediately after the insert and the NVMe drivers are the last item in volume 1. If you save the BIOS after the insert, and then close MMTool, and then launch MMTool and load the modded BIOS, you will see that the NVMe drivers are now the next to the last item in volume 1. It looks like in the process of saving there is some formatting of the file. Padding? That worried me but I redid the process, and looked at the result before I saved the file and it matched your picture and after the save, it was different.

@Fernando - Thank you! Yes, this is well know thing for all Asus, common way, we all use this to make BIOS proper. This is same thing UBU does at end (ie replace capsule once done) and some other tools do as well, such as CoffeeTime.
The issue is not about bricking BIOS in this case, it's about being able to USB Flashback the BIOS or not. In this case, if not done correctly, user simply cannot flash the mod BIOS, USB Flashback will not detect the file or will error and not start etc
Sorry, I cannot link you to anything about this, it's something we users who modify BIOS have known, done, and worked around for many years since Asus started using CAP BIOS
It's just common knowledge for editing Asus BIOS, there is no guide/info about this to link to in general

The stock capsule 2-4KB at start of each encapsulated stock BIOS is not touched or edited, only the actual BIOS/Body of the capsule is extracted, edited, then replaced back into the capsule once finished.
The BIOS itself (ie body) of capsule can be extracted w/ UEFITool or by direct hex, or you can simply/cut/delete off the capsule and leave yourself with the BIOS body, then put back as mentioned later, it does not matter but the latter is least ideal for non-tech users to deal with.

MMTool, AMIBCP, and UEFITool can edit BIOS while in capsule yes, but 99.9% of the time this = broken capsule or invalid/unsigned capsule and you cannot use this with USB Flashback. Rare case may pass (0.0001%), if some bug in BIOS/check by flashback not done etc.
Often MMTool or AMIBCP will tell you, "Saving BIOS as unsigned", with or without capsule, but this does depend on the BIOS or tool version, if you see that message or not.
But in all cases, if you edit BIOS with capsule attached, and do not do as I mentioned instead, then you cannot USB Flashback the BIOS.

Yes, mainly, only Asus are encapsulated in this way, with signed capsule as first 2-4KB of the BIOS. Some Asrock as you know, have an internal capsule/signature check thing, but it's not this same method/thing Asus does
Asus has done ALL BIOS this same way since beginning of switch from ROM to CAP several years back. I do now know why Asus does this, I guess they think it helps with "Security", similar to why Asrock does their thing too.
No manufacturer needs this, and none should do it!! But you know, they all try to act like they want to be "Secure"

As for new guide, Yes, I have considered making some type of general how to edit/save and check to be sure BIOS is OK before flashing type of guide.
But, I've just not had time to do yet. Same as I REALLY need to update my fix FIT guide too, much easier way to do that now, just no time to update it yet
But, as for replacing this guide, no, I can't do that and don't think it needs done. This is a great guide, just needs updated with some info from time to time.
I know long threads concern you, so you could always make this one a new thread, just close this and start a new w/ copy/paste of first post, that way this thread would start over new/fresh and not be so long.
If you would like me to write you out some step by step short summary on how to do the Asus Caspule work-around, and maybe include a few image examples at each step, then you can edit/adjust however you want and make your own image examples etc, let me know?

@Lars - yes, due to padding and MMTool not showing the name of that padding file. NVME will go to below last "DXE" labelled entry when looking at the file in UEFITool, sometimes this may go before or after a padding at end, all BIOS are different
Look at your before/after side by side with UEFITool and you will better see the padding change, and or how/where the NVME module gets inserted.

@Fernando - You're welcome!

Yes, it very well may be your P8Z77-V is one of the rare ones this is OK on, similarly some Asus by accident or rare forgetfulness, can also flash mod BIOS via EZ Flash, which as you know Asus's goal is to block that at every example.
This is similar to that, I'm sure you've seen cases where user can flash mod BIOS via EZ flash, it's rare, and not supposed to be allowed/possible.

Additionally, it's not always about what's in the capsule, it's about if the capsule is attached when modified that causes the issue. Something else in the BIOS is changed/checked elsewhere, which I've not ever looked into, this may be more the case with Aptio IV than V
Sometimes capsule changes to Aptio Unsigned, and sometimes capsule remains same 800-1000 bytes, but whatever it checks internally, if not the capsule itself, in some cases is changed. If CAP is attached when modified and I don't think "unsigned" is the only time this will fail flashback.
This check and how it all works all may depend on board series or capsule version, or Aptio version I am not sure, especially on Aptio IV, for Aptio V it's almost always changed to "Unsigned capsule" (but again, not always), and may depend on tool used as well in these cases

The older example BIOS which we started with recently that MKS-DXB was using (Maximus V Formula) did not say "Unsigned Capsule", yet it was stopped from being flashed via flashback until properly made.
Newer BIOS, I grabbed random example to check for you, MAXIMUS-IX-CODE, if you edit this as-is, with MMTool 5.02 or AMIBCP, then check with UEFITool you will see Aptio Unsigned for the capsule, and it tells you when saving MMTool or AMIBCP that it's saving as unsigned too.
Doing same edit with UEFITool 25/28 etc, will not change the capsule, but this resulting BIOS would still be unable to flash via USB Flashback too, due to internal checks done outside the capsule
Files created with any of the three tools as-is would not be possible to USB Flashback. Some older examples such as some Aptio IV or your exact board, capsule may remain signed but BIOS still unable to flashback (except in rare cases)

You can see by @SoniX's UBU this is commonly known and used practice if you still are not sure I am correct. First thing UBU does is to remove capsule from BIOS, thus you see the 2-4KB smaller "BIOS.bin" in the work folder.
Then it does it's scans, and lets you update etc. Then at end you are given option "Rename to Asus Flashback" (ie put mod BIOS back into stock capsule) or leave as-is BIOS.bin. Choosing the Flashback option, the original capsule is then restored, otherwise BIOS is left as-is without the capsule

Or, just google search here at the site, all the times I had to help users fix capsule via hex (search >> hex capsule flashback site:win-raid.com)
And then double or triple those findings for for all the times I just checked users mod BIOS and fix without mentioning the issue

As to the percentages I mentioned, Asus goal is 100% protected, so those that fail and allow in a mod BIOS are rare and would only be by their mistake, thus my 99% / 1% comments, but yes, those may be a bit off from how many actual mistakes they've made in all the BIOS they put out

Changes to the main post look good to me, thank you!
I will take some time tonight and update that post you linked to, to add how-to image examples for user so it's easier to see what is being done for those unfamiliar with using UEFITool or hex editors
^^ Done, please check and let me know if you think everything is clear enough, or if I need to add or change anything - thanks!

Just an update for any Supermicro owners. I've got an X10SRL-F board:
BIOS 2.0b - Requires DXE driver baking in
BIOS 3.0b - Supports nvme boot out of the box
BIOS 3.1 - Supports nvme boot
BIOS 3.2 - Supports nvme boot

FYI my old X9SRL-F on 2.x BIOSs required DXE modding, but since then they've moved to 3.x BIOSs. I wouldn't be surprised if nvme boot was also included in the OEM firmware, but can't guarantee it.
Thought I might put this here as release notes had no details, Supermicro support were useless, but Fernando said 3.1 should work, and it did, so I thought I'd experiment with older and newer.

@Fernando - You're welcome, and thanks for looking it over to be sure all looks OK to follow along for everyone
Yes, I moved that around too, it was split, addressing him up top and then his BIOS linked at bottom, due to how I originally posted that. So then I combined it at top.
But for now, I will put in spoiler at bottom of post, I think maybe that's best (in case he did not grab yet) << Done, please check it, thanks

Hmmm, yes I can make that into it's own sticky new guide, but explaining reasoning is not my strong suit, as you can see above in the posts you mention
Don't do anything on this yet, about closing this topic to make new one etc, give me some time.
I would like to gather some images at random as I edit BIOS, about added/removed padding and or non-UEFI files, as BIOS edits are done, and then I will add checking that and how to check stock/mod BIOS side by side in general to this guide too.
This will take me some time to get these images naturally, I don't know what BIOS to easily grab and do it on purpose to cover all the things I need to cover and not be wasting hours checking BIOS and trying to re-create on purpose, so it make take a while.

hi. you can help me?
i have old mather board. Z8MAD2H3.U1C (last bios)

NvmExpressDxe_Small.ffs

MMTool v4.5.0.23 [UEFI]
---------------------------
file size exceeds the volume size


solution: https://www.win-raid.com/t871f50-Guide-How-to-get-full-NVMe-support-for-all-Systems-with-an-AMI-UEFI-BIOS-395.html#msg122634