I’ve created a modded version of the VMware NVMe Option ROM to use memory-mapped I/O (MMIO) instead of index-data register pair (IDP) access to the device. Note that IDP is optional and is not implemented by most devices.
The modded Option ROM should be compatible with all PCIe NVMe SSD’s and modern operating systems, such as Windows 10 and Linux.
Please use the included OpRomCfg to configure vendor ID and device ID because other tools might damage the Option ROM.
Important Hint (added by Fernando):
Just to prevent a serious misunderstanding and wasted time by trying to customize the offered NvmeOpRom module with not matching HardwareIDs, I want to make clear, that the user has to customize the VendorID and the DeviceID of the NVMe Controller, which is within the SSD (and not of the SSD itself}.
About to flash and test your mod but I am getting a different checksum when I use my tools on the nvmeoprom file after changing the vendor device id. Are you sure your app is configuring the checksum correctly?
I’ve created OpRomCfg because I could only find tools that seem to be specific to an Option ROM and change other things too, not just Vendor ID, Device ID and checksum.
Please compare the two versions (both with proper Vendor ID and Device ID). Checksum is only the very last byte. If your tools change any other byte then the checksum is expected to be different, but those other changes are most likely corrupting the ROM.
Well with your utility the checksum at the bottom was 89 which differred from my checksum correction utility which gave me 39. In anycase got a checksum error when I tried to post using your utility. Not with mine but got no idea if the rom even loaded because it doesnt post any startup messages.
There are three files in the 7Zip file. OpRom.bin which was created after running it through my patch64 utility, and nvmeoprom.bin which was created using your utility with device ids: 4D14 04A8
Thanks
PS: Not really my utility but one I compiled using Pinzaccos source code.
@davidm71 : When comparing NvmeOpRom.bin and OpRom.bin in nvme_opt_rom.7z, byte at position 0xED is 0x26 in NvmeOpRom.bin while is 0x76 in OpRom.bin. This 0x50 difference is correctly reflected in the checksum of both files.
Note that 0x26 is the correct value at position 0xED because that is in the original, unconfigured NvmeOpRom.bin too.
As a conclusion, I belive that both files have correct checksum, one byte of OpRom.bin however was corrupted by patch64.exe and as such I cannot recommend the use of patch64.exe.
I have a GA-970A-UD3 and trying to find a way to edit the bios to boot to a plextor m9pey 512g ssd pcie. Would this work with that? Can I use award bios editor to add it in? would I just add another pci driver? also the vendor ID and device ID would that befor the motherboard or the card?
@Flaky I’m glad to hear that. Were there any changes necessary? Could you please specify the exact model of the mother board, the BIOS version and the NVMe SSD model.
I did insert the module using MMTool3. I had to remove LAN Option ROM first, as the space is limited. At first I did use the OpRomCfg to fill the module with vid/did, but the bios is also happy with unmodified version - it seems inputting the vid/did during insertion with mmtool is enough.
@Ethaniel - thanks for your experimental rom, I would test on many boards/BIOS but no NVME here, however Fernando and I were just discussing about somehow making such a module, maybe he’s missed this post until now?
@Fernando - care to do some tests with this when time permits? I’m just interested in general functionality of the rom, does it work as good/easily as UEFI NVME module we use now, how difficult do you think it would be for most (non-tech knowledgeable) users to use the checksum tool and ID insert etc?
I’d be happy to test this on more boards, but unfortunately I have nothing based on phoenix/award on my hands right now.
There are two things which make this less feasible for general audience: 1. Different tools depending on bios (with uefi it is simpler, because in most consumer motherboards there is AMI UEFI) 2. Mod is done for one particular drive, so it is not an universal modification
First one can be solved by creating a script/tool for that. Second…
@Ethaniel Could a module be done in such a way that instead of specifying VID/DID of the drive, we would specify PCIe root port/controller on which the module should expect an NVMe drive? For example, on this particular board: x16 slot - 8086:29C1 x1 slot - 8086:27D0
That would allow us to create more universal bioses (e.g. bios for motherboard X with one NVMe-enabled slot), but I have no idea what would be the effort for such a thing.
@Flaky - what type of AMI BIOS boards could you test, do you have anything newer than the G31? Did you ever test and compare the normal NVME mod vs this module on the G31 BIOS?
@Lost_N_BIOS I’ve just checked this module on Asrock 960GC-GS FX - works fine. And again, no need to do configuration using OpRomCfg, as entering vid/did in mmtool seems sufficient.
I am not really sure what you mean by “normal NVMe mod”. Previously I have had only done simple UEFI mods, and never really bothered with duet/clover.
