Sidebar Sidebar
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)

nex01 said:
Hello, Sorry I'm a complete noob.
I'm already trying to find a way for months to run my Macbook Pro Retina Late 2013 with Intel Graphics in Windows because the GT750M is sucking up so much power from the battery.

So I finally found this thread, but it's really confusing and hard to understand.

Can you or someone else explain me step-by-step how you enabled the Intel Iris Pro and disabled the Nvidia?

I installed Windows via Bootcamp assistant on OSX Mavericks.

The only thing I understood so far was:

1.) changing graphics to intel only with gfxcardstatus
2.) chainloading windows with grub
3.) installing a driver that disables Nvidia driver loading
4.) installing intel drivers?

Not sure if I understood that correctly so far, so that's why I'm asking

Thank you very much, your help is appreciated :)
Click to expand...

Hi nex01, sorry that there are no good instructions yet, this is all very experimental.

But if you're interested in getting it to run, start with setting up GRUB:

nex01 said:
I uploaded my grub folder here: http://andreas.heider.io/gmux/2013/g...set-os.tar.bz2

sudo mount -t msdos /dev/disk0s1 /efi

Then move the folder to /efi/EFI/grub and edit the grub.cfg.
Click to expand...

This should then make the the Intel GPU visible in Windows. Then you can do the gfxcardstatus and driver thing.
 
I'm not entirely certain, you'll most likely have to edit the grub.cfg to match your partitions. Apart from that, just unpacking and placing it in the correct folder should be enough.

I don't really have the time/energy to write good instructions and especially test everything, but I'll try to check this thread somewhat regularly and help out if I can.
 
i have been able to get the iris pro graphics running on my late 2013 rmbp with nvidia dgpu under both windows 8.1 x64 and linux as per the files and info given in this thread
brightness control and sleep doesnt seem to work which are the only major issues

if any people are stuck i can point you in the right direction if need be
as it can be quite cumbersome getting it to work
 
I think the problem is that Apple's EFI does not support Optimus,
both cards are physically active but Windows can't switch to eachother because of missing Optimus support and that's why it fails when waking up from sleep.
 
Yes, I suppose it does wake up correctly, but the display is connected to the wrong card so it stays black. If you want you could try if sleep works with an external monitor (in case that works at all with the intel card on the new mbps).

The MBP does something similar to early revisions of Optimus (actual mux instead of just copying the image from Nvidia->Intel), and does not expose the exact same interface, so the Optimus driver doesn't work with it. You could try the driver from the previous page to see if that helps with sleep, I'm not sure about that.
 
ah- said:
Yes, I suppose it does wake up correctly, but the display is connected to the wrong card so it stays black. If you want you could try if sleep works with an external monitor (in case that works at all with the intel card on the new mbps).

The MBP does something similar to early revisions of Optimus (actual mux instead of just copying the image from Nvidia->Intel), and does not expose the exact same interface, so the Optimus driver doesn't work with it. You could try the driver from the previous page to see if that helps with sleep, I'm not sure about that.
Click to expand...

So could I possibly use an early version of the Optimus driver (possibly modified) to use the switchable graphics?
 
Does anyone know where to find the old 306.37 NVidia drivers or maybe could upload them? Currently downloadable Boot Camp seems to include a newer version which causes a black screen in an EFI installation.

I found the drivers for Toshiba but turns out they're manufacturer-specific: Toshiba drivers contain nvtd.inf while Apple's contain nvao.inf and my Geforce 650M wasn't recognized by Toshiba's drivers. Even if I could tweak the vendor ID numbers in the .inf file it probably wouldn't work.
 
jjarvi said:
Does anyone know where to find the old 306.37 NVidia drivers or maybe could upload them? Currently downloadable Boot Camp seems to include a newer version which causes a black screen in an EFI installation.

I found the drivers for Toshiba but turns out they're manufacturer-specific: Toshiba drivers contain nvtd.inf while Apple's contain nvao.inf and my Geforce 650M wasn't recognized by Toshiba's drivers. Even if I could tweak the vendor ID numbers in the .inf file it probably wouldn't work.
Click to expand...

www.laptopvideo2go.com is your friend
 
I finally found nVidia drivers that work with mid-2012 Retina here:
http://swcdn.apple.com/content/downloads/55/51/041-3891/se4uhpqng48t842cdsosqh28lft54fmswl/BootCampESD.pkg

It's version 296.49 inside that Boot Camp package, I couldn't find 306.37 anywhere but at least this works. Download links for other Mac models that all point to Apple's servers: http://www.cafe-encounter.net/p682/download-bootcamp-drivers

How to find any version by examining Apple's server: http://apple.stackexchange.com/a/59079

thomaskc said:
www.laptopvideo2go.com is your friend
Click to expand...

Thanks for the link, it would have saved me a lot of searching to know that before! However it's a Toshiba driver there. Installation says:

Code: 
NVIDIA Installer cannot continue
This graphics driver could not find compatible graphics hardware.

Maybe you or someone else could post nvao.inf and nvao.cat (or whatever they call the inf and cat files inside the Display.Driver folder of the installer) from NVidia 306.37 drivers as distributed inside Boot Camp? Those files might be enough to get that version working.
 
Last edited:
Potential EFI Modifications

It should be possible to make modifications to Apple's EFI using UEFI tools. The only difference from modifying a normal UEFI would be the rather confusing naming, I believe.
 

Attachments

  • AppleEfiList.txt
    7.9 KB · Views: 1,179
Hi,

I've been reading much of this thread and just registered to post how awesome you guys are for getting this deep into Apple's EFI. I also have a few questions with what else can be done with all your work.

I came across mention of Apple's EFI checking for the kernel flag acpi_osi=Darwin (at least, that's what the Linux developers are using), which would allow all the hardware normally hidden by the EFI to show up in an OS due to "faking" being OS X. Is this the same as "apple_set_os," or does the acpi flag merely show all but the Intel Iris Pro (I can't check for myself because I get a black screen & BCD corruption using nex01's grub loader to apply "apple_set_os")?

Also, I was on Intel's site earlier and I found that they've officially released a Thunderbolt driver for their 4000 and 5000 series controllers (so much for being a "driverless interface"). In combination with the EFI tools mentioned above by shanovan, would it be possible to get native Thunderbolt hotplug support in Windows using the Intel driver (which is indeed compatible with the Late 2013 rMBP) + apple_set_os?

Please excuse me if I'm straying too far away from what you're doing; saying I'm excited by the thought of working around Apple's Windows limitations is an understatement.
 
KNNSpeed said:
Hi,

I've been reading much of this thread and just registered to post how awesome you guys are for getting this deep into Apple's EFI. I also have a few questions with what else can be done with all your work.

I came across mention of Apple's EFI checking for the kernel flag acpi_osi=Darwin (at least, that's what the Linux developers are using), which would allow all the hardware normally hidden by the EFI to show up in an OS due to "faking" being OS X. Is this the same as "apple_set_os," or does the acpi flag merely show all but the Intel Iris Pro (I can't check for myself because I get a black screen & BCD corruption using nex01's grub loader to apply "apple_set_os")?

Also, I was on Intel's site earlier and I found that they've officially released a Thunderbolt driver for their 4000 and 5000 series controllers (so much for being a "driverless interface"). In combination with the EFI tools mentioned above by shanovan, would it be possible to get native Thunderbolt hotplug support in Windows using the Intel driver (which is indeed compatible with the Late 2013 rMBP) + apple_set_os?

Please excuse me if I'm straying too far away from what you're doing; saying I'm excited by the thought of working around Apple's Windows limitations is an understatement.
Click to expand...

Do you have a link to these drivers on the Intel site? I am not able to find these...
 
Last edited:
KNNSpeed said:
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23742

Though it's listed for the DZ87KLT-75K, it works with the 4000, 5000, and 5110 controllers listed here:
http://ark.intel.com/products/family/79641/Thunderbolt-Products

The Late 2013 Retina MacBook Pro uses a DSL5520 controller, listed as "Intel Thunderbolt Controller - 156C" or something like that.
Click to expand...

Ahh, yeah I have installed that driver. Hot plug still does not work (as I am sure you have found out). Just an FYI, that board uses a 3000 series TB chip. I check Intel's site every week or so to see if there is an updated driver.
 
IoN6 said:
Ahh, yeah I have installed that driver. Hot plug still does not work (as I am sure you have found out). Just an FYI, that board uses a 3000 series TB chip. I check Intel's site every week or so to see if there is an updated driver.
Click to expand...

My DZ77RE-75K uses a DSL3310; I thought the DZ87KLT-75K used a DSL4410?

I'm pretty sure hotplug won't work without an EFI edit, like the Intel Iris Pro on the NVidia Retinas. Since an OS identifying itself as a non-Apple OS via ACPI causes the EFI firmware to cut power to the Thunderbolt controller, then it makes sense why hotplug doesn't work.

Linux developers were able to get around this via a similar method as the apple_set_os command written about here, although they used a kernel flag "acpi_osi=Darwin." So it looks like we have the driver component within Windows taken care of; it's just that some EFI trickery (that I honestly have no idea how to do), which may or may not involve grub, is needed to get the EFI firmware to cooperate. Which leads back to my earlier question: Is apple_set_os like acpi_osi=Darwin?
 
KNNSpeed said:
My DZ77RE-75K uses a DSL3310; I thought the DZ87KLT-75K used a DSL4410?

I'm pretty sure hotplug won't work without an EFI edit, like the Intel Iris Pro on the NVidia Retinas. Since an OS identifying itself as a non-Apple OS via ACPI causes the EFI firmware to cut power to the Thunderbolt controller, then it makes sense why hotplug doesn't work.

Linux developers were able to get around this via a similar method as the apple_set_os command written about here, although they used a kernel flag "acpi_osi=Darwin." So it looks like we have the driver component within Windows taken care of; it's just that some EFI trickery (that I honestly have no idea how to do), which may or may not involve grub, is needed to get the EFI firmware to cooperate. Which leads back to my earlier question: Is apple_set_os like acpi_osi=Darwin?
Click to expand...

According to the tech spec it is the Intel L3310L CIO 10Gb Controller.
 
KNNSpeed said:
Hi,

I've been reading much of this thread and just registered to post how awesome you guys are for getting this deep into Apple's EFI. I also have a few questions with what else can be done with all your work.

I came across mention of Apple's EFI checking for the kernel flag acpi_osi=Darwin (at least, that's what the Linux developers are using), which would allow all the hardware normally hidden by the EFI to show up in an OS due to "faking" being OS X. Is this the same as "apple_set_os," or does the acpi flag merely show all but the Intel Iris Pro (I can't check for myself because I get a black screen & BCD corruption using nex01's grub loader to apply "apple_set_os")?

Also, I was on Intel's site earlier and I found that they've officially released a Thunderbolt driver for their 4000 and 5000 series controllers (so much for being a "driverless interface"). In combination with the EFI tools mentioned above by shanovan, would it be possible to get native Thunderbolt hotplug support in Windows using the Intel driver (which is indeed compatible with the Late 2013 rMBP) + apple_set_os?

Please excuse me if I'm straying too far away from what you're doing; saying I'm excited by the thought of working around Apple's Windows limitations is an understatement.
Click to expand...

acpi_osi=Darwin and my grub apple_set_os are different things. The acpi_osi thing is what the kernel reports to the acpi bytecode. If you extract and decompile your acpi tables you can see quite a few if(acpi_osi=Darwin) then to something, else do something else.

apple_set_os deals with the Apple EFI disabling hardware during boot, which happens before the acpi stuff. If the kernel/bootloader doesn't tell the EFI that it is osx before exiting the EFI boot services, the EFI will disable all kinds of hardware by writing into some hardware configuration registers.

So you really need both to get access to all hardware.

Not sure about the Windows thunderbolt driver, it's probably best to read up on the development of the Linux driver, they got pretty far.
 
I see. Thanks for the info!
I'm currently checking out how the Linux developers got it to work, and it seems the biggest thing is to use the kernel flag "acpi_osi=Darwin" on boot.

Would you (or anyone else) happen to know where and how to pass that command on Windows boot so that it overrides "acpi_osi=Windows 2013"? ("Windows 2013" = Windows 8.1, according to Microsoft's documentation.)
 
KNNSpeed said:
I see. Thanks for the info!
I'm currently checking out how the Linux developers got it to work, and it seems the biggest thing is to use the kernel flag "acpi_osi=Darwin" on boot.

Would you (or anyone else) happen to know where and how to pass that command on Windows boot so that it overrides "acpi_osi=Windows 2013"? ("Windows 2013" = Windows 8.1, according to Microsoft's documentation.)
Click to expand...

I don't know if that's easily possible, as pretty much all other ACPIs are written to support Windows. You could try extracting the ACPI tables, decompile them, edit the check and then recompile and override the original ones. I'm pretty sure you can override ACPI tables in Windows if you boot it in developer mode or something.

Not the best solution, as it will only help for your specific firmware version but might be an easy way to see wether the thunderbolt drivers work.
 
Alright, I'll try that. Thanks!

A couple other ideas occurred to me, and I wonder if any of them are possible:

1) Boot a tiny linux kernel with the acpi_osi flag set to trick the EFI, and then from that chainload Windows and unload Linux with all the hardware enabled. In theory I think this could combine both apple_set_os and acpi_osi into one fell swoop, since it would require grub.

2) "Reverse hackintosh," meaning use a custom bootloader similar to chameleon/clover/etc. and feed it a DSDT, which would allow all hardware to work without either using apple_set_os or acpi_osi. I guess this is similar to the above proposal of modifying the Windows acpi tables, except in this case they just get bypassed.
 
Sorry for the double-post, but I figured this would warrant its own bump.

So I managed to get a custom DSDT (ACPI table) loaded in Windows surprisingly easily, and I changed what happens when Windows identifies itself as Windows to the EFI.

Well, the thunderbolt controller shows up--both on startup and after sleep. I can't use any devices without plugging them in at boot time, but the controller shows up without anything attached.

As a side effect, I can't see my battery status any more, but I think I can fix that with some more DSDT hacking.

I'm going to guess that it needs a driver under Windows to work now. The intel driver I linked to seems to be more of a connection manager as opposed to a resource-allocating thing. Maybe a filter driver like is mentioned here (see Liel Lazar's posts) would work?

I was trying to compare the DSDT table of my DZ77RE-75K (which has a perfectly functioning thunderbolt port and uses no driver; it's all handled by the UEFI or the ACPI calls, I'm not sure which), but I can't tell what's going on since I'm just figuring this out as I go.
 
KNNSpeed said:
So I managed to get a custom DSDT (ACPI table) loaded in Windows surprisingly easily, and I changed what happens when Windows identifies itself as Windows to the EFI.

Well, the thunderbolt controller shows up--both on startup and after sleep. I can't use any devices without plugging them in at boot time, but the controller shows up without anything attached.
Click to expand...

Wow, that was pretty fast. Good to hear that it worked this easily.

KNNSpeed said:
As a side effect, I can't see my battery status any more, but I think I can fix that with some more DSDT hacking.
Click to expand...

I'm pretty sure I read something about exactly that. So just finding and modifying the battery switch should fix that.

KNNSpeed said:
I'm going to guess that it needs a driver under Windows to work now. The intel driver I linked to seems to be more of a connection manager as opposed to a resource-allocating thing.
Click to expand...

Yeah this is pretty much what I remember from the lkml posts about the Linux driver. Don't know much more about Thunderbolt, but good luck with getting something running!
 
I feel like this all could be accomplished a lot faster if there were more complete documentation of Apple's custom ACPI 4-character abbreviations. I have no idea what things like "DTGP" or "NPME" stand for. Similarly, Intel's ACPI 4-character names are just as undocumented. Granted, it's possible to figure out some (BAT0 is clearly battery), and most, if not all, of the 3-character abbreviations are documented in the 1000-page ACPI 5.0 specification.

Anyways, I'll put it out there now that I don't think I'll be able to make the driver simply due to the fact that I don't know where to start or really what to do. I can try to figure it out (I think I have all the tools to make one installed), but it'll likely take a while.

Instead, I'm going to see if I can get the ACPI to handle everything pertaining to hotplug a la the DZ77RE-75K, which, if I can even get close, will also take a while since 1000 pages of specification doesn't read/skim itself!

My first priority is to get the battery status working, though, since that's kind of important. I'm under the impression that it should be simple, but it's not been turning out that way (probably because I'm just not seasoned enough to be able to tell where exactly I need to make changes).
 
Bump!

I've got some good news and some weird/kind of unfortunate news.

First, the weird news:
Apple will most likely not make a driver for Thunderbolt on Windows. A benevolent coder would have to instead.

Why do I say this? Because I had to go through and comment out hundreds of lines of code in order to get Thunderbolt to show up under an OS identifying itself as NOT OS X. In other words, it looks like Apple specifically went out of its way to make Thunderbolt not usable for us multibooters.

The good news (and there's quite a bit):
  • It *IS* possible to get Thunderbolt hotplug to work under Windows. I'm certain of it. I'm going to try my "imitate Intel's motherboard" idea and see if that works, otherwise we'll need someone to make a driver.
  • I got the battery indicator to show up!
    In fact, I got EVERYTHING that's normally meant to show up when using Windows to show up properly (with the exception of the Intel iGPU). I found that Apple uses an external SSDT to store all of the Thunderbolt information (SSDT #4, specifically), and by commenting out all of the "If (OSDW())" entries in it, of which there is a TON, I made it so that Thunderbolt shows up natively under Windows and persists through sleep, no OS spoofing needed!

Next step: Let's get hotplug working!

Edit: For the curious, what it seems to me so far is that the problem lies in device enumeration.
We know that ejecting the devices works just fine when Windows is booted with Thunderbolt things plugged in, and what doesn't work is the initial device setup. I can tell that the device is being detected when plugged in (with my hacked ACPI tables in use) because there's a device manager refresh that sometimes occurs.

What the problem looks to be is that the firmware isn't being told to configure the plugged-in device. It is obvious that the firmware CAN enumerate and configure devices; we see it on boot time and it's the only way Thunderbolt devices even remotely work under Windows in the first place. I think hotplug enumeration can be accomplished by making some kind of ACPI event that then takes advantage of the firmware's device configuration ability.

(OR maybe Windows can do all the configuring itself if it's merely told by the ACPI, "hey, buddy, something just got plugged in, go check it out!"--though I'm not 100% if this idea would work.)
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back