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-t...).
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:
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!
There has been no official reply in this thread, with regards to the question of why the same fix – which has apparently been implemented for other NUC modules – cannot be implemented for us, NUC8i*BEH owners, so that we would be able to gain signal during initial POST. Could someone please comment?
Moreover, in an unrelated note, when visiting the drivers page for my NUC (NUC8i7BEH), I am now see that there is a Thunderbolt 3 Controller Firmware Update (version 46), dated April 26. There is no detailed changelog for that firmware update, with its description only stating that it provides "Security Enhancements" (it is unclear what these security enhancements precisely are).
Seeing that the issue that is described in this thread appeared after applying BIOS 0083 (which introduced changes that had to do with security and Thunderbolt 3), I am exercising caution in applying this controller firmware update (this is admittedly a Thunderbolt 3 controller firmware update – as opposed to a BIOS update – but I am cautious nonetheless). Also, seeing that I don't have a firmware image for the firmware version that's presently installed on my NUC, I presumably will not be able to roll this back in case of an issue.
Has anyone with an eGPU applied said Thunderbolt 3 Controller Firmware update 46, and could share their impressions?
One more thing: the release notes document that is downloadable along with the update states that a Thunderbolt device should be attached to the NUC before and while updating. Because I use an eGPU, I am concerned with the possibility that updating the Thunderbolt 3 controller firmware might result in a loss of image signal, during the update (the computer outputs image through the eGPU that is connected via Thunderbolt 3). Seeing that one must have a Thunderbolt 3 connected before and during performing this firmware update – and that I don't have any Thunderbolt 3 device apart from the eGPU in my possession – I don't know how I should proceed.
I accidentally found a way to solve this problem. At least it works on my NUC8i7beh & Razer Core X.
When I was trying to change the serial number of multiple monitors in Windows 10, someone said that I need to specify the primary video port in the BIOS, so I tried to set the primary video port to the Thunderbolt. After reboot, the monitor serial number in Windows was not changed, but the next day I found that when the computer is turned on, of course, turn on the eGPU first and then the NUC, and the monitor immediately has a signal, just like not using the eGPU.
The original setting in the BIOS is "auto". I guess there is a bug here. Setting "auto" will always default to the HDMI, even if HDMI is not connected to any cable.
My English is very poor, I don’t know if I express it clearly, the pictures may be easier to understand, you can try it.