NUC8i7BEH, BIOS version 0083 and eGPU issues (and a workaround)

[PavelPr]

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!

[mtju]

NUC8i5BEH + 0083 BIOS + Lenovo Graphics Dock (mobile NVIDIA GeForce GTX 1050) here - experiencing the same problems as PavelPr.

Before on 0081 BIOS I could use monitor and keyboard attached via dock from right from the POST/BIOS and even during BIOS upgrade processes - it was working perfectly. I wish that downgrade would be possible...

UPDATE:

I did not perform any configuration changes in BIOS but video and keyboard via dock somehow began working again during POST/BIOS phase after playing around with plugging/unplugging HDMI and Thunderbolt cables, booting and logging in to Windows.

But during Windows (1909, build 18363.016) boot video via dock was still being lost - loading indicator was stopping but I could still see loading and login screens just fine via HDMI. I could still do "blind" login and then video was outputted again via the dock.

Next, as per PavelPr's advice, I have disabled VT-d in BIOS but I have left Thunderbolt security level unchanged at "Unique Id" and it did the trick - now everything (minus VT-d, which I do not currently use) works as before.

Thank you, PavelPr, for your detailed post!

[PavelPr]

I am glad that you were able to get your systems back in working order, @mtju and @rockeyfish!

@mtju 
Interestingly though, I couldn't get my setup to work properly until I changed both settings, as I described. Changing these setting separately did not seem to do the trick for me. Wonders of the world.

[Ronny_G_Intel]

Hi PavelPr,

We are currently looking into the issue that you described:  not seeing a POST screen on the first boot after a power cycle when an eGPU is connected. POST screens are seen on every subsequent reboot, but after a power cycle, no image is displayed until the system has finished booting into Windows.

I have to tell you that this may take extra time and I cannot promise any solution at this time but we are working on the root cause analysis and I will get back to the community as soon as I get any update.

Regards,

Ronny G

[PavelPr]

Hi Ronny,

Thanks for your reply!

It has been almost two months since my initial post. Could we please get a status update on these two issues?

Thanks!

[PavelPr]

Hi Intel,

Could we please get a status update on this?

Could you also please comment on Intel's policy to block BIOS downgrades in certain circumstances? – An option to downgrade to BIOS version 0081 would have saved me a lot of trouble. The choice of whether to downgrade the BIOS to an earlier release should be, in all circumstances, with the customer (even when security fixes are concerned).

Thanks!

@MaryT_Intel

@Sebastian_M_Intel 

[Ronny_G_Intel]

Hi PavelPr,

Intel prevents BIOS downgrades under some circumstances so that a bad actor cannot install a previous BIOS that contains exploitable vulnerabilities without a customer knowing about."

I would always recommend that customers check the BIOS Update Release Notes before running a BIOS update, this will give you a quick overview of the fixes included on a particular version and other implications.

See for example https://downloadmirror.intel.com/29798/eng/BE_0083_ReleaseNotes.pdf 

 Let me know if you have more questions.

Regards,

Ronny G

[PavelPr]

Hi Ronny,

I am aware of the warning that appears in the release notes. What I intend to say is that this policy has no place to be, to begin with.

There is no difference, in terms of security, between downgrading and not upgrading. In the same way that the choice of whether to upgrade or not is with the consumer, in terms of  whether to downgrade or not – the choice should be with them too. There is no practical difference between these scenarios (not upgrading and downgrading), as the end result is the same. In the same way Intel cannot force an upgrade, Intel should not block downgrades.

Second, I was perfectly aware of the security updates in version 0083. I read the release notes. Generally, I do not downgrade BIOSes. However, this case is different. After upgrading to version 0083, my eGPU stopped working with the NUC. Any reasonable person would agree that such circumstances merit a downgrade, but that option was blocked by Intel. At the time of applying the BIOS update, I wasn't aware of the fact that it can make eGPU configurations dysfunctional; after the update, it was already too late. Ironically, the only way to make the eGPU work again was to disable security features in the BIOS.

To me, the only alternative here then is to avoid security-related BIOS updates altogether, because in the event that they have other negative effects on the system, they cannot be downgraded. This should never be the case.

Had I not been able to find a workaround, I would've had to buy a new computer. Is that preferable over a BIOS downgrade?

Finally, Intel has never commented on the eGPU issue itself, that has arisen with version 0083. Can we expect a fix that will make eGPUs work like before BIOS 0083, in default BIOS configurations (without modifying security settings)?

Likewise, no comment has been made by Intel on the issue of not seeing a POST screen on the first boot after a power cycle when an eGPU is connected ? – POST screens are seen on every subsequent reboot, but after a power cycle, no image is displayed until the system has finished booting into Windows.

Thank you!

[Sebastian_M_Intel]

Hello PavelPr, 

Thank you for your reply. 

Please remember that this inquiry is being reviewed internally, as soon as we have an update we will post it on this thread, kindly wait for a response. 

Regards,  

Sebastian M   

Intel Customer Support Technician  

[rockeyfish]

NUC8i7BEH (BIOS version 0083) & Razer Core X & Sapphire Radeon RX 5700 NiTRO+

I also encountered the same problem, thank you very much for sharing the solution. Test success.

In addition, I still want to use the virtualization function, I hope Intel can solve this problem as soon as possible.

[Ronny_G_Intel]

Hi PavelPr,

The issue that you described before 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 is the expected behavior based on our internal investigation.

During the first boot, BIOS is not able to enumerate the eGPU at post stage yet, the eGPU needs to wait until the eGPU driver takes over when system boots into the Operating System stage. After the eGPU driver is enumerated, the system is able to identify that there is an eGPU attached to Thunderbolt port. Therefore, at the second re-start/boot the NUC will set the primary display to the eGPU path. This is the reason why users will not see post screen during first boot. 

I hope this helps.

Regards,

Ronny G

[rockeyfish]

I received a BIOS update reminder today. The version is BECFL357.86A. Has this problem been resolved?

[AlHill]

"BECFL357.86A"  That is not the version number.  It will be four digits, like in the subject line.

[rockeyfish]

Sorry, my mistake, the new version is 0085.

[PavelPr]

The new version in question is 0085, and no such fix is documented in its change log. The change log reads:

“Fixed issue that made system fans spin over 3000 RPM of workload.”

And that’s about it.

[n_scott_pearson]

Do the Release Notes say there is a fix for this issue? If not, then no, there isn't. This isn't rocket science.

...S

[wil]

Hi Ronny -

POST screen on first boot with eGPU worked fine with BIOS version 0081.

POST screen on first boot with eGPU does not work with BIOS version 0083.

Can you bring back same functionality as existed in BIOS version 0081 where POST screen shows on first boot?

As mentioned in this thread and the release notes, we cannot downgrade to version 0081.

Look forward to hearing from you.

Best,

William

[PavelPr]

Thanks for writing back.

Unfortunately, your response does not address the following issues:

1. After applying BIOS 0083, one has to disable the VT-d, in order to be able to gain HDMI signal from the eGPU, without having to enter the Windows logon credentials blindly. Prior to version 0083, there was no need to do this.

Changes that were made in BIOS version 0083 apparently have to do with this. Your response does not indicate when we could expect a BIOS version that would restore proper eGPU functionality without the need to disable VT-d.

2. Your response does not address concerns about Intel's policy of blocking downgrades, where security fixes are concerned. While I understand the security implications, the choice should be with the customer.

There is no difference between not upgrading the BIOS and downgrading it. Intel cannot force BIOS upgrades, and likewise – it should not block downgrades and leave the choice with the consumer. In both cases, the security fixes are not present (both when not upgrading and downgrading). There is no difference between these scenarios, and to my understanding, they should not be treated differently.

Your BIOS updates can have implications on system usability, as the present issue demonstrates. Had I not been able to identify the solution that I outlined in this post, I would've been left with an unusable system (I absolutely need the eGPU for my usage scenario).

Downgrading the BIOS would have provided a quick path to the recovery of the functionality that was broken by the BIOS update. Please stop blocking BIOS downgrades, even when security fixes are concerned.

3. I am willing to accept the explanation regarding eGPU enumeration. It makes sense.

Still, why cannot something like this be implemented in the UEFI BIOS (so that the BIOS would perform the enumeration itself)? What if I don't want to depend on an operating system? Having no screen output during the first POST/bootup gives a (temporary) false impression of a dysfunctional system.

[PavelPr]

On another note, did anyone here get to update to BIOS 0085? Did it have any impact on eGPU functionality?

[rockeyfish]

I have not updated to 0085, I am afraid that new problems will appear.

[n_scott_pearson]

BIOS 85 delivered only one fix, namely the fix for the issue causing the fan to run at full speed.

...S

P.S. Fear? There's no fear in computing. Get out on that bleeding edge with the rest of us!