[b][/b]
[i][/i]
[u][/u]
[s][/s]
[code][/code]
[quote][/quote]
[spoiler][/spoiler]
[url][/url]
[img][/img]
[video][/video]
Smileys
smile
smile2
spook
alien
zunge
rose
shy
clown
devil
death
flash
sick
heart
idee
frage
blush
smokin
mad
sad
wink
frown
crazy
grin
hmm
laugh
mund
oh
rolling_eyes
lil
oh2
shocked
cool
[mail][/mail]
[pre][/pre]
Farben
[rot][/rot]
[blau][/blau]
[gruen][/gruen]
[orange][/orange]
[lila][/lila]
[weiss][/weiss]
[schwarz][/schwarz]
mireque
Posts: 18 | Last online: 02.05.2017
Date registered
01.03.2016
Sex
male
    • Hi @humpelpuber,

      thank you for your report. From your screenshot, it looks like you aren't using the DUET method and its UEFI Shell as described in the article, but it seems like you've somehow gotten into UEFI shell of your ASUS Q87T mainboard (the first line clearly says it) ...

      But your new ASUS Q170T should work fine with your EVO, and even make it correctly bootable.

    • @Mrus

      Glad you've got it working. So now the startup.nsh resides in root folder of the DUET USB drive? If that's the case, it's interesting, because I've edited/created the startup.nsh via Notepad and saved into fs0:\EFI\Boot folder ...

      I've looked into UEFI Shell sources and actually the 5 sec waiting time is hardcoded here, so to change it one would need to recompile it from sources.

      Finally, would you mind sharing a little bit info about your setup you got this working on - chipset, cpu, nvme ssd?

    • @Mrus

      What kind of encoding does the startup.nsh file have? From the image you posted it looks like you are using Windows' notepad and afaik there is a option to set encoding upon saving.
      Maybe this could be the issue?

    • @Mrus

      I get it. It's up to the BIOS/chipset how it gets mapped, so fs0 for NVMe is probably okay and fs1 for USB seems fine too after remapping.

      Can you please try following:

      - When it boots to UEFI Shell, it will wait for cca 3-5 seconds before attempting to execute startup.nsh.
      - When you're waiting, try pressing Esc to get to the shell prompt directly.
      - What happens when you type in the prompt - fs0:\EFI\Boot\startup.nsh - does this startup.nsh script ever get executed or not?

      Thanks.

    • Hi @Mrus ,

      thanks for your report. First, I can see a mistake/typo in your startup.nsh script:

      fs0:\EFI\Boot\Bootx64.efi -> should be fs1:\EFI\Boot\Bootx64.efi (fs1 is the partition where the Windows 10 UEFI bootloader is located, not fs0).

      I can imagine if you'd be using using fs0 here then you'd be essentially "boot-looping" the UEFI Shell from the DUET USB stick and the real Windows 10 bootloader will never get executed.

      If this is not the case (you have a typo here), does startup.nsh ever execute? Can you please post some screenshots what the UEFI Shell is saying when trying to execute the startup.nsh script?

    • @Nyctophilia

      Thanks. I think we will have to wait for some other success reports from others before going anywhere forwards. Currently I'm testing the DUET from UDK2015, so far seems stable.

      I definitely encourage "legacy" users to try every method described on this forum to get their NVMe SSD booting (either yours method via Clover or the one I have written about).

      One cannot lose anything and 2017 is surely going to be the M.2 NVMe SSD year I guess :-)

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.06.2017

      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.

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.04.2017

      I've updated the article to also reflect situations when users do not have USB 3.0 ports / sticks and want to use USB 2.0 sticks only.

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.04.2017

      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 :-)

      Hope this helps.

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.03.2017

      - 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).

      Youre welcome @SkOrPn, my pleasure:)

    • Afaik, DUET was the first thing the folks at TianoCore did. If I am not mistaken (correct me if I am wrong), Clover team based its Clover bootloader on DUET.

      So, I'd definitely recommend using Clover if you plan doing hackintosh stuff, because Clover seems totally optimized for it (there are some many tweaks incorporated in it due to hackintosh).

      I'd definitely recommend using DUET for Windows, because it's the "original and purest implementation" of the stable UEFI standard, and it seems to works incredibly well on X58 platform, even in 2017 :)

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.03.2017

      Hello SkOrPn,

      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.

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.03.2017

      Hello Fernando,

      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.

    • mireque has written a new post "X58 Chipset with problems to boot off a PCIe connected SSD" 01.02.2017

      Hi Fernando,

      thanks for your reply. I probably understand what you've asked. I don't have any other platform than X58 to try this on, hence it's aimed at what worked 100% for me. Couple of remarks though (some of it is included in the Prerequisites section):


      - The boot sector is on the NVMe SSD (Windows installer does this), but DUET bootable USB stick via DUET accesses the FAT hidden system partition on the NVMe SSD where Windows 10 is installed via provided UEFI driver (NvmExpress-*.efi) and then just executes (= boots) the Windows 10 bootloader (that is \EFI\Boot\Bootx64.EFI image on the hidden Windows partition)

      - You need to have a free PCI-e slot for the M.2 to PCI-e adapter ;)

      - I have chosen USB 3.0 stick for Windows 10 installation mostly due to performance reasons and for differentiation of system block devices, you can of course also use USB 2.0 sticks to put Windows 10 install ISO on, but then it will be a little bit messed up in the UEFI Shell, and I didn't want to bother users with guessing game (unless the user is more experienced and wants to play with UEFI Shell) - so using USB 3.0 stick was the most straightforward way for me

      - You can use Windows 8.1 Pro too (I have been running it on the same setup before switching to Windows 10)

      - It is possible to use the other SATA disk as a boot device, BUT ...

      - ... because I have chosen Windows 10, I currently don't recommend using any other disk other than the NVMe in the system (especially for bootloaders, maybe as data disks should be fine), because in my experience and that really happened, Windows 10 had simply messed up bootsectors of my SATA drive (and this has been widely documented on the Internet that Windows 10 really act strange sometimes) and the bootloader on the SATA drive just went missing - I couldn't boot my NVMe from the SATA disk partition, therefore using USB sticks for bootloading seems like a better way - maybe Windows 8.1 Pro should be OK bootloaded from other SATA drive, but I definitely not recommend this for Windows 10 systems for now ..

      - Also, using other SATA disks may potentionally affect whole system performance, because Windows (even running from NVMe) is accessing those SATA disks - from my experience, I could clearly see difference in boot times when system was temporarily connected with my old SATA OCZ Vertex 2 drives in AHCI mode (as suggested in my tutorial)

      - Windows 8.1 and Windows 10 installers do have native NVMe drivers present - theoretically, if the NVMe PCI-e drive correctly implements the basic NVMe standard, it should be usable (of course you can miss some of the performance by not using drivers from the manufacturers)

      - I confirm that the Samsung NVMe 2.0 driver works correctly with SM961 under Windows 8.1 Pro / Windows 10 Pro (as others on the Internet rumoured that it doesn't work - IT WORKS)


      I can only recommend other users of LEGACY platforms to try this tutorial and report back. It will be very useful for us to know what works. I personally plan on trying out other NVMe's like Intel 600p, OCZ RD400 and maybe some Samsung EVO 960... My tutorial is not meant as the defacto standard for booting NVMe's on legacy systems :), but mostly as a hint for those who want to try it out. I can see users succeed with booting from the other SATA drives, using USB 2.0 sticks as Windows install media, etc - this is only the beginning.

      Guys, please do share if you tried it, X58 is still strong enough, even in 2017 ;)

    • Hello folks,

      after hours of fiddling and studying Clover, Tianocore, DUET, UEFI, UEFI Shell, Windows Boot loader internals, other tutorial on this, etc... I am reporting !!! SUCCESS ON BOOTABLE NVME UNDER WINDOWS 8.1 PRO on my 8+ years old ASUS P6T SE, Core i7 920 with SAMSUNG SM961 256GB !!!

      It can't be described what I am feeling right now to see it booting and working. Just - it was definitely worth spending the time with it and I think it's the best upgrade for my trusty P6T SE/i7 920 in its existence. Still running strong ;)

      I will not post the exact steps I did to get this working right now, still want to try and document another ways (i.e. clone my old Intel Raid-0 system and try different bootloaders), but I'll write very detailed and easy-to-use tutorial in the coming days (weeks?) as my time permits.

      So far speeds are awesome, didn't even have to turn off RAID in BIOS - my "legacy" Intel RST RAID-0 works too and is even accessible from this new NVMe system, next - Samsung NVMe driver works ok, Windows 8.1 Pro seems stable, hope it will last. Screenshot of my freshly installed Win 8.1 Pro right now:



      STAY TUNED !!!

      -M.

Recipient
mireque
Subject:


text:
{[userbook_noactive]}


Xobor Forum Software von Xobor