Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Win7 x64 booting natively via EFI (no BIOS emulation)
- Thread starter VirtualRain
- Start date
- Sort by reaction score
Format USB drive as Fat32 and simply copy your Windows install files over. I highly suggest using windows 8.1 though as you will have a much easier time installing it. Hope that helps
Hi, anyone else interested in getting the Intel GPU working when booting Linux/Windows via EFI on the MBP 11,3? Since the MBP11,2 uses it the drivers should work, but it gets disabled during boot.
It seems to get disabled in a similar way that the Intel GPUs were disabled in the CSM/BIOS bootcamp, by setting some bits in the PCI config space of the root bridge. In particular, byte 0x54 of the pci config space of 00:00.0 is changed from 3d (IGPU on) to 0d (IGPU off). This is documented in 4th-gen-core-family-mobile-m-h-processor-lines-vol-2-datasheet.pdf.
On previous macbooks it was possible to reenable it using setpci -s 00:00.0 54.b=3d, but on my 11,3 this doesn't work anymore, if I look at the changes with lspci -xxx the byte is only set to 2d, which leaves the IGPU disabled.
The weird thing is that it is still enabled in GRUB, byte 0x54 is still 3d and the IGPU is visible in lspci. But once GRUB loads Linux or Windows then suddenly the IGPU is disabled, even with pci=earlydump in Linux, which should run before ACPI or something else should have the chance of disabling it.
So I guess the change happens during the ExitBootServices call, but I can't find where exactly and how it determines that it's not booting OsX and should disable the IGPU.
Any ideas?
It seems to get disabled in a similar way that the Intel GPUs were disabled in the CSM/BIOS bootcamp, by setting some bits in the PCI config space of the root bridge. In particular, byte 0x54 of the pci config space of 00:00.0 is changed from 3d (IGPU on) to 0d (IGPU off). This is documented in 4th-gen-core-family-mobile-m-h-processor-lines-vol-2-datasheet.pdf.
On previous macbooks it was possible to reenable it using setpci -s 00:00.0 54.b=3d, but on my 11,3 this doesn't work anymore, if I look at the changes with lspci -xxx the byte is only set to 2d, which leaves the IGPU disabled.
The weird thing is that it is still enabled in GRUB, byte 0x54 is still 3d and the IGPU is visible in lspci. But once GRUB loads Linux or Windows then suddenly the IGPU is disabled, even with pci=earlydump in Linux, which should run before ACPI or something else should have the chance of disabling it.
So I guess the change happens during the ExitBootServices call, but I can't find where exactly and how it determines that it's not booting OsX and should disable the IGPU.
Any ideas?
So I got it to work, see http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html for details. Hopefully it will be in the git version of grub in a few days, until then you'll have to apply the patch from that email.
This adds a new command to grub, apple_set_os, which fakes being OS X, and configures all hardware as if it were booting OS X, including the Intel GPU.
To boot with the Intel GPU enabled, build grub with the patch from the mail above, choose grub from refind, and execute the apple_set_os command. You can do this either by including it in your grub.cfg, or simply in the command line (you can access it with "c", and exit it with Esc). You can even exit grub after executing apple_set_os, so you can also use it to boot Windows with the IGPU enabled.
It works perfectly fine in Linux. But in Windows most of the screen turns black soon after the boot, with only the mouse cursor and a blinking Wifi icon visible, no matter wether I boot with the Nvidia GPU or the Intel GPU (via the GfxCardStatus trick).
This adds a new command to grub, apple_set_os, which fakes being OS X, and configures all hardware as if it were booting OS X, including the Intel GPU.
To boot with the Intel GPU enabled, build grub with the patch from the mail above, choose grub from refind, and execute the apple_set_os command. You can do this either by including it in your grub.cfg, or simply in the command line (you can access it with "c", and exit it with Esc). You can even exit grub after executing apple_set_os, so you can also use it to boot Windows with the IGPU enabled.
It works perfectly fine in Linux. But in Windows most of the screen turns black soon after the boot, with only the mouse cursor and a blinking Wifi icon visible, no matter wether I boot with the Nvidia GPU or the Intel GPU (via the GfxCardStatus trick).
Well, in Windows the IGPU is enabled and for a very short while displays the login screen, but then the screen goes mostly black. I guess this is some sideeffect from enabling the IGPU, since the same thing happens both with the Nvidia or Intel GPU active. The Bootcamp EFI driver changes more than just the GPU, it also messes with SpeedStep and more, and I suppose one of the other changes confuses Windows.
Also it'd be easy to port the grub command to a standalone Efi application, I just used grub because it had the nicest Efi implementation. Gnu-efi applications always hang for me, and Edk2 is a bit bloated.
Hi DaGr8Gatzby! Thanks for your awesome guide! It's pretty useful.
I have a question. When you slipstream the win7 install.wim into the win8 installer, did you slipstream the Nividia drivers into install.wim also?
What I do was extracting the win8 installer into my USB disk and replace the install.wim. That's all. Then I set the registers using rEFInd and was able to start the installer and install. But after 2 reboots the screen keeps blank for quite a long time. The caps lock button is working. So I am wondering whether should I slipstream the drivers into the install.wim.
I'm using a MacBook unibody late 2009. Which has almost the same hardware as MacBook Pro 5,3.
Thank you!
Thanks Andreas.
I patched the GRUB with apple_set_os extension you wrote and now I can also see both Intel Iris Pro and NVIDIA GT750M GPUs in Windows Device Manager.
Unfortunately, black screen problem is also there.
However, despite the apparent lack of black-screen issues in Linux, I do not think that it is possible to power-off the NVIDIA GPU using the old gmux register values. If I attempt to do it through vgaswitcheroo interface, I get the following error:
Also, any attempts to power-down dGPU manually in UEFI shell do not seem to work, Windows keeps seeing the dGPU so I suppose Apple changed the gmux this time and the register values / ranges can be different.
I suppose disassembling AppleMuxControl module should reveal what changes they did this time...
Hey, great to see somebody interested in this!
How did you get to the device manager? I can't even log in?
The vgaswitcheroo error you get is because it cannot switch while something (Xorg) is still using the GPU. You should be able to switch via ssh after you shut down Xorg or from a VT. However, after switching you will only get a black screen because of an issue in i915, but other than that it should work (and does work on my mbp 11,3), including switching back to the nvidia GPU. If you're interested in this, see for example https://lkml.org/lkml/2014/1/6/566.
So it seems that the new gmux messagebox register values should work, see http://www.spinics.net/lists/platform-driver-x86/msg03729.html and the current apple_gmux.c driver for what changed from the old register values.
Yeah, I had the same problem. I tried something like this, but nothing happened:
I'm not sure why, maybe the gmux doesn't work before ExitBootServices or I didn't wait long enough or wrote to the wrong registers.
Maybe you can find a way to talk to the gmux and get it to power down the dGPU? A first start would be to just read/write simple values and see them changing, for example the switch ddc.
How did you get to the device manager? I can't even log in?
The vgaswitcheroo error you get is because it cannot switch while something (Xorg) is still using the GPU. You should be able to switch via ssh after you shut down Xorg or from a VT. However, after switching you will only get a black screen because of an issue in i915, but other than that it should work (and does work on my mbp 11,3), including switching back to the nvidia GPU. If you're interested in this, see for example https://lkml.org/lkml/2014/1/6/566.
So it seems that the new gmux messagebox register values should work, see http://www.spinics.net/lists/platform-driver-x86/msg03729.html and the current apple_gmux.c driver for what changed from the old register values.
Yeah, I had the same problem. I tried something like this, but nothing happened:
I'm not sure why, maybe the gmux doesn't work before ExitBootServices or I didn't wait long enough or wrote to the wrong registers.
Maybe you can find a way to talk to the gmux and get it to power down the dGPU? A first start would be to just read/write simple values and see them changing, for example the switch ddc.
Have fun
@Andreas,
It is possible to boot in Windows with both Iris Pro and GT750M enabled as long as you do not install / load Intel drivers. As soon as Intel driver is loaded you end up with the blank screen + mouse. However, as long as the Intel GPU is handled by Windows VGA driver there are no issues (apart from the fact that the iGPU is not used).
By the way, I managed to disconnect the NVIDIA card from Windows now - here is a simple command line application that does it:
http://www.dimkovic.com/distrib/WinGmuxCtrl_0.1.zip
To switch to IGD and power off dGPU, you need to be an admin and execute this:
Replace "igd" with "dis" and that would be powering on the dGPU and switching to it.
Unfortunately, I immediately end up with the black screen. Good news is: this means that mux control is working. Bad news is, obviously the switch does not complete properly.
It might be that my switching code is bad - please feel free to hack it. Basically I took the Linux apple_gmux.c code (I still keep the "indexed" accesses as well, dunno if this is still needed) and ported it to Windows using the OpenLibSys.org WinRing0 library for port I/O.
It is possible to boot in Windows with both Iris Pro and GT750M enabled as long as you do not install / load Intel drivers. As soon as Intel driver is loaded you end up with the blank screen + mouse. However, as long as the Intel GPU is handled by Windows VGA driver there are no issues (apart from the fact that the iGPU is not used).
By the way, I managed to disconnect the NVIDIA card from Windows now - here is a simple command line application that does it:
http://www.dimkovic.com/distrib/WinGmuxCtrl_0.1.zip
To switch to IGD and power off dGPU, you need to be an admin and execute this:
Replace "igd" with "dis" and that would be powering on the dGPU and switching to it.
Unfortunately, I immediately end up with the black screen. Good news is: this means that mux control is working. Bad news is, obviously the switch does not complete properly.
It might be that my switching code is bad - please feel free to hack it. Basically I took the Linux apple_gmux.c code (I still keep the "indexed" accesses as well, dunno if this is still needed) and ported it to Windows using the OpenLibSys.org WinRing0 library for port I/O.
Very cool, so it's just the Intel driver that causes the black screen, that's nice to know. I thought this might be a deeper issue.
About the black screen after switching, I guess this might be because the Intel card doesn't know it has a screen attached to it. GMUX_PORT_SWITCH_DDC switched the DDC line, which is used for display detection, and since this line is normally connected to the Nvidia card the iGPU sees no connected screens.
So I think your switching code is working perfectly, it just switches at the wrong time, after Windows has already booted and detected the screens.
So there are a few things I'm wondering about:
- Maybe it works when you already switch off the dGPU _before_ booting windows, for example in an EFI application/script or a GRUB command?
- What's different in the MBP11,2, which obviously has the Intel GPU running fine in EFI Windows? I would be very surprised if it used a different igdkm64.sys.
My current theory is that in addition to just disabling the iGPU when booting Bootcamp, the EFI also sets some configuration flags that avoid the igdkm64.sys black screen. And since my grub command disables all of the Bootcamp code, not just the iGPU disabling part, it also disabled the black screen fixup code.
If you want to dig into this, get the Firmware Update from http://support.apple.com/kb/DL1704, unpack the .pkg (just google it) and then the scap using Phoenix Mod Tool (http://forums.mydigitallife.info/th...eplace-SLIC-in-Phoenix-Insyde-Dell-EFI-BIOSes). This should get you DE23ACEE-CF55-4FB6-AA77-984AB53DE811_562.ROM (which according to google is PCH Init Peim). If you look at it you will find a function at 0x84ed, which is called on ExitBootServices and does the iGPU disabling and a lot more. My guess it that modifying this function so that only the iGPU disabling part is turned off might do the trick. Or possibly finding out what exactly it changes and then doing only the interesting parts manually. Intel has pretty good documentation in 4th-gen-core-family-mobile-m-h-processor-lines-vol-2-datasheet.pdf, so this might be useful. The writes to 0x0e000050 and so on correspond to writes to the PCI configuration space of the iGPU, see for example DEVEN on page 60 of the intel docs and page 32 for the memory layout. This might seem a bit overwhelming, but it's really not that complicated once you get how this all hangs together.
About the black screen after switching, I guess this might be because the Intel card doesn't know it has a screen attached to it. GMUX_PORT_SWITCH_DDC switched the DDC line, which is used for display detection, and since this line is normally connected to the Nvidia card the iGPU sees no connected screens.
So I think your switching code is working perfectly, it just switches at the wrong time, after Windows has already booted and detected the screens.
So there are a few things I'm wondering about:
- Maybe it works when you already switch off the dGPU _before_ booting windows, for example in an EFI application/script or a GRUB command?
- What's different in the MBP11,2, which obviously has the Intel GPU running fine in EFI Windows? I would be very surprised if it used a different igdkm64.sys.
My current theory is that in addition to just disabling the iGPU when booting Bootcamp, the EFI also sets some configuration flags that avoid the igdkm64.sys black screen. And since my grub command disables all of the Bootcamp code, not just the iGPU disabling part, it also disabled the black screen fixup code.
If you want to dig into this, get the Firmware Update from http://support.apple.com/kb/DL1704, unpack the .pkg (just google it) and then the scap using Phoenix Mod Tool (http://forums.mydigitallife.info/th...eplace-SLIC-in-Phoenix-Insyde-Dell-EFI-BIOSes). This should get you DE23ACEE-CF55-4FB6-AA77-984AB53DE811_562.ROM (which according to google is PCH Init Peim). If you look at it you will find a function at 0x84ed, which is called on ExitBootServices and does the iGPU disabling and a lot more. My guess it that modifying this function so that only the iGPU disabling part is turned off might do the trick. Or possibly finding out what exactly it changes and then doing only the interesting parts manually. Intel has pretty good documentation in 4th-gen-core-family-mobile-m-h-processor-lines-vol-2-datasheet.pdf, so this might be useful. The writes to 0x0e000050 and so on correspond to writes to the PCI configuration space of the iGPU, see for example DEVEN on page 60 of the intel docs and page 32 for the memory layout. This might seem a bit overwhelming, but it's really not that complicated once you get how this all hangs together.
Thanks, I'll definitely check the firmware and see if there is something more that is being done...
I played a bit more with the switching - so, first I dumped what registers are being written / read:
Based on this, I just did a small script using GRUB:
Basically, just added below lines before the chainloader:
Ignoring delays for the moment, this code should do pretty much the same, just before Windows is booted.
And, it does. I get the black screen immediately. Unfortunately, Windows does not manage to regain the access to the display, even with Iris Pro drivers installed
So, either we are still missing an additional operation that has to be done or, by design, Apple expects Intel driver to perform an additional operation which is not being done in Windows igdkm64.sys.
I played a bit more with the switching - so, first I dumped what registers are being written / read:
Code:
gmux version: 4.0 (release: 8), indexed: 0
Switching GPU to IGD...
Writing to port: 0x7c2, value: 0x1
Reading port: 0xd4, value: 0xff
Writing to port: 0x7d4, value: 0x28
Reading port: 0xd4, value: 0xff
Writing to port: 0x7c2, value: 0x2
Reading port: 0xd4, value: 0xff
Writing to port: 0x7d4, value: 0x10
Reading port: 0xd4, value: 0xff
Writing to port: 0x7c2, value: 0x2
Reading port: 0xd4, value: 0xff
Writing to port: 0x7d4, value: 0x40
Reading port: 0xd4, value: 0xff
Powering down dGPU...
Writing to port: 0x7c2, value: 0x1
Reading port: 0xd4, value: 0xff
Writing to port: 0x7d4, value: 0x50
Reading port: 0xd4, value: 0xff
Writing to port: 0x7c2, value: 0x0
Reading port: 0xd4, value: 0xff
Writing to port: 0x7d4, value: 0x50
Reading port: 0xd4, value: 0xff
WinGmuxCtrl: Discrete card is powered OFFBased on this, I just did a small script using GRUB:
Basically, just added below lines before the chainloader:
Code:
apple_set_os
outb 0x7C2 1
outb 0x7D4 0x28
outb 0x7C2 2
outb 0x7D4 0x10
outb 0x7C2 2
outb 0x7D4 0x40
outb 0x7C2 1
outb 0x7D4 0x50
outb 0x7C2 0
outb 0x7D4 0x50Ignoring delays for the moment, this code should do pretty much the same, just before Windows is booted.
And, it does. I get the black screen immediately. Unfortunately, Windows does not manage to regain the access to the display, even with Iris Pro drivers installed
So, either we are still missing an additional operation that has to be done or, by design, Apple expects Intel driver to perform an additional operation which is not being done in Windows igdkm64.sys.
Hey psyq321, great work! I just tried your outb-writes and with a bit of fiddling I got it to boot with just the Intel GPU. I must have had something mixed up when I tried this myself a few weeks ago.
The secret is to first set it to "Intel only" in GfxCardStatus, this is somewhat broken on osx but has the nice side effect of sticking around, so on the next reboot the whole EFI uses the Intel GPU.
Then I chainloaded Windows with
Screenshots: http://andreas.heider.io/gmux/2013/mbp113_intel.PNG
http://andreas.heider.io/gmux/2013/mbp113_gpuz.PNG
I think the reason that it wasn't working for you before is that you turned off the Nvidia GPU while EFI was still using it as the main display, and then something crashed.
That said, the Intel settings thing crashes and when trying out the Bioshock Infinite Benchmark it crashed once but then ran perfectly the second time.
The secret is to first set it to "Intel only" in GfxCardStatus, this is somewhat broken on osx but has the nice side effect of sticking around, so on the next reboot the whole EFI uses the Intel GPU.
Then I chainloaded Windows with
and the black screen problem was gone.
Screenshots: http://andreas.heider.io/gmux/2013/mbp113_intel.PNG
http://andreas.heider.io/gmux/2013/mbp113_gpuz.PNG
I think the reason that it wasn't working for you before is that you turned off the Nvidia GPU while EFI was still using it as the main display, and then something crashed.
That said, the Intel settings thing crashes and when trying out the Bioshock Infinite Benchmark it crashed once but then ran perfectly the second time.
@Andreas,
Great job! Got it to work on mine, too. It was, indeed, the boot-time dGPU activity that prevented the disconnection. Forcing the Iris Pro with gfxCardStatus solved the issue, as you found out.
Now, the weird thing is - I still cannot boot with dGPU powered down. But if I just switch to Intel GPU in GRUB and then boot into Windows and >then< switch the dGPU with the WinGmuxCtrl tool, it works just fine.
Finally, the result is virtually no power draw from the GT750M:
https://forums.macrumors.com/attachment.php?attachmentid=457334&stc=1&d=1390247497
So, in Windows the things to figure out which are still open:
- Backlight control does not work with Iris Pro (at least, not on my setup)
- Dynamic switching
I guess we can also poke gmux and adjust the backlight manually...
Great job! Got it to work on mine, too. It was, indeed, the boot-time dGPU activity that prevented the disconnection. Forcing the Iris Pro with gfxCardStatus solved the issue, as you found out.
Now, the weird thing is - I still cannot boot with dGPU powered down. But if I just switch to Intel GPU in GRUB and then boot into Windows and >then< switch the dGPU with the WinGmuxCtrl tool, it works just fine.
Finally, the result is virtually no power draw from the GT750M:
https://forums.macrumors.com/attachment.php?attachmentid=457334&stc=1&d=1390247497
So, in Windows the things to figure out which are still open:
- Backlight control does not work with Iris Pro (at least, not on my setup)
- Dynamic switching
I guess we can also poke gmux and adjust the backlight manually...
Attachments
Last edited:
To not reinvent the bicycle...
Congratulations to this small community for achieving brilliant results. Some time ago I had created a super-simple UI which uses my driver to talk to GMux in order to set the display backlight level. This was actually targeted for the 1st-gen rMBP. The goal was to bring very smooth brightness control to Boot Camp. This should work with 2nd-gen rMBP, either. If you want to test this tool, please PM me.
Congratulations to this small community for achieving brilliant results. Some time ago I had created a super-simple UI which uses my driver to talk to GMux in order to set the display backlight level. This was actually targeted for the 1st-gen rMBP. The goal was to bring very smooth brightness control to Boot Camp. This should work with 2nd-gen rMBP, either. If you want to test this tool, please PM me.
Last edited:
@Andreas,
Quick question:
- Did you perform any EFI update to your Mac?
- Do you boot to GRUB directly or through refind?
The reason I am asking is - I cannot power down dGPU while in the bootloader at all. If I attempt to do this, laptop will freeze.
However, I can do this in Windows later. But this creates an undesirable side-effect of NVIDIA driver being loaded, and then it prevents resuming from sleep... of course I can fix that by some other means (either powering off the dGPU early in the Windows boot process by writing a .sys driver that would load as boot-bus-extended, meaning immediately after ntoskrnl, or by manual eviction of the driver while loading)
I suspect that something is keeping the dGPU ON while in bootloader, despite the fact that I went to OS X and forced the GPU to iGPU through GfxCardStatus.
Quick question:
- Did you perform any EFI update to your Mac?
- Do you boot to GRUB directly or through refind?
The reason I am asking is - I cannot power down dGPU while in the bootloader at all. If I attempt to do this, laptop will freeze.
However, I can do this in Windows later. But this creates an undesirable side-effect of NVIDIA driver being loaded, and then it prevents resuming from sleep... of course I can fix that by some other means (either powering off the dGPU early in the Windows boot process by writing a .sys driver that would load as boot-bus-extended, meaning immediately after ntoskrnl, or by manual eviction of the driver while loading)
I suspect that something is keeping the dGPU ON while in bootloader, despite the fact that I went to OS X and forced the GPU to iGPU through GfxCardStatus.
I'm running the MBP112.0138.B02 firmware (So update 1.3), and boot via Refind and then grub. It's possible that it will sometimes freeze, even if EFI doesn't use the dGPU it knows that it exists and has a driver loaded which might crash if it just disappears. I booted twice without any issues, but it wouldn't surprise me at all if this were a problem.
If you know how to do this on Windows (I have to admit that I don't), this is by far the best option. The grub outbs are just a hack, as soon as you want to use sleep/hibernate you'll have issues again because the dGPU will get powered up on resume and possibly the display/ddc mux might be set to the wrong GPU as well.
Hmm, then this is the same configuration as mine... I guess I am just not lucky and getting freezes due to something related to dGPU still being alive while in UEFI bootloader.
As for the Windows driver, writing one is not really hard - I'll do this as soon as I find some time.
Basically, my idea is to switch to iGPU and power down dGPU as soon as the Windows kernel loads.
I'll try this and if it works I'll post the driver source so it can be hacked / poked.
As for the Windows driver, writing one is not really hard - I'll do this as soon as I find some time.
Basically, my idea is to switch to iGPU and power down dGPU as soon as the Windows kernel loads.
I'll try this and if it works I'll post the driver source so it can be hacked / poked.
Black Screen Question
Dear Professionals,
First of all thank you for the excellent work and informative posts in this forum/thread; using your information, i was able to come quite far in my efi booting endeavour, but i am not completely there yet. Now i ask you to help me out and/or clarify things for me;
Here are my goals:
Get windows 8.1 to boot natively (efi) from an usb drive
Platform: mbp mid 2010 (mbp6,2) with a 512mb nvidia 330m gt gpu
I want windows to actually use the discrete gpu
Here is what i did:
Partition usb hdd using guid scheme with one efi bartition, one ms reserved, rest for os
Using dism, unpacked the install.wim to the os partition
Installed bootloader to efi partition
Booted the windows (this mode is called windowstogo by ms) on a different computer as the first-time setup seems to check for something on my mac and then reports that this computer isnt supported; entered serial etc
Connect hdd to mac again, boot into win8.1
Installed nvidia drivers
Disable internal/intel video card; the nvidia has an error sign next to it in the device manager;
Then installed refind on my efi partition
Installed efi shell on efi partition
Having the hdd connected to my mac again, started the efi shell
I then use the following commands:
mm 01000004 7 -PCI
mm 0001003E 8 -PCI
mm 750 3 -IO
fs[x]:\EFI\Microsoft\Boot\bootmgfw.efi
As i understand it,
the first mm sets bus mastering on the nvidia card
the second mm sets vga enable on the bridge connecting to the nvidia card
the third mm enables the discrete gpu (already enabled upon boot, so nit neccessary?)
Status:
Windows 8.1 boots, but i get only a black screen (doesnt matter wether on external or internal monitor) and when i move my mouse i see a mouse cursor; rarely, some white icons from the windows logon screen flash into view an vanish again. So i have, like many of you the black-screen-problem.
If i do not set the mm commands, i can work with windows 8.1 ok but i just have basic display adapter functionality.
Is there a fix for this?
I did not find the intel gfx driver in my windows\system32\drivers directory;
Thank you all so much for your help in advance!
If anybody wants or is interested, i can post a full transcript of all commands used to set the system up in the way described!
Best Regards!
Dear Professionals,
First of all thank you for the excellent work and informative posts in this forum/thread; using your information, i was able to come quite far in my efi booting endeavour, but i am not completely there yet. Now i ask you to help me out and/or clarify things for me;
Here are my goals:
Get windows 8.1 to boot natively (efi) from an usb drive
Platform: mbp mid 2010 (mbp6,2) with a 512mb nvidia 330m gt gpu
I want windows to actually use the discrete gpu
Here is what i did:
Partition usb hdd using guid scheme with one efi bartition, one ms reserved, rest for os
Using dism, unpacked the install.wim to the os partition
Installed bootloader to efi partition
Booted the windows (this mode is called windowstogo by ms) on a different computer as the first-time setup seems to check for something on my mac and then reports that this computer isnt supported; entered serial etc
Connect hdd to mac again, boot into win8.1
Installed nvidia drivers
Disable internal/intel video card; the nvidia has an error sign next to it in the device manager;
Then installed refind on my efi partition
Installed efi shell on efi partition
Having the hdd connected to my mac again, started the efi shell
I then use the following commands:
mm 01000004 7 -PCI
mm 0001003E 8 -PCI
mm 750 3 -IO
fs[x]:\EFI\Microsoft\Boot\bootmgfw.efi
As i understand it,
the first mm sets bus mastering on the nvidia card
the second mm sets vga enable on the bridge connecting to the nvidia card
the third mm enables the discrete gpu (already enabled upon boot, so nit neccessary?)
Status:
Windows 8.1 boots, but i get only a black screen (doesnt matter wether on external or internal monitor) and when i move my mouse i see a mouse cursor; rarely, some white icons from the windows logon screen flash into view an vanish again. So i have, like many of you the black-screen-problem.
If i do not set the mm commands, i can work with windows 8.1 ok but i just have basic display adapter functionality.
Is there a fix for this?
I did not find the intel gfx driver in my windows\system32\drivers directory;
Thank you all so much for your help in advance!
If anybody wants or is interested, i can post a full transcript of all commands used to set the system up in the way described!
Best Regards!
Last edited:
@Andreas,
I wrote a small Windows driver that does nothing else but switches to Iris and powers down the dGPU:
http://www.dimkovic.com/distrib/GmuxSwitchTestWinDriver.zip
You can see from the source that it is very simple.
To change/build it you need the Windows Driver Kit (I use 7.1)
Basically what it does it - it immediately performs the switch and power-off before NVIDIA driver gets a chance to load. This eliminates the NVIDIA from the Device Manager completely.
However, with my setup - it still hangs the system and I need to switch to Iris in the GRUB menu WITHOUT powering off the dGPU, and then load Windows with the driver which finishes the job.
This is the GRUB part:
And then, gmuxtest.sys does the power-down.
--
What it still does not do is handling the resume.
This is the next thing I'll be looking into - basically we need do the same thing again when Windows resumes. Here the trick will be to do it as quickly as possible before Windows gets the chance to figure out that NVIDIA is present again and load the NV driver...
I wrote a small Windows driver that does nothing else but switches to Iris and powers down the dGPU:
http://www.dimkovic.com/distrib/GmuxSwitchTestWinDriver.zip
You can see from the source that it is very simple.
To change/build it you need the Windows Driver Kit (I use 7.1)
Basically what it does it - it immediately performs the switch and power-off before NVIDIA driver gets a chance to load. This eliminates the NVIDIA from the Device Manager completely.
However, with my setup - it still hangs the system and I need to switch to Iris in the GRUB menu WITHOUT powering off the dGPU, and then load Windows with the driver which finishes the job.
This is the GRUB part:
Code:
apple_set_os
outb 0x7C2 1
outb 0x7D4 0x28
sleep 1
outb 0x7C2 2
outb 0x7D4 0x10
sleep 1
outb 0x7C2 2
outb 0x7D4 0x40
sleep 1And then, gmuxtest.sys does the power-down.
--
What it still does not do is handling the resume.
This is the next thing I'll be looking into - basically we need do the same thing again when Windows resumes. Here the trick will be to do it as quickly as possible before Windows gets the chance to figure out that NVIDIA is present again and load the NV driver...
Ok, I figured even how to survive sleep->resume cycle
Basically, after resume we need to:
- Reconfigure the gmux again (switch to Iris, power off the dGPU)
- Stop Intel driver (e.g. with devcon.exe from Win DDK)
- Start Intel driver again
Sometimes last two operations need to be performed 2 times.
Problem is, after resume and gmux reconfigure Intel Iris Windows driver will fail to detect the display. When we stop Intel driver afterwards, Microsoft VGA driver will correctly detect the screen. Restarting Intel Iris driver afterwards gets the display detected again.
The only remaining problem is that Broadcom WiFi dies sometimes during all this (yes...) Maybe I accidentally powered it off? This will be interesting to check because I suspect Apple is not powering down WiFi/Bluetooth radio either so this is another avenue for
--
So basically now we have everything needed as far as knowledge is concerned.
What needs to be done to make this more automatic?
- Properly written Windows driver that will perform the dGPU power-off early in the boot process and reinitialize the gmux after resume
- Windows service that also listens to power events and restarts the Intel Iris Pro driver after system resume
After this we can also try dynamic GPU switching - the idea would be to disable/re-enable drivers after gmux reconfigure... maybe it would work?
Basically, after resume we need to:
- Reconfigure the gmux again (switch to Iris, power off the dGPU)
- Stop Intel driver (e.g. with devcon.exe from Win DDK)
- Start Intel driver again
Sometimes last two operations need to be performed 2 times.
Problem is, after resume and gmux reconfigure Intel Iris Windows driver will fail to detect the display. When we stop Intel driver afterwards, Microsoft VGA driver will correctly detect the screen. Restarting Intel Iris driver afterwards gets the display detected again.
The only remaining problem is that Broadcom WiFi dies sometimes during all this (yes...)
Maybe I accidentally powered it off? This will be interesting to check because I suspect Apple is not powering down WiFi/Bluetooth radio either so this is another avenue for --
So basically now we have everything needed as far as knowledge is concerned.
What needs to be done to make this more automatic?
- Properly written Windows driver that will perform the dGPU power-off early in the boot process and reinitialize the gmux after resume
- Windows service that also listens to power events and restarts the Intel Iris Pro driver after system resume
After this we can also try dynamic GPU switching - the idea would be to disable/re-enable drivers after gmux reconfigure... maybe it would work?
I'm wondering is the system otherwise perfectly stable when everything is loaded as per instructions and only iGPU is used? Also I'm very curious is the notebook surface between keyboard and display finally as cool as in OS X after viewing, say, 1080p youtube for 20 min.? 'Normally' it gets incomparably warmer after just a few minutes of video playback.
IMHO Boot Camp on the rMBP has 3 major annoyances: (1)battery life, (2)stock trackpad driver, and (3)the keyboard backlight which is forced at maximum brightness after each boot. My tools fix only (2) and (3), so if this finally fixes the battery life, it's the day of the total victory over Apple plans to make Windows-on-MBP an ugly thing. I know, I'm too fast, as the resume from sleep fix shall be automated first, but anyways con-gra-tu-la-ti-ons already! (Especially if the stable and cooler operation is confirmed)
IMHO Boot Camp on the rMBP has 3 major annoyances: (1)battery life, (2)stock trackpad driver, and (3)the keyboard backlight which is forced at maximum brightness after each boot. My tools fix only (2) and (3), so if this finally fixes the battery life, it's the day of the total victory over Apple plans to make Windows-on-MBP an ugly thing. I know, I'm too fast, as the resume from sleep fix shall be automated first, but anyways con-gra-tu-la-ti-ons already! (Especially if the stable and cooler operation is confirmed
)