Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

kambala

macrumors newbie
Original poster
Jun 15, 2021
16
10
Moscow, Russia
Hi everyone. I'll describe my setup and what I have already tried first.

I have installed Big Sur on MacBookPro6,2 (15'' mid-2010) via OCLP. Then I decided to install Windows 10 in (U)EFI mode. Officially my mbp supports only 8.1 via non-UEFI (legacy) mode.

First, I tried using Winclone's command line utilities to deploy install.wim to the prepared volume. That seemed to have worked, I booted into the initial Windows setup screen (region, keyboard layout etc.), but every time I reached MS account login, Mac suddenly rebooted and after that I could no longer enter Windows or start the setup again. Tried the whole procedure twice - with the same result.

Then, I decided to try deploying install.wim with dism.exe directly. Found very detailed instruction for that, all worked fine, also deployed some Bootcamp drivers like it says and finally managed to bypass the MS account login screen. This time Windows setup crashed again (BSOD because of igdkmd64.sys - Intel graphics driver), but at later point. However, this time I was able to boot into Safe Mode (it showed me the OOBE screen again which I couldn't complete due to errors, but in the end managed to kill it and see the desktop) and delete graphics drivers - this finally let me boot Windows normally. Installed all Bootcamp drivers, but the same BSOD was back. Safe mode and delete drivers again. Then I installed DDU and deleted all drivers properly with it, also disabled Windows Update driver downloads to prevent the failing drivers being installed again.

Currently Windows works fine, both Nvidia and Intel video adapters are visible in Device Manager, both use MS Basic Display Driver. I've also disabled the Nvidia adapter there since it's failing. Only screen brightness can't be changed (I believe that porting nvidia_bl.c to WinAPI would fix it). But visual artefacts still appear on the screen from time to time - I believe Nvidia adapter is still trying to do something, but fortunately it doesn't kill windows (unlike macOS, where kernel panic takes place immediately in such case).

Now I'd like to run Windows on iGPU completely to avoid those artefacts, but I can't seem to understand how to achieve that. I've found an excellent thread about Windows+EFI, but too bad it's quite big and the most important info isn't given in the first post. I've managed to find required info there (maybe there's more, I didn't read all 40+ pages):
But all instructions there are about getting dGPU to work (as I understand) and I need exactly the opposite. Also, some years ago I've already struggled to make Nvidia adapter work properly in EFI mode (back when it was functioning flawlessly), found GRUB solution for that and converted it to EFI+rEFInd. But it's not helping me now either.

Elsewhere I found Linux instructions how to force iGPU:
Code:
outb 0x728 1 # Switch select
outb 0x710 2 # Switch display
outb 0x740 2 # Switch DDC
outb 0x750 0 # Power down discrete graphics

which for EFI would be:
Code:
mm 728 1 -io
mm 710 2 -io
mm 740 2 -io
mm 750 0 -io

Once I execute the second statement in EFI shell, the screen goes black. Executing next commands and booting windows doesn't power the screen on.

I've also tried the following:
Code:
mm 000001003e 8 -pci
mm 0001000004 7 -pci
mm 750 0 -io
but the last command makes screen black with the same result as above. Even powering down iGPU with mm 750 2 -io results in black screen for some reason... Although in EFI shell I see that the screen runs on dGPU.

My PCI devices:
Code:
00 00 01 00 - bridge (pci/pci) - 10d device handle
00 01 00 00 - Nvidia VGA - 10e device handle
00 00 02 00 - Intel VGA - 110 device handle

Unfortunately, I'm completely unfamiliar with low-level hardware stuff like PCI, bridge, bus etc., all those commands are basically magic to me. Although the above links from the Windows+EFI thread slightly enlightened me, I still don't understand what I need to do to solve this.

Potentially I can convert windows to legacy booting, although I'm not sure if that'd work fine with OCLP. But if I remember correctly, in legacy mode windows can access only dGPU.
 
Last edited:
  • Like
Reactions: sat

kambala

macrumors newbie
Original poster
Jun 15, 2021
16
10
Moscow, Russia
will post some findings that I made, although the issue is still not solved.

first of all, after reading CPU's datasheet (you can find it in the web archive or check my uploaded version) I finally understood what those magic mm commands mean when you want to make Nvidia work under Windows:
  • mm -pci 1003e 8 - enable VGA (bit 3) in Bridge Control register (0x3E) of the bridge device, default value is 0x0
  • mm -pci 1000004 7 - make Nvidia VGA device bus master (enable bit 2) in Command register (0x4), default value is 0x3
  • mm -pci 50 2 -w 2 - this turned out to be even wrong, as the right register for my CPU is 52, not 50. And it's sufficient to modify just a single byte. It disables iGPU (enable bit 1) and forces it to not allocate any memory (set 0 to bits 4-7) in the root device's (0/0/0) Processor Graphics Control Register. So correct command is mm -pci 52 2, and default value is 0x50.
  • mm -pci 54 3 - completely disable iGPU device (disable bit 3) in the root device's Device Enable register, default value is 0xB.

Then I started playing with registers trying to make windows recognise iGPU properly. I found out that disabling Memory Access on Nvidia VGA with mm -pci 1000004 0 makes Windows report that iGPU "is working properly", but after executing this command in the EFI shell makes screen stuck (which is kinda expected). I can still log into the device through VNC or ssh and use it normally. If I power off NVIDIA GPU with those 4 -io commands before booting windows (or even inside Windows with RW Everything program), nothing changes anyway - black screen, but completely usable through VNC.

I have a suspicion that Windows simply doesn't know how to power on display panel as there's no dedicated iGPU driver. Installing the driver from BootCamp causes immediate BSOD, also tried doing it with disabled driver signature verification - that made slight progress as I heard the system sound of "new device connected", but then BSOD again and windows won't boot until I disable the iGPU device in Safe Mode. On the internet I read that driver for this iGPU officially supports only 8.1, so I went ahead and installed 8.1. The driver did install, but BSODed again with the same behavior as under 10.

So, it seems that something is preventing the driver from running correctly. Linux also had similar issue where it was solved by forcing LVDS into dual-channel mode. It can't be done simply through CPU registers as with Nvidia, so I started reading the Linux's Intel iGPU driver code as well as official manuals, but that didn't get me far, unfortunately, as there's really lots of info. I found how to dump all VGA-related registers under Linux in order to check and compare their values under Windows hoping that maybe just a few needs to be adjusted, but I don't understand how to access MMIO space using RW Everything program - going to iGPU memory as reported by BAR registers and offsetting by appropriate value shows only garbage.

Next I'd try some DSDT/SSDT patching to disable dGPU on hardware level, maybe that'd make windows happy (and might force macOS/gMux to never try switching to dGPU, although that's mostly not a problem at the moment).

Any hints/ideas would be greatly appreciated.
 
  • Like
Reactions: sat

kambala

macrumors newbie
Original poster
Jun 15, 2021
16
10
Moscow, Russia
Basically solved! I've found another NVRAM variable that also controls active GPU at boot time: GfxMode, under Apple's GUID. The research is described in details in #2,996

Now I can simply do nvram GfxMode=4 in macOS (or equivalent in Linux/Windows/EFI Shell) and after reboot iGPU drives the screen! And Windows also uses iGPU and no more visual glitches in my case!
  • brightness can only be changed by writing directly to gmux I/O port 0x774, I used RW Everything program for that
  • installing iGPU driver still causes Windows to reboot and then never boot again until the driver is deleted, although no BSOD now
 
  • Like
Reactions: sat

sat

macrumors newbie
Jul 17, 2019
6
0
New York, NY
Have you tried modifying gmux I/O port 0x774 when using the Nvidia controller on the MacBookPro6,2?

(Also, are you still using the refind script to force your iGPU at startup? I'm using that to set the dGPU, with the commands in the automatic start script which appears to still be working on my machine, but it's too bad I need to have refind bootstrap windows 11 on every boot, as that makes hibernation impossible.)
 

kambala

macrumors newbie
Original poster
Jun 15, 2021
16
10
Moscow, Russia
Have you tried modifying gmux I/O port 0x774 when using the Nvidia controller on the MacBookPro6,2?
don't remember to be honest, but that would simply adjust screen brightness. It doesn't matter which GPU is active and will always work.
Also, are you still using the refind script to force your iGPU at startup?
as I wrote in the last post in this thread, I simply do nvram GfxMode=4 (or equivalent in other environments) just once and it survives reboots (unless that variable is deleted or you perform NVRAM reset of course). it's dGPU which needs the "bootstrap" script where you'd adjust some registers with mm command before booting Windows (see second post in this thread).
as that makes hibernation impossible
yes, that's what we have to live with, unfortunately
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.