ah-

I used the windows version of gpu-switch + apple_set_os.efi + reFind 0.87 to boot Windows 8.1 (bootcamp install). No issues with black screens.

@ah- Do you know how I would go about using the Optimus.dmg tool described in this post with apple_set_os.efi? Could I patch reFind with whatever EFI tweaks are inside the dmg?

My main purpose for trying to get the Iris working is to unlock optimus internal LCD output on discreet gpu macbooks. I think it would be extremely useful to everyone if we could conveniently enable it.

Thanks!

I looks like Optimus.dmg is the old grub implementation of apple_set_os.efi, which does exactly the same thing as apple_set_os.efi, just as a grub command instead of a standalone EFI application. You don't need both, one is enough and I think apple_set_os.efi is the better implementation. In particular since less can go wrong, like grub not finding stuff.

I'm a bit surprised to see that it does anything on systems without a dedicated GPU, but who knows what exactly Apple does.

I'm not sure if the NVIDIA driver does any power management, on Linux the dedicated GPU just stays powered up even if you boot with Intel as the primary. Somebody wrote a GMUX driver that can cut the power, see here: MacRumors Forums - View Single Post - Win7 x64 booting natively via EFI (no BIOS emulation)

It's rather crude and probably won't work if you want to use the NVIDIA GPU at all, but maybe it decreases power consumption.

Also, did you have any issues with black screens at all? What software/versions are you running?

Hi everyone, you might be interested in this: https://github.com/0xbb/apple_set_os.efi

Download it from releases, install refind, sudo mount -t msdos /dev/disk0s1 /efi, copy apple_set_os.efi to /efi/EFI/custom/apple_set_os.efi.

You should then see an entry for apple_set_os.efi in refit. Before you boot Windows, just quickly start that, which will flash the screen while it runs and then just boot Windows. This enables the Intel GPU so it's visible in the device manager. No more grub/Linux required. (To clarify, this disables the hiding of the Intel GPU and makes it appear in the device manager, nothing else. NVIDIA could still remain your primary GPU).

There is now also a Windows version of gpu-switch at https://github.com/0xbb/gpu-switch, which you can use to set the primary GPU for the next boot.

I just tested it and was able to use the Intel GPU, but booting with both GPUs active and the NVIDIA driver installed often gives me black screens after booting. I have no idea why, when I uninstall the NVIDIA driver it works perfectly, I just see two displays, one for each GPU.

Well, nice progress! Too bad the intel drivers don't work, but that seems to be a general problem.

You could try that, but the screen going black means that at least the display switching worked. External doesn't really matter, so it just might be that the ddc switch didn't happen. You don't have any sleeps in your startup.nsh so adding some after each mm might help. I think it might be "stall".

Another thing might be that it could work better with the eGPU disconnected, just to rule out one possible source of errors.

Okay did some quick tests.

I tried to set IO in EFI shell using mm command but everything's set to 0xFF as mentioned before and can't be written. (maybe there's no efi driver for the device?)

Booted eGPU Setup's freedos and used "pt IO peek/poke" commands which show everything's set to 0xFF and nothing can be written aswell.

That's strange, things like "mm 07c2 -IO 2" should work in the EFI shell.

After that I used RW Everything. Here's a screen of my IO Space:

Guess this looks pretty nice and matches your updated commands.

>wait{1,100,o 0x7c2 2}; o 0x7d4 0x28; 
>wait{1,100,o 0x7c2 3}; o 0x7d4 0x10; 
>wait{1,100,o 0x7c2 3}; o 0x7d4 0x40;

This actually does nothing as far as I can tell.

>wait{1,100,o 0x7c2 1}; o 0x7d4 0x28; 
>wait{1,100,o 0x7c2 2}; o 0x7d4 0x10; 
>wait{1,100,o 0x7c2 2}; o 0x7d4 0x40;

This will turn off my LCD. It's still connected to GT650m though.

Added 0x7c2 0; 0x7d4 0x50; which should shutdown the dGPU if I got it right. My LCD turns black, windows freezes shortly after that and reboots. if my egpu is connected my external screen shows "VIDEO_DXGKRNL_FATAL_ERROR"

Thanks a lot for your help!

That's pretty cool, it's no big surprise that Windows crashes if you cut the power to the dGPU while it's in use . The gmux just switches the data lines for the internal display without giving the OS any notification, so it's also no surprise the LCD turns black because the Intel driver doesn't know that suddenly there is a display connected to it.

But you could try to just switch the external display (with just wait{1,100,o 0x7c2 2}; o 0x7d4 0x40;) and then connect an external display. This way there's a hotplug notification and maybe you get a picture from the Intel card on the external display.

And it's probably a good idea to leave out powering off the dGPU for now, if you want that you should do it before booting Windows. So the next major step would be to get the gmux switched before booting, if it works in Windows it has to work outside of it as well.

Oh great! I'll take a look at it tonight.

As far as I know it's not that easy to trigger IO Ports in Windows cause it's blocked by default for some security reasons. It can be done using some libs though. For now RW Everything was the most useful (out of the box) IO Tool I could find.

I'm not really sure how to make use of the message box interface in Windows.

Bootcamps NullDevice allocates 0x700 - 0x7FE IO space so I tried to trigger 0x728, 0x710, 0x740 and 0x750 after uninstalling the NullDevice drivers.

Maybe my conclusions where totally wrong?!

You could also try switching the gmux before booting windows, for example in startup.nsh or using GRUB. But yeah maybe for the beginning it's easiest to just do it in windows because it's more interactive than rebooting all the time to see if anything happens.

In the long run it might be necessary to do the switching before booting, so Windows sees the internal display connected to the intel card during boot.

The following should switch the gmux to integrated (based on what the linux driver does):

// new version of outb(2, 0x728) - switch ddc
outb(2, 0x7c2) // write the value to the value register
sleep 100ms // instead of gmux_index_wait_ready, just to be on the safe side
outb(0x28, 0x7d4) // write the port to GMUX_PORT_WRITE
sleep 100ms // instead of gmux_index_wait_complete

// new version of outb(3, 0x710) - switch internal display
outb(3, 0x7c2) // write the value to the value register
sleep 100ms // instead of gmux_index_wait_ready, just to be on the safe side
outb(0x10, 0x7d4) // write the port to GMUX_PORT_WRITE
sleep 100ms // instead of gmux_index_wait_complete

// new version of outb(3, 0x740) - switch external display
outb(3, 0x7c2) // write the value to the value register
sleep 100ms // instead of gmux_index_wait_ready, just to be on the safe side
outb(0x40, 0x7d4) // write the port to GMUX_PORT_WRITE
sleep 100ms // instead of gmux_index_wait_complete

Yeah I know this driver for quite a while. That's basically why I haven't lost hope yet.

Linux apple_gmux is part of vgaswitcheroo so it's not that simple.

I allready tried to trigger the IOports via EFI shell and form within Windows (using a tool called RW Everything) without results.

In my case all ports triggered by the Linux driver are set to 0xFF and nothing happens if set.

BootCamp Drivers by default installs a NullDevice driver which has to be replaced by something like vgaswitcheroo I guess.

I tried to get in touch with some Linux developers involved in vgaswitcheroo/apple_gmux but didn't receive any response yet.

Let me know if you have some more hints as I'm not _that_ much into Linux.

I wrote a good part of the apple_gmux driver . The driver you linked previously is my old version that doesn't support the newest apple hardware. I don't remember if it's just the retina mbps, but apple changed how you have to communicate with the gmux chip. That's why poking at the old IOports doesn't do anything.

See LXR linux/drivers/platform/x86/apple-gmux.c and [PATCH] apple-gmux: Add support for message box interface (as found in MBP10,1/Retina MacBook Pro) -- Linux x86 Platform Driver Development for more. Unfortunately I don't have access to a retina mbp so I can't help with testing/developing directly. When using any code from this, use the first link (or a recent mainline kernel), not the patch.

Edit: So what you need to do to hopefully get a minimal version to work is to take the part so that

gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2); gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);

gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);

runs. For that you need gmux_index_write8 (that's the same as the outbs, but with the message box interface), which requires gmux_index_wait_ready and gmux_index_wait_complete. I'm not sure about this, but maybe you can even skip the wait functions and for a rough first version just replace them with a long enough sleep.

Just a quick hint, how the gmux is controlled changed with the retina mbps from simple ioports to a message box. See the newer apple_gmux linux driver for how to use it.