Win-Raid Forum (Drivers - Firmware - Modding) » Special Topics » NVMe Support for old Systems » [HowTo] Get full NVMe support for all Systems with an AMI UEFI BIOS
@DarkLunaPhantom:
Thanks for the original BIOS.
After having compared it with your modded BIOS I found out the following:
1. You have inserted the small NVMe module absolutely correctly.
2. Nevertheless your modded BIOS may have become unusable due to the fact, that the MMTool additionally has inserted a natively not present Pad-file.
3. By using the UEFITool v0.26.0 I was able to insert the small NVMe module without adding the unwanted Pad-file.
Here are the related pictures showing just the downmost end of the "DXE Driver Volume":
1. Original BIOS: 
2. Your modded BIOS: 
3. My modded BIOS: 
Attached is the BIOS, which has been modded by me. Try it at own risk and report, whether it worked or not.
Good luck!
EDIT: The attached BIOS file has been removed by me on 10/27/2020
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 #1Nevertheless our Forum Member MKS-DXB started the recent discussion with this post:
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.Zitat von MKS-DXB im Beitrag #5895It turned out, that he didn't know how to flash an ASUS *.CAP BIOS by using the ASUS USB Flashback feature.
Have a similar mother board. Have been unable to do a usb flash after bios mod as its a .rom file.
I do see what you mean, but the last part is what I was getting at. He knew how to flash it via USB Flashback, had used before with stock BIOS, but his NVME mod BIOS was not prepared properly due to following this guide the steps I mentioned were not addressed within the guide.
So, he ended up with an NVME mod encapsulated improperly because none of that is discussed as part of the NVME mod process. Sure this could be taken as a flashing problem, but it shouldn't have to be (our discussion about on/off-topic posts aside), this should all be covered in this guide here
My main point was all that about capsule, editing BIOS outside of capsule and putting back into capsule, should really be part of the guide, something to cover that for all Asus users.
Otherwise all Asus users are instantly stuck with invalid mod BIOS as soon as they follow the guide, and then either have to ask for help to redo here, or another thread, or make a new thread etc
This shouldn't happen by following a guide to mod a BIOS, unless addendum is added "Asus users - Please start a new thread of your own, or ask "here (at link)" for help how to fix your NVME BIOS once done with this guide - see what I mean?
And my apologies if anything I said in previous reply sounded rough, I was very sick, head pounding, and stomach swirling, and so I was trying to hurry my way through that reply so I could go toss-it-up
@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
@Lost_N_BIOS:
Thank you for your statement and advice regarding the modification of capsuled ASUS mainboard BIOSes.
Before I am going to update the start post, I would like to know more about the additional risks to get a bricked mainboard/system, if the user modifies the entire *.CAP file instead of extracting and modifying the "body" of a capsuled BIOS. Is your knowledge based just on the feedback you got from users, who ran into problems after having flashed their modded ASUS BIOS, or is it a wellknown and often discussed problem? If it should be the latter, please give me links to the related publications.
As we both know, the AMI Aptio UEFI MMTools and all versions of the UEFITool are able to modify capsuled BIOSes and to save the modded BIOS without giving any warning.
Additional question:
Are only ASUS mainboards with a capsuled BIOS (offered by ASUS as *.CAP file) affected by these specific problems? If yes, why? If not, the BIOSes of which other mainboard manufacturers need the same precautionary measures?
By the way, as I already have mentioned >here<, it may be a good idea to start a new thread by writing a new/updated guide. Would you be willing to overtake this task? You know much more about BIOS modding and the related risks than me.
@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.
@Lost_N_BIOS:
Thank you very much for your detailed answers, which enlighted me in different ways.
As a consequence I have updated today my guide regarding the following sections of the chapter "This is what you should do:":
- "Preparations"
- "BIOS Modification" > "a) Guide for the usage of AMI's MMTool 4.50.0023:" > "Verification of the successful insertion:"
- "BIOS Modification" > "b) Guide for the usage of the UEFITool:" > "Verification of the successful insertion:"
Please have a look into related sub-chapters and let me know, if you should have any alternative or additional proposal.
By the way:
My limited knowledge about how to modify an ASUS *.CAP BIOS and to get it properly flashed was mainly based on my own experiences with my ASUS P8Z77-V, which I owned until April 2015. I modded the BIOS very often without removing its capsule and never had a problem to get it properly flashed by using the USB flashback method.
After having read your explanations, I have done some additional tests with the AMI Aptio IV MMTool 4.50 and with the UEFITool 0.28 to find out, whether any byte of the capsule header really will be altered by the insertion of the NvmExpressDxe_4.ffs module. My test candidates were the latest original (capsuled) BIOSes for the ASUS mainboards P8Z77-V (the one I formerly owned) and Z87-PRO. Both AMI Aptio IV BIOSes are supported by the ASUS Flash-Back method. The insertion of the NVMe module went flawlessly with both BIOSes and both used Modding Tools (neither a space nor a Pad-file problem). After having successfully modified the *.CAP files I compared the capsule header codes of the original and the modded *.CAP files by using the HxD tool.
Result of my 4 tests (2 different BIOSes, 2 different Tools): The BIOS capsule header hex codes before and after the insertion of the NVMe module were absolutely identical. Not a single byte had been altered.
My conclusion: It would not have made a difference, if I would have removed the original capsule before modifying the BIOS and re-added it to the modded BIOS "Body".
My question to you: How do my test results match your recent statement?
Zitat von Lost_N_BIOS im Beitrag #5918Have I been just lucky having by chance tested the 2 only ASUS *.CAP BIOSes, which belong to the 0,1%, whose capsule don't become invalid/unsigned by the insertion of the NVMe module?
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.
Since you have much more experience with the modification of ASUS *.CAP files, I have no doubt, that there is a risk to modify a capsuled ASUS BIOS directly (without removing and re-adding the original capsule), but I suspect, that the percentages you mentioned are too high (99,9%) respectively too low (0,0001%).
@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!
@Lost_N_BIOS:
Thank you very much for having extended your previously very short guide and for having added the related screenshots to make it as easy as possible for newbies.
Zitat von Lost_N_BIOS im Beitrag #5920Your updated guide is fine.
@Fernando - ^^ Done, please check and let me know if you think everything is clear enough, or if I need to add or change anything - thanks!
Nevertheless I have a remark: The first sentences of the post and the fact, that you had addressed it personally to MKS-DXB, may irritate the users, who will be linked to the related post by my guide. Furthermore it may not be a good idea to hide such important guide, which covers much more than the topic of this thread, in a thread, which will be closed and marked as "Outdated" very soon.
My proposal is, that you start a new "stickied" thread about how to manually modify ASUS *.CAP BIOSes within the "BIOS Modding" subforum and paste the guide into the related start post. This would offer you the opportunity to add a short introduction and explain the reason for the necessity to remove the capsule header before starting the BIOS modding procedure (as you had already layed down within your posts #5918 and #5920).
What do you think about this idea?
@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.
@Lost_N_BIOS:
Thanks for the update of the linked post - it looks much better now.
Regarding the creation of a separate thread about the modification of ASUS *.CAP BIOSes we are not in a hurry. Once it is online, I will start a new thread about the NVMe support of old systems and close this one.