Reminds me of editing NVMe support into my Supermicro X9DR7-LN4F server mainboard (Sandy/Ivy Bridge) I have at home. It involved "unpacking" the 'BIOS' (UEFI) image, adding an NVMe module that was published somewhere (I think it was actually generic, as in plain UEFI and not specific to the BIOS vendor, AMI in this case), repacking it, and then flashing it on the mainboard (with clenched buttcheeks — I'm not sure this board has a recovery mode…)
(It works perfectly to this day.)
It's a little sad that Supermicro didn't do this at their end, it's maybe an hour of work, two with testing…
inclusion of the NVMe DXE trifecta (Nvme, NvmeSmm, NVMEINT13)
Now that I think about it, this sounds very much like what I threw into the X9DR7-LN4F BIOS image.
Ed.: apparently these are the files I used, though I cannot dig up how or where I did this :)
-rw-r--r-- 1 41917 May 28 2020 P-X9DR7-E-LN4F_BIOS_3_3_release_notes.pdf
-rw-r--r-- 1 30493975 May 28 2020 FD12LITE.zip
-rw-r--r-- 1 16293994 May 28 2020 Aptio_V_AMI_Firmware_Update_Utility.zip
-rw-r--r-- 1 818096 May 28 2020 UEFI_Shell_Spec_2_0.pdf
-rw-r--r-- 1 2104626 May 28 2020 AMIBCP 4.53.zip
-rw-r--r-- 1 5910147 May 28 2020 UEFITool_v0.27.0.rar
-rw-r--r-- 1 10665 May 28 2020 NvmExpressDxe_4.rar
-rw-r--r-- 1 404236 May 28 2020 MMTool 4.50.0.23.zip
-rw-r--r-- 1 6150536 May 28 2020 Aptio_4_AMI_Firmware_Update_Utility.zip
Frankenstein motherboards direct from Shenzhen with recycled parts and features that didn't exist at the time that allow me to strip out high core count Xeons and max-capacity ECC DIMMs from servers being tossed at work and shove them in standard mATX/ATX motherboards in tiny quiet cases at home for my homelab.
Plus, the recyclers add in NVMe boot support (and M.2 slots) at the factory!
Do a search for x79 and x99. Or the socket type of your preferred xeon chip.
People recommend the machinist brand motherboards. I've had good experience with the Killrser (typo) brand.
At the prices you see it seems too good to be true but those xeon CPU/motherboard/ram kits are the real deal. It's mind blowing buying a Xeon processor for the price of a cup of coffee.
If you live in an area with low electricity costs, or a cold climate where the computer ends up heating your house it's a hell of a deal.
Check out YouTube for reviews and gaming benchmarks on these systems too.
I did something similar, I patched a Gigabyte Z77-DS3H bios with the SAMSUNG_M2_DXE module to get a Samsung SM951 AHCI M.2 SSD working. It's not SATA and not quite NVMe, PCIe AHCI existed for a short while before NVMe became ubiquitous.
This was to enable a screamer of a Hackintosh based on Mavericks which didn't have native NVMe support at the time.
…AHCI is the SATA controller standard, how and why did they put in extra effort to make it not work?!? (I'm not questioning they did in fact break it, it's in line with other dumb things HW vendors do… just… ugh!)
Well m.2 sata would be using one lane as sata with an ahci controller elsewhere (probably embedded in a chipset or cpu).
PCIe AHCI have the controller on the m.2 device, maybe better than sata speeds? But I think to boot from an unexpected AHCI controller you might need a boot rom? And why would you put a boot rom on a device that's all about storage?
But I think to boot from an unexpected AHCI controller you might need a boot rom?
The whole point of AHCI was that you wouldn't need a boot ROM. You already have firmware support for talking to an AHCI controller to find drives and locate an operating system, because that's how the system boots off the built-in SATA ports. The firmware modules required to do the same with an AHCI add-in card are the firmware modules you're already using, so the add-in card doesn't need to bring them along in an option ROM. Same for drivers in the OS.
Most likely, the motherboards in question simply never implemented code to probe for any other AHCI devices beyond the built-in one, and would have been equally unable to boot from an AHCI controller card providing more SATA ports.
Definitely was faster than standard SATA but nowhere near NVMe potential. It still came with all the AHCI warts as AHCI was optimized for spinning disks and had 32 commands per queue, while NVMe supports up to 64,000 and so on and so forth. The major limiting factor was utilizing SATA-based command structures over PCIe.
My guess is at the time it was a familiar protocol stack which apparently made it easier to retrofit legacy systems before NVMe? AHCI was already well-supported across major OSes then (Windows, Linux, macOS), but UEFI firmware still needed to understand this abomination.
yes, it can flash new "bios" from USB in case of bad update. this function is inate to intel "chipset" so every motherboard with direct to "chipset" connected usb port can recover bad update.
but you need to have usb flashdrive connected for long time, like 5 minutes or so, after powerup, without leds blinking so it can be scary / confusing.
Comments
Reminds me of editing NVMe support into my Supermicro X9DR7-LN4F server mainboard (Sandy/Ivy Bridge) I have at home. It involved "unpacking" the 'BIOS' (UEFI) image, adding an NVMe module that was published somewhere (I think it was actually generic, as in plain UEFI and not specific to the BIOS vendor, AMI in this case), repacking it, and then flashing it on the mainboard (with clenched buttcheeks — I'm not sure this board has a recovery mode…)
(It works perfectly to this day.)
It's a little sad that Supermicro didn't do this at their end, it's maybe an hour of work, two with testing…
Now that I think about it, this sounds very much like what I threw into the X9DR7-LN4F BIOS image.
Ed.: apparently these are the files I used, though I cannot dig up how or where I did this :)
(…10kB compressed for the actual NVMe DXE…)I take the even riskier route.
Frankenstein motherboards direct from Shenzhen with recycled parts and features that didn't exist at the time that allow me to strip out high core count Xeons and max-capacity ECC DIMMs from servers being tossed at work and shove them in standard mATX/ATX motherboards in tiny quiet cases at home for my homelab.
Plus, the recyclers add in NVMe boot support (and M.2 slots) at the factory!
Now that's intriguing. I presume you underclock/undervolt them or something to keep the thermals reasonable without jet-engine-level fans?
you need to underclock/undervolt for motherboard to handle energy flowing into it.
big desktop cooler for example Corsair A115 can cool 250W TDP under 40db
for sandy bridge XEONS - 2/3 of CPUs were under 100 w TDP, all of them were under 150W TDP
Well, that sounds fun. Do you find these boards on AliExpress?
Do a search for x79 and x99. Or the socket type of your preferred xeon chip.
People recommend the machinist brand motherboards. I've had good experience with the Killrser (typo) brand.
At the prices you see it seems too good to be true but those xeon CPU/motherboard/ram kits are the real deal. It's mind blowing buying a Xeon processor for the price of a cup of coffee.
If you live in an area with low electricity costs, or a cold climate where the computer ends up heating your house it's a hell of a deal.
Check out YouTube for reviews and gaming benchmarks on these systems too.
I did something similar, I patched a Gigabyte Z77-DS3H bios with the SAMSUNG_M2_DXE module to get a Samsung SM951 AHCI M.2 SSD working. It's not SATA and not quite NVMe, PCIe AHCI existed for a short while before NVMe became ubiquitous.
This was to enable a screamer of a Hackintosh based on Mavericks which didn't have native NVMe support at the time.
…AHCI is the SATA controller standard, how and why did they put in extra effort to make it not work?!? (I'm not questioning they did in fact break it, it's in line with other dumb things HW vendors do… just… ugh!)
Well m.2 sata would be using one lane as sata with an ahci controller elsewhere (probably embedded in a chipset or cpu).
PCIe AHCI have the controller on the m.2 device, maybe better than sata speeds? But I think to boot from an unexpected AHCI controller you might need a boot rom? And why would you put a boot rom on a device that's all about storage?
The whole point of AHCI was that you wouldn't need a boot ROM. You already have firmware support for talking to an AHCI controller to find drives and locate an operating system, because that's how the system boots off the built-in SATA ports. The firmware modules required to do the same with an AHCI add-in card are the firmware modules you're already using, so the add-in card doesn't need to bring them along in an option ROM. Same for drivers in the OS.
Most likely, the motherboards in question simply never implemented code to probe for any other AHCI devices beyond the built-in one, and would have been equally unable to boot from an AHCI controller card providing more SATA ports.
Definitely was faster than standard SATA but nowhere near NVMe potential. It still came with all the AHCI warts as AHCI was optimized for spinning disks and had 32 commands per queue, while NVMe supports up to 64,000 and so on and so forth. The major limiting factor was utilizing SATA-based command structures over PCIe.
My guess is at the time it was a familiar protocol stack which apparently made it easier to retrofit legacy systems before NVMe? AHCI was already well-supported across major OSes then (Windows, Linux, macOS), but UEFI firmware still needed to understand this abomination.
I followed a tutorial a couple of years ago to add NVMe support to an ASUS MAXIMUS VII GENE. Worked great!
(I think it was this one: https://winraid.level1techs.com/t/howto-get-full-nvme-suppor... Also praise be to Level1Techs and ArchiveTeam I think for rescuing it along with the rest of Win-Raid)
yes, it can flash new "bios" from USB in case of bad update. this function is inate to intel "chipset" so every motherboard with direct to "chipset" connected usb port can recover bad update.
but you need to have usb flashdrive connected for long time, like 5 minutes or so, after powerup, without leds blinking so it can be scary / confusing.
fat32 formatted drive.
good to know, luckily I didn't need it :)
I'm not sure any of this is possible nowadays, I'm assuming a modified BIOS/UEFI image would be rejected due to missing some vendor signature…
i can not comment on icelake or newer. but i can say a lot of insane ↕ things can be found on russian / chinese forums.