Hello everyone,
Yesterday I encountered an eGPU compatibility issue after a BIOS update, and was able to resolve it. I would like to share this in hope that it could help somebody who is struggling with the same problem, and to save them some time and frustration.
I've been successfully using a NUC8i7BEH unit with an eGPU (Gigabyte AORUS Gaming Box 2080 Ti) for several months now. Yesterday, I attempted to update the BIOS to the latest release (0083). After the update, I could no longer obtain HDMI signal from the eGPU, connected to the NUC. I am using Windows 10 Pro version 2004 (May 2020).
Strangely enough, once Windows is done loading, the embedded LEDs on the eGPU did light up as they normally would. No HDMI signal, though. I then started investigating (if you are not interested in the technical details, scroll down for a description of what I did to work around this issue).
When powering up the NUC with both the eGPU and the integrated GPU connected to different HDMI inputs on the TV, signal would appear to be coming from the integrated GPU. Then, only after having completed the Windows logon procedure (that usually means entering one's password), would the eGPU start emitting HDMI signal normally.
I then decided to test this "blindly": I shut down the machine, disconnected the HDMI cable that was connected to the internal GPU, and let the system boot. After some time, when I was certain that the logon screen should have appeared, I blindly entered my password, and voila – the standard Windows desktop appeared, out of nowhere.
As this would never happen before BIOS 0083, I decided to check its change log. Sure enough, I saw this:
"Fixed issues with Kernel DMA protection".
Interesting, now that made some sense. A change that was made to the DMA protection logic could have triggered this, because Kernel DMA protection (a relatively new feature, available starting from Windows 10 version 1803) has bearing on the way in which Thunderbolt 3 ports operate (for the curious, have a look here: https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt).
Eventually, I was able to pinpoint the issue: it seems that, for some reason unbeknownst, BitLocker, in combination with BIOS version 0083, will not let Thunderbolt 3 devices enumerate until Windows logon has been completed, as long as the "Intel Virtualization Technology for I/O (VT-d)" option is enabled in the BIOS, and the "Thunderbolt 3 Security Level" is set to anything but "Legacy".
N.B., It seems that others have encountered similar issues under different setups, and have come up with the same solution (https://egpu.io/forums/pc-setup/thunderbolt-devices-enabled-before-windows-login-possible/).
Here's what I did to work around that issue:
1. Power down the system;
2. Disconnect the eGPU from the NUC by unplugging the Thunderbolt 3 cable;
3. Connect the HDMI port of the integrated GPU to your display;
4. Power up the NUC and enter the BIOS by pressing the F2 key at POST;
5. Open the "Advanced" menu, navigate to "Security" and *disable* the "Intel Virtualization Technology for I/O (VT-d)" option (the other "Intel Virtualization Technology" option can remain enabled);
6. In the same tab, change the Thunderbolt Security Level to "Legacy";
7. Save your settings by pressing F10, and let the system boot normally;
8. Shut the system down, disconnect the HDMI cable from the integrated GPU and reconnect
the eGPU to the NUC. Then power on the system as you usually would (refer to the subsequent paragraph describing one remaining issue).
The system should now work normally.
Please note that if you have BitLocker enabled for any of your drives (to check this, search for "Manage BitLocker" in Windows 10, or open the "BitLocker Drive Encryption" applet through the Control Panel), make sure to obtain your BitLocker recovery key before changing these settings. You should have the key handy so that you could input it, should BitLocker require the key due to a detection of a configuration change.
To obtain the BitLocker recovery key, follow instructions by Microsoft here:
https://support.microsoft.com/en-us/windows/finding-your-bitlocker-recovery-key-in-windows-10-6b71ad...
Make sure to have the BitLocker recovery key in your possession and stored safely, just in case.
Please note that I have no knowledge of the possible security or virtualization implications of changing these settings.
One remaining issue is that when an eGPU is connected and the system is first powered on, there is no POST screen and picture appears only from within Windows, once the OS has finished loading. Subsequent computer restarts will show a POST screen, but when the computer is initially being turned on after being off (power-cycled), there is no POST screen coming through the eGPU during the initial boot procedure.
This has also been documented by other people, with different NUC models, here: https://egpu.io/forums/postid/69803/
And here: https://egpu.io/forums/pc-setup/activate-the-egpu-during-bootsplash/
In the latter link, one of the posters indicated that for Skull Canyon NUCs, this has been fixed as of a certain BIOS release. The NUC8i7BEH still exhibits this behavior, though.
**********************************************************************************************************************
Note to Intel:
Could you please investigate what exactly it is, in the changes made to the BIOS in version 0083, that could cause this incompatibility – and correct the issue so that eGPU initialization could work as it used to, before BIOS version 0083? Could you also please share with us what exactly, in the fix that was made to the Kernel DMA protection logic in BIOS 0083, is causing this?
On another note, the BIOS version 0083 change log states the following: "Due to the Intel® ME firmware update in BIOS version 0083, you can’t downgrade to version 0081 or earlier."
This, with all due respect, is an indiscretion. It should be up to the customer to decide whether to remain on the most current BIOS version or revert to an earlier one (despite any security implications), whatever the reason.
You see, had I not been able to determine what is causing this, I would have been left with a system that is in unusable state (i need the eGPU for work), and would have had to wait for Intel to (possibly) implement a fix. Being able to downgrade to version 0081 would have saved me a lot of time.
Please stop blocking BIOS downgrades, even when security fixes are concerned. The choice should be with the customer, not with Intel. The present issue is a very good example why.
Moreover, even though I understand that using an eGPU is not a very common practice, please test your BIOS releases under such configurations. Doing so will surely be of great value to us, NUC and eGPU-combo owners.
Thank you very much!
