@mireque : Thanks for your detailed reply. If I understand you correctly, your answer to my last post’s question is "Probably yes!". So it has to be verified of the users, whether your method is successful with other LEGACY mode chipsets and whether the "easy way" to use the NVMe SSD as system drive, which I have described within my last post, works as well.
Yes, no matter where the boot sector is (on a bootable USB Flash Drive or on a bootable SATA connected Disk Drive), the user will not boot off, but into the PCIe connected NVMe SSD. So the title of this thread is not 100% correct regarding the methods we are talking.
Another (functional) boot device is always needed (hard disk or usb device), using a standalone NVMe or PCIe SSD with no other disks will not be possible.
I can’t imagine who would care about the extra layer. BIOS’s routinely add layers upon layers before it actually boots a device anyway. If the extra layer bothers anyone all they have to do is disable a few of them within their BIOS. I plan on getting TWO M.2 SSDs and completely turning off my SATA ports and USB 3.0 ports entirely. I now use a USB 3.1 card, for USB 3.0 devices anyway and a VERY nice USB 3.0 hub. So the back ports are useless to me. That’s one layer now gone that frees up PCIe lanes. SATA ports will also be disabled to free up resources and time within the BIOS. I have 5 PCIe ports that all comply with at least the x4 requirement of M.2 SSD’s that I can use, one for the GPU, one for the USB 3.1 card and TWO for the SSD’s. Having a dedicated USB 2.0 device (I have the perfect super fast USB 2.0 drive already present for this type of thing) for this procedure is perfectly OK with me if it allows me to take advantage of my PCIe’s underlying speeds over the SATA bottleneck.
My only thought is if its possible to use this DUET dual booting method using a MBR partition format it using EXT4 instead, or something Windows 10 can not see? Or is that already the case with the DUET partition, is it a hidden partition? Once Windows boots it would be really nice if the device that is loading Windows isn’t visible to the Windows system, except for maybe inside the Disk Manager of course.
Another thought I have is, does this method allow Windows to load and use the Samsung drivers for the SSD?
I’ve reread your post again and now finally understand what you’ve asked. I’ve made small correction in my reply.
- If you’ve meant the bootsector of the Windows 10 (or anything related to Windows 10 bootloader/boot manager), no, that’s not present on the DUET USB disk, it’s still present on the NVMe SSD, but DUET bootloader (UEFI Shell to be precise) that boots from the DUET USB stick then executes the Windows 10 bootloader (\EFI\Boot\Bootx64.efi image) that is present on the hidden FAT partition on the NVMe SSD, and it executes it directly - NVMe bootsector is not used, not needed because you’re executing (via DUET/UEFI Shell) the raw bootloader from the NVMe SSD directly. DUET is able to access that hidden boot partition thanks to the NvmExpress-*.efi driver and also Windows 10 is accessing the NVMe disk using UEFI block read/write methods, not via BIOS direct access.
I hope I have clarified what you’ve asked. Feel free to ask if you need some more explanation though.
please read my last two detailed answers to Fernando’s questions, I hope everything is explained there. Also I hope I’ve thoroughly explained everything in my tutorial article, that has been just updated to also reflect these questions you and Fernando have asked
DUET USB stick is only BOOTLOADER and UEFI support layer for legacy BIOS, nothing else. There’s nothing from Windows bootloader / bootmanager there, it’s not needed, because DUET can execute directly from the NVMe
DUET uses GENERIC NVM-Express UEFI driver to be able to access NVMe SSD’s (but this is the layer before Windows uses its own NVMe driver or the one manufacturer provides, if running before Windows 8). If particular NVMe SSD correctly implements NVMe standard (and it should), then yes, DUET will be able to access it and Windows will be able to access it.
Look at it this way:
Computer power on -> LEGACY BIOS start/init -> DUET MBR boot from USB stick -> DUET executes UEFI Shell -> UEFI Shell loads Generic NVMExpress.efi driver and remaps system block devices -> UEFI Shell sees Windows 10 hidden FAT partition DIRECTLY on the NVMe -> UEFI Shell executes Windows 10 UEFI bootloader from that FAT partion directly (\EFI\Boot\Bootx64.efi image) -> Windows 10 is now booting (under UEFI mode, of course)
DUET is just a helper and UEFI layer above the legacy BIOS. That’s what the authors intended.
I wasn’t confused, I already read everything and it is all VERY clear to me, so thank you for that. My questions were outside of what you covered in your guide. Is the USB DUET device visible from Windows after windows has already loaded? I mean can you see it with your eyes in your file manager and thus possibly manipulate or accidentally destroy your DUET? This was not answered in your guide as far as I can tell.
Also, you answered my other question about using Samsung drivers for the full effect of the SSD performance, so thank you for that. That also wasn’t in your guide because its just not necessary information and I understand that. Your guide is perfect as it is, thank you.
One more question though, are these files for download in your guide publicly available and kept up to date at all times? Or should we make backups of them at cloud storage places like MEGA or Dropbox? I guess I am asking if the links/files are safe and will always be available? Is DUET an ongoing open project (I haven’t done any searches for it yet)? And did DUET create this method to boot NVMe SSD’s, or did you put it together yourself? The reason I ask these questions is because I am the maintainer of the Samsung 960 thread at Overclock.net and I need important information so I don’t accidentally tell lies to the public, haha. Hope that makes the reason for all these questions more clear and understandable. Thank you very much mireque.
The DUET USB stick is visible to Windows because it’s a regular FAT partition, but I just removed its drive letter from the Windows Disk Management after installation to not show it in Windows explorer for convenience. I will mention this in the article, thanks for reminding me that.
- All of the files (duet, uefi drivers and uefi shell) are publicly available, the versions I use in the article and recommend are hosted at my Mega account, and I don’t have any intentions to remove them, nor update at the moment - after running all of this for about a month without any problems, it seems stable enough in these versions - hopefully they will last on Mega for quite some time But in any case, I have those files always backed up personally because if I were to lost them and something ever goes wrong with my DUET USB stick (hopefully not because I have bought a new one, dedicated to this purpose), I would probably have problems with booting my NVMe
- DUET is an integral part of TianoCore EDK II project (opensource UEFI platform), and that project still lives afaik. But it’s somehow very hard to compile the latest TianoCore EDK II from sources (which I have unsuccessfully tried by myself several times because I wanted the very latest DUET version). Instead, I have just used the very last DUET binary version the folks from TianoCore have provided to public, and it’s the version from November 2013 implementing UEFI v2.31. However, it’s perfectly stable (been running it for about a month flawlessly), so I don’t see the need to replace it nor suggest any newer version of the DUET at the moment. But do not confuse DUET with the NVMe and XHCI drivers (NvmExpressDxe-64.efi, XhciDxe-64.efi) that DUET / UEFI Shell needs to access your NVMe - these are the versions compiled and provided by Clover team (it seems they succeeded in compiling the latest TianoCore EDK II, and I have used Clover revision 3949 from Nov 2016). To me, that all of this works this stable (combination of DUET from 2013 + fresh UEFI NVMe / XHCI drivers from 2016), is a testament of quality of the code of the DUET (respectively the opensource TianoCore UEFI implementation) itself. Insane, but the UEFI interface seems properly defined and very well executed.
- DUET just implements the UEFI interface on top of existing legacy BIOSes, just like the newest UEFI-only motherboards implement UEFI interface directly (without legacy BIOS code). And by implemeting UEFI interface, with proper UEFI driver (NvmExpressDxe-64.efi), it can access your NVMe directly and then it can execute the Windows bootloader directly from the NVMe - I haven’t invented how UEFI works, folks at Intel did. I just did tons of research on this topic because I was in need of new SSD for my X58 platform, and NVMe caught my attention. That research has paid off in the form of that article that I put together.
- (Btw, I have also shared my success at Overclock.net in some threads - feel free to spread it how you like, so most legacy users like us can benefit from all of this).
Utterly brilliant to say the least. The only thing that could possibly beat this is actual BIOS modifications. But I have no problem at all with an implementation such as this.
One last question, is the XHCI drivers for accessing your USB 3.0 drive? My Rampage III Extreme does not boot USB 3.0 devices (unless I use the USB 2.0 port of course), so I would be forced to use USB 2.0. I have some old but very fast HyperX and OCZ USB 2.0 drives I retired years ago. These are top of the line USB 2.0 flash drives and just as fast as any USB 3.0 drive on a USB 2.0 port. Again, I do not have any working USB 3.0 ports on my board that are seen in my BIOS, so I wouldn’t be able to use DUET on a USB 3.0 port. I tried to solve this problem for the past few years but it seems Asus did NOT make my USB 3.0 ports bootable, for some very odd reason.
So I have to use USB 2.0 ports to boot DUET from. I naturally assume this is perfectly OK? And the reason why I ask is because I thought XHCI was a USB 3.0 driver? If that’s the case, would I even need that driver since my BIOS can’t see those ports anyway??
Booting DUET is of course always performed from USB 2.0 stick, because USB 2.0 is guaranteed to boot on X58.
I’ve needed XHCI (USB 3.0) driver because I’ve got the Windows 10 installation media on USB 3.0 stick that was attached to my NEC PCI-e USB 3.0 addin card.
You can of course prepare and use another USB 2.0 stick with Windows UEFI installation media - then you’ll not need to load XHCI driver and that USB stick will be visible right out of the box in the UEFI Shell. But in this case, filesystems FS0 and FS1 can be swapped, because only X58 chipset decides which USB 2.0 stick is initialized first on your system. If NvmExpress-*.efi can’t be loaded from FS0 because it simply is not found, then try loading it from FS1. I’ve written the article in a partial hurry and I’ve missed to mention that of course, using USB 2.0 for Windows install is possible and USB 3.0 is optional. But anyway, I just wanted to write exactly how I did it - using USB 3.0, and to avoid confusion of swapping filesystems which I have experienced. I will mention this in the article, but need to figure out how to write it as simple as possible to not cause confusion.
Btw, this was the fastest installation of Windows OS in my life - it literally took cca 2minutes to restart and then one more minute to complete the installation (using USB 3.0 + Nvme) - just crazy
I think I will give this duet a try just to see how it works and possibly make some adjustments for my particular system. Maybe I can use duet to load xhci drivers, and just maybe have it point to my usb 3.1 add-in card. With any luck maybe I can also install Windows from a USB 3.0 device.
Thanks again for your time and effort getting something working for people who want to use nvme on older systems.
Do you happen to know if DUET can see other USB chips on the PCIe bus, such as my Gigabyte GC-USB3.1 x4 card? I am wondering if I can build the DUET device on a USB 2.0 flash drive, insert that flash drive into a USB 2.0 port (so the BIOS see’s it), boot to the DUET but then have the “startup.nsh” point to the Windows 10 setup files on my SanDisk Extreme connected to that super fast USB 3.1 card? Like I said, I will have to play around for sure, lol.
I assume I would have to somehow find a command to ask DUET if it see’s the SanDisk flash drive on the USB 3.1 card, and if it does figure out what drive number assignment it has been given so I can use that information in the automated “startup.nsh”.
I’ve got some good news to share - I’ve finally managed to compile the latest stable TianoCore EDK2 sources (the UDK2015 release, UEFI v2.5) with UEFI drivers (NVMe + XHCI) compiled directly into DUET (no need to load drivers now). If this proves stable over time (I’m currently running / testing it now), I’ll most probably release it - then the whole tutorial / process will be much easier to do. Will let you know for sure.
Thx for the work so far. But mine hangs when trying to install the drivers in the UEFI shell after the success line. This update with drivers pre installed may be an instant fix for me I think if you have it working. Trying to run a 960 evo on a p8p67 evo board.
@mireque : The topic “Usage of an NVMe SSD with natively not supported systems” is meanwhile very popular. That is why I decided to create a new Sub-Forum within the “Storage Drivers” section named “NVMe Drivers (incl. NVMe Support without BIOS Modding)”. Since you have written a very interesting guide about how to get full NVMe support with a LEGACY mode Intel X58 Chipset system, I have moved the related thread into the new Sub-Forum and hope, that this is ok for you. Nevertheless this is in my eyes not the final solution, because a) the related thread should start with your guide resp. the presentation of your method and b) the current thread title given by the thread starter does not really indicate, that it contains the presentation of your “DUET-USB Boot Method”. As a consequence I would rather like to split this thread into 2 separate ones and to set >this< post as starter of a separate “stickied” thread with a title like “How to get an NVMe SSD bootable with LEGACY Systems (DUET-USB Boot Method)”. What do you you think about this idea?
Thought you would like to know that I finally bit the bullet and got the SM961 256GB. I then used your method and the clover method here and both work really good. The DUET method though is much faster for some reason and shaved 8 seconds off my bootup to desktop. The Clover method doesn’t auto boot Windows 10 though, it just boots up to the Clover UI. I then have to manually select Windows 10 EFI Boot in order to actually boot Windows. Not sure why that is because I followed the directions to the letter.
But DUET boots to desktop in 22 seconds flat from system power-on, when my legacy BIOS using Samsung 840 Pro AHCI took 30 seconds. I gave clover a super fast Sandisk Extreme USB too, and gave DUET the slowest 8GB USB 2.0 I had, a $1 special drive LOL. DUET is amazing as it is on my x58. I only wish we could figure out how to get rid of the “startup.nsh” timeout ( set to 0 or 1 ) because that would boot my system like a brand new 2017 system practically.
Wanted to let you know I actually got rid of that timeout with “Startup.nsh’” and suppressed its video output so nothing or no text is displayed on the screen on my X58 system. I did this by messing with Duet’s source code and compiling it myself. Happy to share the files if you want. If I could only replace the ‘Tianocore’ logo with EVGA I’d be happy.
Wow, thank you. Yeah the display doesn’t bother me none. However, 0 seconds timeout is great. Can you still use Esc to enter UEFI shell if needed for something else perhaps, just have to do it quicker?
I wanted to try out Clover because it is themeable, and like you I wanted something more in-line with my Asus ROG boards theme, something maybe that looks like the Asus UEFI menus of today lol. But like I said I have no clue how to set Clover to autoboot and I need to do that before I can leave DUET. And I believe the startup.nsh only works on clover when you actually select UEFI Shell from the main UI menu of Clover. Maybe I should actually try using a startup.nsh before I deem it non functional. So until I get Clover autobooting Windows I have to say DUET is better for our older systems.
I will give your DUET a try and see if I can break under 20 seconds boot time. That would be crazy awesome on x58 to say the least. Thanks again…
EDIT by Fernando: Unneeded part of the fully quoted post removed (to save space)
I just found this post which solved my Clover issue. Since Clover is easily edited for timeout, it now beats DUET in booting my Windows 10 from power on to desktop in 19 seconds. Apparently it was DUET taking longer to boot Windows because now test after test its taking about 31 seconds for DUET to get me to desktop. Even if I managed to use 0 timeout on DUET, it would still lose to Clover’s speed. Tomorrow I need to test further if it is the usb drives themselves that are giving me the greatest differences, or the efi programs. Not that any of this is of true concern, a few seconds here or there, blah, its just that I have plenty of USB drives and I might as well use the one that provides the fastest stable Clover or DUET EFI boot, especially if we are talking nearly ten seconds difference with just the right setup.
Now I can research how to theme Clover and possibly get myself an Asus ROG theme going on when I need to boot Linux live sessions
EDIT by Fernando: Unneeded and already previously quoted post removed (to save space)
