PLX is a PCIe lane switch (PCie lane endpoint manager), it does not have any more features than this or RAID related.
The card needs additional resources for additional features support, like RAID and boot, so thats what you need to look for.
That could be in the future …who knows… the next GEN of self-aware bios interface that would detect additional cards and their controllers providing/uncovering additional menu settings to control her functions…
But we’re not there yet… so answering your question, the bios can control the embedded controllers of her chipset, The Intel C600 AHCI/RAID and additional ones present in the mainboard, only.
The bios detects additional hw interfaces but cannot set/config her functions, this is usually done on the card when she possesses an Option Rom FW (OpROM) during the platform initialization.
So when looking for a card with RAID support, usually it comes with a OpRom of the controller used, ex.: Marvell, ASmedia, HighPoint, etc…
Why is it recommended to turn off Secure Boot? Won’t it work at all with these NVMe drivers?
I have an Asrock Z77 Extreme4. There is an official BIOS from 2017 with NVMe support, but also a newer one from 2018 without NVMe but with some microcode updates and possibly other fixes. I want to add the latest microcode and other modules with UBU anyway, but should I rather use the official, older NVMe BIOS as base file or the newer one and add the NVMe drivers provided in this thread?
For reference, the official BIOS files I mentioned: https://www.asrock.com/mb/Intel/Z77%20Extreme4/#BIOS
Because otherwise you may not be able to get the OS properly installed onto the NVMe SSD.
Once the OS installation has been completed you can try to set “Secure Boot” to “Enabled”. This way you can verify yourself whether disabling this BIOS setting is permanently required or not.
Your other questions are off-topic. It is up to you to find out which BIOS version is the better source for your specific system.
Thanks; if there’s no specific problem with Secure Boot I’ll just use the latest BIOS version. I guess the DXE drivers from the forum have no disadvantages compared to those provided by Asrock?
I updated the microcode etc. with UBU and then tried to add the NVMe driver with MMtool but it reported ‘not enough space’, even with the small compressed driver, but UEFItool inserted even the large driver without error message, however I then went with the small one. I read an opinion on the forum that the small one might even be faster. What are the advantages of the large one?
The BIOS that I produced works so far, but I haven’t installed the NVMe drive yet.
Also the link in the first post appears to be broken, about how to compare the BIOS files in UEFItool to check for problems with the padding files. How do you do that? I can’t find the posting that this is referring to: https://winraid.level1techs.com/t871f50-Guide-How-to-get-full-NVMe-support-for-all-Systems-with-an-AMI-UEFI-BIOS-255.html#msg66135
I was browsing some of the modded bioses posted on the forum, and I notice some of them also contain the SAMSUNG_M2_DXE.ffs
Should both SAMSUNG_M2_DXE.ffs and NvmExpressDxe_5.ffs be included in the bios? Or is just the Nvm Dxe enough? Is there any harm/benefit having them both.
BTW, I will be using one of these:
SSD Samsung 970 EVO PLUS, M.2 - 1TB
or Samsung SSD 980 PRO, M.2 - 1TB
The SAMSUNG_M2_DXE module is only needed for being able to boot of an M2 SSD, which uses the AHCI data transfer protocol.
Since all your listed M2 SSDs use the NVMe protocol, only the insertion of the NVMe module makes sense.
Reporting success.
Thank you @Fernando for the help and the guide.
For ASUS users with CAP bios: You can mod your CAP with MMOtool and than simply flash the modded CAP with USB BFB (bios flashback function, if your motherboard supports that). More specifically, no need for ROM extraction steps (and re-capsuling in CAP) in this use case scenario.
I’ve tried to follow the guide for a Supermicro X10SAE Motherboard. Upon inserting the NVMe modue, I am noticing that a pre-existing Pad-File is removed. This appears to be the case when inserting the module with both MMTool and UEFITool. Below is a screenshot displaying the original on the left and the mod on the right.
Please see attached. This is the exact same file hosted on the manufacturer’s website, which not only includes the BIOS image but the readme and utilities.
@hethspd
The proper insertion of the NVMe module into your specific mainboard BIOS is more difficult than I thought. Unfortunately I don’t have currently the required time to solve your problem.
@hethspd
As the MMTool 5.x reports successful insertion of the Small variant, regarding volume space (besides the pad error) i would be using the UEFI_tool0.28 to insert the same variant.
Or if you wish to use the standard variants, you may try the method of removing unnecessary drivers, related to UEFI DXE network boot drivers.
Im not providing any files here, because it seems you’re a capable user and fully understands the processes, give it a try and ensure you have backups and recovery methods, good luck.
EDIT: I made another test with older MMTool 4.x and the insertion of the small variant is also OK with original Pad still present, so plenty to choose.
@MeatWar - Thank you for taking a look and providing advice. I’m still struggling to make sure that the Pad-files are retained from the pure image. I’ve tried to insert the NVMe module using MMTool4.x instead of MMTool5.x as you suggested. Below is specific version information.
As you have mentioned, the Pad-File after the DXE Volume appears to be intact with both MMTool and UEFITool as illustrated below.
However I now seem to be losing the Pad-Files before the DXE Volume as illustrated below. MMTool further seems to remove records with GUID 05CA01FC-0FC1-11DC-9011-00173153EBA8.
Humm… didnt checked those ones, usually we check end volume.
Indeed all options i elaborated will remove them and they got data… even getting more space and using other variants…
Tried to extract/insert/replaced, neither worked also, the volume is always modified…
We can try another method, make an FPT dump of the bios_region only, not AMI AFU backups.
Then try again all the methods we already know here… but do not get many hopes, this one is tricky.
Its a risk but it still could work if flashed… but dont do it if you cant recover it.
EDIT: Tomorrow il check other Supermicro X10 confirmed success reports here on forum and will analyse their structure ori/mod, this was never noticed and it works or this one is a damm pain…
