@100PIER :
Thanks for your comment.
This has meanwhile been added to my guide.
If you want to test that NVMe module configuration, I recommend to replace just the body of the stock nvme module by using the file named NvmExpressDxE_2.efi and to leave the other 2 NVMe modules untouched.
@Fernando
Hello, itâs me again.
Finally managed to plug in the SSD through a PCIe x1-x16 riser with a PCIe->M.2 adapter (whole lot of this shit here xD )
The disk is being recognized by the bios and everything is fine, but I canât install the OS on it, cause the system has some problems with it - it says that wonât boot it 
Any guesses what should i do?
What is the exact error message?
Read and follow the start post of this thread.
@Fernando
âWindows cannot be installed to this disk. This computerâs hardware may not support booting to this disk. Ensure the diskâs controller is enabled in the computerâs BIOS menu.â
@Christophy :
Have you already checked within the BIOS, whether the "Secure Boot" feature has been enabled?
It has to be disabled, if you want to boot off the NVMe SSD.
Have you looked into the "KEYS" section as well?
So Fernando I reached out on the Clover forums about optimizing the nvmexpress driver and so far no one replied or wrote back.
In anycase I have modified one of Coderushâs (I think his) utilities based on the same UefiTool subroutines called Ozmtool and
it will take your Nvme modules (the three vs the one) and insert it into a bios and automatically expand the main firmware volume
so no need to delete Satadriver or recompress any other ffs files to make them fit. I have tested it and found that it has no problem
making room for the nvme modules without needing to use Uefitool. Runs on the command line. So if beta testers brave enough
to test it out please PM me.
@davidm71 :
Thanks for having contacted the Clover Team regarding a newer version of their NVMe module development.
If you really have used the code of any tool, which had been developed by our Forum member CodeRush, did you get his allowance to modify it?
The main problem is not to get a module inserted into a BIOS, but to to get the inserted module and to keep the other modules in the neighborhood working. The possibility to compress certain BIOS modules within a certain Volume is limited. Exactly that is the reason for the message "Not enough space within the Volume", which is a security feature and means: "An insertion may have a negative impact on the function of the inserted and other BIOS modules."
All my tools are explicitly BSD- and/or GPLv2-licensed, so no one needs any permission to modify them.
OZMTool is written by TuxUser (with a bit of my help in better understanding the inner works of the 0.2x engine), but itâs also based on UEFIToolâs source code.
Thereâs a problem with insertion of new stuff in DXE volume if the volume itself is a root volume and hasnât enough space to fit the new driver, and in this particular case, even UEFITool can do nothing with the situation, but this case is very rare on modern systems.
In my opinion, automation tools like OZMTool, UEFIPatch or UBU are actually making things worse, and I only realized it after 5 years of developing/helping developing them.
The tool obscures the real complexity and danger of FW modifications, so less and less people are actually understand what they are doing and why they are doing it, switching to mindlessly applying any VBIOS/OROM/ME update they may find, trying to get another 100 IOPS from the same SSD and another 50 Mhz of already overclocked RAM. This kind of tinkering is totally fine, but only if it helps learning how the FW actually works and why you need to change this instead of that, and automation simply destroys this step. A proper guide with explanations and infos is 100 times better than a program that automates it, because if you read a guide - you learn something, and if you run a program - you learn nothing at all, only itâs author did during the program development.
Please think twice before telling the world âhey guys, Iâve automated your routine BIOS modding task!â as I did, as you will be blamed for every user mistake, every bricked system, every corrupted BIOS and about 10% of those will actually be your fault because a perfect 100% working program canât exist.
@Fernando , about the OROM integration guide: I canât write it just because I donât know anything about them, but @SoniX may know more.
CSM in general is a bane of every EFI developerâs existence, so the sooner we get rid of legacy OptionROMs - the better.
I know there are still a lot of systems that canât work in pure UEFI mode with disabled CSM, but this is a very good reason to upgrade your system.
I was and am very much aware of the gpl license and read it over twice. I did this out of fun and hobby and to learn coding. I meant no disrespect to the original authors or to take credit for their work or anything. The license was very clear that it was allowed as long as a documentation was included referencing the original author. In anycase thats interesting what Coderush has said about command line tools making it worse. All I did was open the app up to take other files besides the usual Oz files. I mean Iâve used this app myself when I was hackintoshing and worked for me. Granted i got a dual bios switch so if anything went wrong i could reflash by turning a switch. I did notice however there were portions of code marked â//Todo laterâ so iâm guessing its not a complete product. So I agree with you guys that a step by step approach is better. So with my sincere apologies please forget about it. Was just having fun.
Itâs great that this brings you fun, @davidm71 , way to go! Just wanted to warn you: if you want to share your tool and want others to use it - be prepared of the constant stream of âplease patch my BIOSâ, âwhy is this shit not working?!â and âyou need to pay for repairing my motherboard!!!â
I very much encourage everyone to share the knowledge and have fun with BIOS modifications, but thereâs also a big chunk of people who donât understand that we arenât a tech support, we donât have to help anyone with anything and we wonât be hold responsible for anything that they read here.
The whole FW modding community really need people like you, @davidm71 , so please donât stop tinkering and having fun because Iâve said something. I wonât be where Iâm now without UEFITool, and I still think that âautomate everythingâ is a bad idea, but I donât discourage you from doing anything or releasing anything.
Well you do make sense. I tested this tool out on a half dozen bios files but there was one from Asus that was strange enough to make it say âImage implodedâ so I guess there will be the rare compatibility glitches and who needs the headache and worry that someoneâs board got bricked. Thanks for the encouragement though. Thank you.
@fernando I final installed my SM961 drive, but I have run into an issue.
I followed the steps outlined in the tutorial and I was able to install Win10 on the Nvme drive. However, I am still unable to boot from it. I suspect that it is either an issue with how the BIOS was flashed or a setting within the BIOS that I need to change.
1. I extracted the 3 Nvme ffs files from an ASUS Sabertooth BIOS and inserted them into my MB BIOS at CSMCORE. I flashed the BIOS without issue. Note that the Sabertooth BIOS was a .cap and my MB was .rom. Would that affect it? I opened the modded BIOS and see the three Nvme files, soâŚ
2. I see Windows Boot Manager as a boot option. However, I do not have settings for secure boot or CSM setting. Iâve unplugged the other drives and tried disabling the SATA controller. My BIOS does have an override boot to allow direct boot of a disk - this works with other drives but not the Nvme. Iâm not sure why I can see it, but cannot boot to it.
MB: ASUS Crosshair V Formula
BIOS: 1703 & 1605
@Antibear,
I have a Sabertooth X99 mboard and never see 3 different NVMe BIOS modules into BIOS v3402.
I think only one NVMe module does exist.
Are you sure ?
No, these are the names of the 3 NVMe modules, which are within the Sabertooth X99 BIOS 3402:
1. NvmeInt13
2. Nvme (the equivalent to the NvmExpressDxE module)
3. NvmeSmm
@Fernando ,
UBU tools does display only one NVMe module is present.
So, this is confusing.
UEFI_Tool does detect (via âsearchâ option) 7 occurrences of ânvmeâ text,and yes, you are right, 3 different nvme modules can be found.
Are all of them used by the system when booting ? or after booting ?
Or only one, or two are used ?
Interdependancy between them ?
Is âNVMEâ module the only one detected by UBU scanning ?
Lot of mysters for me.
UBU is correct. There is only 1 "real" Nvme module within the BIOS and its name is Nvme. The other 2 have the letters "Nvme" within their names and are Nvme related, but are not required for being able to boot off an NVMe SSD.