d3vi1 helped me try this out on my mid 2010 Mac Mini and unfortunately we were unsuccesfull. ( LG M2261V monitor and NVidia GEforce 320M )
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
d3vi1 helped me try this out on my mid 2010 Mac Mini and unfortunately we were unsuccesfull. ( LG M2261V monitor and NVidia GEforce 320M )
I don't, not by far, since I'm not a programmer, but out of sheer luck I figured out what's wrong and have enough spare time to try to fix it. Who knows, maybe knowing C is not such a bad thing (N.B.: no, it wasn't a deliberate flaming attempt, just an attempt at humor). I did manage to write the static app for my specific computer, so not being a programmer hasn't stopped me. I also expect it not to stop me down the road since we are really talking about a 600 line app (currently ~300).
From what I can tell, EFI is attempting to do as little as possible for setting up the hardware. It only attempts to be able to read and execute the OS loader (with the dependencies implied such as TCP/IP for network booting) and to give it access to a few basic resources (keyboard, mouse (including BT), disk, frame buffer). It does not set PCI registers (unless required by EFI drivers), it does not allocate IRQs, it does not do anything that is not strictly required as it assumes there's a lot more intelligence in an OS than in the Firmware. I'm all for that. You do get access to ACPI and SMBIOS which are proven technologies that are not limited by age (like the BIOS).
What Windows expects and tries to do is actually mostly beyond me. I'm a UNIX admin that started programming in C specifically for this project out of frustration. See PM for details on getting access to my results until now. I want 6-7 operating systems on the same hard-disk in multi boot on my 3000 laptop.
NT4? I'm willing to bet that the code in question was there in all NT editions starting from the elegant 3.1/3.5/3.51 series! Might actually be as old as OS/2. Maybe we should give it some due respect. After all, it's been there in all major releases of the NT line until now and worked for x86. No, just kidding...
No, it's not EFI that should do that because EFI shouldn't make assumptions on what the loaded OS needs. Graphics is just like any other EFI provided function. Some OS or configurations might not need graphics, just like they might not need block device, mouse, keyboard, network or others. Based on ACPI information, the OS and it's drivers should do that and not EFI. EFI, by design doesn't do stuff that's not needed for chain loading the OS. This design keeps the amount of EFI implementation bugs to a lower level as well as allows future OSs with unpredictable hardware access strategies and needs do their own thing with the hardware. Don't assume that Windows 8 will need the same resources from the Firmware as Windows 7. We can rephrase that as: don't model a firmware on current OS releases needs, model it on ANY OS releases (including yet to be released ones).
Planned, but there are a few other things in the pipeline before that.
They actually should. AMD had a presentation about their EFI readiness state at a Microsoft hosted EFI Plugfest saying that the successfully booted Windows.Next using EFI only technologies and specifically not VGA option ROMs. See second paragraph, page 22. Actually, the whole presentation highlights the fact that Windows is not yet ready for EFI in the graphics department. Maybe I should try a leaked build of Windows.Next. Just need to reach those 10 posts in BA.
A GOP frame buffer driver for Windows? Try UGA. I don't think Windows in it's current version reacts nicely to a limitation of the available resolutions, refresh rates, and bit depths as is the case with GOP. In UGA you get lower level access to the hardware and can set your own resolution, refresh rate and a few other things. Apple's EFI implementation implements both for x64 firmwares (that is, UEFI firmwares).
In the long run, I think that writing a VGASave replacement that implements GOP, UGA and VGA (in that order) could save the day. However I already took on one big learning project for C when I decided to do this EFI app. Learning the insides of Windows NT is not really something I feel like being able to do.
As a side note, I'm curious about how much access you get to the EFI runtime services from Windows. Could I write a Windows APP to modify NVRAM variables? Apple's bootcamp startup disk app does that, but I'm not sure if it's through a Microsoft supported NVRAM manipulation API since I don't think we have any. I would really love to see a smarter startup disk app for both Windows and Mac.
They weren't really hacks. The specific hardware support came from the OEM that gave HAL disks and driver disks. X86 and ARM are the only one where you have so much variation and no standards set in stone, just de-facto standards. PPC, MIPS and Alpha came with predictable firmwares (like OpenFirmware for PPC and Sparc). The OEMs (which was usually just one or two for each arch) would support Microsoft in customizing Windows for their arch to the extent of it working better than x86. It used to just work.
There are really three categories of hardware:
1) NVidia Dual GPU. As you stated, there is a problem with the firmware settings. EFI uses the Integrated GPU but blesses the discrete. That's what I saw on another 15" MBP 5,something.
2) Intel+[NVidia|ATI] GPU. Basically, any Core i5/i7 MBP. The intel card is available but unused in EFI. There is even an EFI driver for it (Ironlake in MBP6,1 and SandyLake in MBP8,something), but it's completely unused by the firmware. Windows doesn't care about it. Windows cares only about VGAE.
3) NVidia only GPU. This is my 24" iMac, which still requires VGAE.
Without VGAE you get blank regardless of driver (VGA or NVidia).
That was my first guess too. I also tried forcing a resolution on the video driver and it didn't work. A VNC server reported the frame buffer size to be an invalid 0x0.
Linux works without a problem on all macs in version 3.0+ if you disable the integrated Intel. If you have one or without Intel, it just works. I tried Alpha 3 of Ubuntu and daily builds. Previous releases required noefi as a kernel flag which brought some disadvantages, but that is not required anymore. Adding i915 to the blacklist or simply hiding the card with 00:00.00 54h=3 does the job.
I'm a programmer and have made a hybrid GPT/MBR boot (chain) loader, based on FreeBSD sources, but I must say that what you did is quite beyond what I ever managed to do. Congrats, and despite being convinced that you can handle everything yourself, I'm lending a helping hand whenever you feel like using it
And am I just being thick or is the PM system on this forum completely abnormal? I can't seem to find it anywhere...
Oh, I see. I must have a minimum of 5 written posts. I guess I'll have to post some filler stuff
AHCI works already!
You can enjoy full AHCI already if you have a Mac that's based on an Intel chipset.
Check this topic and this link for the AHCI enabler. It worked fine on my MBP6,2.
My interest in EFI lies in having several OSs installed on my Mac while not resorting to extended MBR partitions. The faster boot from not loading the CSM is quite a boon, too.
You can enjoy full AHCI already if you have a Mac that's based on an Intel chipset.
Check this topic and this link for the AHCI enabler. It worked fine on my MBP6,2.
My interest in EFI lies in having several OSs installed on my Mac while not resorting to extended MBR partitions. The faster boot from not loading the CSM is quite a boon, too.
Reply to Thread
Ah. Actually the way video drivers work in Windows, I think GOP is the better bet for exactly the reason you suggest it isn't. Changing resolutions and such is a whole 'nother level of coding. There are two parts to XP era graphics drivers (which work fine on vista/7 for our purposes.) The miniport driver which is a standard windows driver. Mine is going to be blank mostly because there is no actual physical adapter. Then there is the graphics driver itself which is hardly a driver at all. It is more like a DLL and calls and is called by some .sys files.
One of the things the driver has to export are the available modes. Since kernel mode drivers have full access to all of system memory (the driver itself runs in its own virtual address space tho) it is theoretically very easy to read the modes supported by the EFI framebuffer when windows asks for the modes supported by the driver. According to what you said before, in the case of MacBooks, this will always be the native resolution of the display. To me, for the purpose of loading WinPE for installing windows, this is perfect just the way it is.
Windows video driver tutorials are a dime a dozen on the net and there are open source GOP/efifb working implementations for linux and other os'es. UGA will not be the future going forward for Macs or any other UEFI platform. (Emphasis on the U, as Intel claims they still have customers licensing EFI from them.)
Sure. I have build 7959. I don't recall ever having installed it. It is 9 months outdated and people say its bugginess is beyond useable. However it is the first leaked x64 edition of Windows 8 and it is a Server edition at that. If there is new EFI support it is probably in this build. I'll check it out. FYI I'm no pirate, I do pay for my bits but I have an exception to the rule that I am fine with sharing as long as it is something that isn't for sale.
MCFG tables are part of the PCI, PCI-x, and PCI express specs. If there are no tables then the platform is non PCI compliant.
THANKS for the link!
No. User mode applications in Windows run in a virtual address space. You can however make a frontend app (or a .cpl like Apple) that calls a NVRAM driver. This is what Apple does as part of the Bootcamp driver install. Kernel mode drivers in NT run in their own kernel space called a "segment" but have complete access to all of system memory. (So long as they don't try mixing the two together. Which results in a blue screen.) If you can compile a .dll you can totally make a driver too. Just use this link to build it.
I have confirmed the int 10h calls are hardcoded into the HAL, so I might possibly want to just give up now on my project (but not yours.) I'll have to write the miniport driver in a peculiar way. Virtual graphics drivers for Windows are a dime for a dozen on the interweb, like for example writing the video data to a file. Writing to a buffer should be way easier than to a disk but these types of things are used as secondary adapters with Windows still booting from real hardware. I have no idea how the HAL will react to this. In other words, how does one set the VGAE register for a virtual device driver?
Ah. Actually the way video drivers work in Windows, I think GOP is the better bet for exactly the reason you suggest it isn't. Changing resolutions and such is a whole 'nother level of coding. There are two parts to XP era graphics drivers (which work fine on vista/7 for our purposes.) The miniport driver which is a standard windows driver. Mine is going to be blank mostly because there is no actual physical adapter. Then there is the graphics driver itself which is hardly a driver at all. It is more like a DLL and calls and is called by some .sys files.
One of the things the driver has to export are the available modes. Since kernel mode drivers have full access to all of system memory (the driver itself runs in its own virtual address space tho) it is theoretically very easy to read the modes supported by the EFI framebuffer when windows asks for the modes supported by the driver. According to what you said before, in the case of MacBooks, this will always be the native resolution of the display. To me, for the purpose of loading WinPE for installing windows, this is perfect just the way it is.
Windows video driver tutorials are a dime a dozen on the net and there are open source GOP/efifb working implementations for linux and other os'es. UGA will not be the future going forward for Macs or any other UEFI platform. (Emphasis on the U, as Intel claims they still have customers licensing EFI from them.)
Sure. I have build 7959. I don't recall ever having installed it. It is 9 months outdated and people say its bugginess is beyond useable. However it is the first leaked x64 edition of Windows 8 and it is a Server edition at that. If there is new EFI support it is probably in this build. I'll check it out. FYI I'm no pirate, I do pay for my bits but I have an exception to the rule that I am fine with sharing as long as it is something that isn't for sale.
MCFG tables are part of the PCI, PCI-x, and PCI express specs. If there are no tables then the platform is non PCI compliant.
THANKS for the link!
No. User mode applications in Windows run in a virtual address space. You can however make a frontend app (or a .cpl like Apple) that calls a NVRAM driver. This is what Apple does as part of the Bootcamp driver install. Kernel mode drivers in NT run in their own kernel space called a "segment" but have complete access to all of system memory. (So long as they don't try mixing the two together. Which results in a blue screen.) If you can compile a .dll you can totally make a driver too. Just use this link to build it.
I have confirmed the int 10h calls are hardcoded into the HAL, so I might possibly want to just give up now on my project (but not yours.) I'll have to write the miniport driver in a peculiar way. Virtual graphics drivers for Windows are a dime for a dozen on the interweb, like for example writing the video data to a file. Writing to a buffer should be way easier than to a disk but these types of things are used as secondary adapters with Windows still booting from real hardware. I have no idea how the HAL will react to this. In other words, how does one set the VGAE register for a virtual device driver?
But UGA was deprecated by UEFI 2.0. I don't think its presence should be relied upon, especially if future versions of Windows are being targeted. It's quite possible that .Next already supports GOP while skipping UGA altogether.
That's exactly what got me curious into the VGA PCI regs. I noticed the AHCI regs and was curious if there are others that are different so I went and did dumps in the EFI Shell in EFI mode and in a DUET loaded version under the CSM.
Just like what got me started.
Great! Looking forward to it. I would like to mention that I believe a successful driver is one that replaces VGASave. VGASave has a special behavior compared to other drivers and a GOPSave is exactly what you would need on EFI systems. VGA Save doesn't do PCI device lookups or anything else. It just attempts to use int10h blindly.
The difference between EFI 1.1 and UEFI 2.1 is minimal. It's nothing that breaks compatibility. Anything written for 1.1 should work for 2.1.
Intel's customers for EFI 1.1 should be the Itanium customers.
The MCFG tables are there, if I understood them correctly. I can set the PCI Configuration registers from EFI. If you look at the 'mm' EFI Shell app, you have 4 types of access: Straight memory access, PCI/PCIE configuration regs, IO Ports and memory mapped IO.
I would imagine that there's also a kernel driver involved for NVRAM access but I was wondering if in Windows x64 UEFI edition you get one from Microsoft or have to write your own. It would be neat to have one from Microsoft (since NVRAM is standardized in EFI, unlike in BIOS), and access it from WMI.
You don't need to. The RDP virtual devices don't care about the VGAE register, thus the Remote Desktop actually works. The RDP devices are as real from a Windows perspective as any others. In GOP you can work on a multi-card system and not even know what video adapter you're using. Just write with GOP specified pixel formats (usually BGRA) at the frame buffer offset with the dimensions that GOP is giving you and you're set. My question is how will you find the GOP after ExitBootServices() runs. You need the active video card EFI_HANDLE or at least the GOP Protocol linked to it. Once you find it (Linux SRC might help you with a way to find it), the rest of the driver should be trivial. It would be nice if the PreOS Windows would just hand GOP over to you, but I don't think they do that. I think that once ntoskrnl starts running there's nothing left of winload and bootmgr.
Thanks for that! This 'trick' has been around for a while now but I don't like to patch the bootloader in order to switch the controller mode to AHCI.
Also, as you wrote, I'd like to get rid of the MBR limitations and have proper power management (seems as it's not fully implemented in Apples CSM).
Great to see that d3vi1 is trying to get the EFI booting working for everyone!
I have a Mac Mini Model 2011 with a built in Intel Grapics HD 3000 and am waiting as well to install the EFI Windows.
From the posts from d3vi1 I read that the problem is with the Graphics drivers and some old fashioned BIOS VGA interupt calls from Windows 7. d3vi1 blames Windows for this implementation. But ... I have read posts from users with EFI motherboards who have no problem at all to install Windows 7. How is it possible that they can install Windows 7 without messing with video drivers, etc.?
I have a Mac Mini Model 2011 with a built in Intel Grapics HD 3000 and am waiting as well to install the EFI Windows.
From the posts from d3vi1 I read that the problem is with the Graphics drivers and some old fashioned BIOS VGA interupt calls from Windows 7. d3vi1 blames Windows for this implementation. But ... I have read posts from users with EFI motherboards who have no problem at all to install Windows 7. How is it possible that they can install Windows 7 without messing with video drivers, etc.?
If I'm not mistaken, it's because motherboards with UEFI on them still use "standard" videocards, with means the graphic card itself it still using/loading a "BIOS"...
The problem we have here is that I think that when our Mac boot in EFI mode, it provide no video BIOS whatsoever.
So, on a PC, we have a kind of hybrid UEFI, as in EFI for motherboard and BIOS for GPU, and on a Mac we either have 100% EFI for OS X or 100% BIOS for bootcamp.
The problem we have here is that I think that when our Mac boot in EFI mode, it provide no video BIOS whatsoever.
So, on a PC, we have a kind of hybrid UEFI, as in EFI for motherboard and BIOS for GPU, and on a Mac we either have 100% EFI for OS X or 100% BIOS for bootcamp.
I hope you are mistaken. BIOS is real mode, 8086-class code. EFI is 32 bit at a minimum. If Windows is doing something to lower the CPU mode, execute initialisation gunk and spring back into virtual mode, I'm so giving Microsoft both my middle fingers that I'll simply refuse running that disgrace of an OS ever again. =P
Ideas, d3vi1? nemomeansnobody?
Heh..
I'm just trying to understand it myself, which I don't think I do 100%
Anyway, if anyone can make it clearer, go ahead
I'm just trying to understand it myself, which I don't think I do 100%
Anyway, if anyone can make it clearer, go ahead
Yes, there are still questions about why users with EFI motherboards can install
Windows 7 easily.
However, some user on another forum made some progress on how to get the
Windows logo animation visible. He reports:
-----
"If you set the resolution to 1024×768 (not stretched) in OSX, after restart,
the pre-boot EFI environment also gets that resolution, which is compatible with Windows 7 EFI Boot.
I can now see the Windows logo animation but still, it hangs there “animating”
all the time never starting the installation itself."
-----
----------
Also I think it might be that the explanation of FrancoisC is correct. The videocards for PCs have their own VideoBIOS, which could explain why it works.
Windows 7 easily.
However, some user on another forum made some progress on how to get the
Windows logo animation visible. He reports:
-----
"If you set the resolution to 1024×768 (not stretched) in OSX, after restart,
the pre-boot EFI environment also gets that resolution, which is compatible with Windows 7 EFI Boot.
I can now see the Windows logo animation but still, it hangs there “animating”
all the time never starting the installation itself."
-----
----------
Also I think it might be that the explanation of FrancoisC is correct. The videocards for PCs have their own VideoBIOS, which could explain why it works.
VGA Emulation
There are two aspects with VGA.
First: you don't actually need it if you have a real driver. You need it only for Windows Setup and Windows Safe Mode.
Second: if you happen to need it for those two parts, there is a solution: shadow the ROM at C0000h and set the correct int10h value. The Option ROM has two entry points: One for POST of the Video card which is at the beginning of the ROM and is not needed by us since the card was initialized by the EFI environment and one for the runtime services which is needed by VGA and VESA BIOS Extensions.
The second one is the problematic one. The ROM you just "copy+paste" (aka BS->CopyMem) from where you find it (FirmwareVolumeProtocol, PCI Option ROM base address or a file on the disk that you loaded in RAM). The int10h value is a bit more complicated since it has to be either generated by POST-ing the ROM or hardcoded in the boot loader that I'm writing for each unique option ROM. The best approach is to POST the ROM, but that cannot happen in EFI without a bit of magic. Fortunately, the guys a SciTech wrote an x86 emulator specifically for this task (for use with XFree86 on non x86 architectures). I will attempt to port it to EFI and use it in the app.
I am a bit concerned that the x86 emulation might be more than my programming skills (or lack of thereof) can handle. But I've made it this far until now.
P.S.: More testers are welcomed. Contact via PM.
There are two aspects with VGA.
First: you don't actually need it if you have a real driver. You need it only for Windows Setup and Windows Safe Mode.
Second: if you happen to need it for those two parts, there is a solution: shadow the ROM at C0000h and set the correct int10h value. The Option ROM has two entry points: One for POST of the Video card which is at the beginning of the ROM and is not needed by us since the card was initialized by the EFI environment and one for the runtime services which is needed by VGA and VESA BIOS Extensions.
The second one is the problematic one. The ROM you just "copy+paste" (aka BS->CopyMem) from where you find it (FirmwareVolumeProtocol, PCI Option ROM base address or a file on the disk that you loaded in RAM). The int10h value is a bit more complicated since it has to be either generated by POST-ing the ROM or hardcoded in the boot loader that I'm writing for each unique option ROM. The best approach is to POST the ROM, but that cannot happen in EFI without a bit of magic. Fortunately, the guys a SciTech wrote an x86 emulator specifically for this task (for use with XFree86 on non x86 architectures). I will attempt to port it to EFI and use it in the app.
I am a bit concerned that the x86 emulation might be more than my programming skills (or lack of thereof) can handle. But I've made it this far until now.
P.S.: More testers are welcomed. Contact via PM.
Windows 8
François reported that Windows 8 beta works out of the box on Macs in EFI mode (as suspected) and I'm downloading it right now. Do give it a try and post the results along with your Mac hardware version. Those Macs that are able to boot the Windows 8 installer in EFI mode should also work with Windows 7 once we have all the proper stuff working in the App.
See:
http://msdn.microsoft.com/en-us/windows/apps/br229516
François reported that Windows 8 beta works out of the box on Macs in EFI mode (as suspected) and I'm downloading it right now. Do give it a try and post the results along with your Mac hardware version. Those Macs that are able to boot the Windows 8 installer in EFI mode should also work with Windows 7 once we have all the proper stuff working in the App.
See:
http://msdn.microsoft.com/en-us/windows/apps/br229516
Windows 8 Official Preview
haven't had a chance to check it out yet and investigate if any of the stuff AMD said in their efi readiness summit is in here:
http://msdn.microsoft.com/en-us/windows/apps/br229516
anybody?
----------
double post. gah if only i hadnt taken the time to check my spelling !!!!
haven't had a chance to check it out yet and investigate if any of the stuff AMD said in their efi readiness summit is in here:
http://msdn.microsoft.com/en-us/windows/apps/br229516
anybody?
----------
double post. gah if only i hadnt taken the time to check my spelling !!!!
It booted successfully on an MBP5,3 and I am waiting for the latest Eureka episode to finish until I try to install it on my MBP6,2.
Windows 8 mostly works in EFI
It worked like a charm on an empty hard-drive. If another OS is already there, the setup is flaky and kept giving me errors on installing the bootloader in the EFI System Partition.
I've installed it on another harddrive on both MBP5,3 and MBP6,2. It works using the GOP framebuffer but with no accelerated Video drivers unless you enable VGA PCI Registers. Once you enable them for the same video card that the GOP protocol is using, it works like a charm including the logo and the video acceleration.
The OS feels very unfinished, which is to be expected, but from our perspective, we have what we want.
The name of the GOP Video Driver is "Basic Display Driver". I'll dig more into it later on, as well as try to install it in Windows 7.
Here's a screenshot of the installation using the integrated GPU (not the discrete one) on MBP5,3.
From what I can tell, the VGA ROM loading part is not required anymore, it's just the PCI Register setting that is required from now on if you want to use the accelerated drivers. Furthermore, the GOP pre-GUI implementation is no longer limited to 1024x768 and 800x600. It draws at the center of the screen regardless of the native panel resolution. The GUI GOP implementation uses the full LCD panel resolution, even in Setup mode.
My take on this: they should backport the GOP framebuffer driver to Vista SP.next and Windows 7 SP.next. You can't otherwise claim UEFI compatibility without that.
Cheers,
R.
It worked like a charm on an empty hard-drive. If another OS is already there, the setup is flaky and kept giving me errors on installing the bootloader in the EFI System Partition.
I've installed it on another harddrive on both MBP5,3 and MBP6,2. It works using the GOP framebuffer but with no accelerated Video drivers unless you enable VGA PCI Registers. Once you enable them for the same video card that the GOP protocol is using, it works like a charm including the logo and the video acceleration.
The OS feels very unfinished, which is to be expected, but from our perspective, we have what we want.
The name of the GOP Video Driver is "Basic Display Driver". I'll dig more into it later on, as well as try to install it in Windows 7.
Here's a screenshot of the installation using the integrated GPU (not the discrete one) on MBP5,3.
From what I can tell, the VGA ROM loading part is not required anymore, it's just the PCI Register setting that is required from now on if you want to use the accelerated drivers. Furthermore, the GOP pre-GUI implementation is no longer limited to 1024x768 and 800x600. It draws at the center of the screen regardless of the native panel resolution. The GUI GOP implementation uses the full LCD panel resolution, even in Setup mode.
My take on this: they should backport the GOP framebuffer driver to Vista SP.next and Windows 7 SP.next. You can't otherwise claim UEFI compatibility without that.
Cheers,
R.
Attachments
There are a few version numbers that you can refer to.
1) "EFI Version" number is declared to be 1.10. While trying different EFI64 Macs, even if the declared version number is 1.10, I've found them to be 100% compatible with 2.10. This generally refers to the protocols that are implemented by the Macs.
2) Apple "EFI Version" which usually refers to the release of the firmware pkg. It has nothing to do with anything logical for us mortals. Some older Macs have 2.0 releases and newer ones have 1.0 releases.
All current Macs, regardless of the declared EFI Version or the firmware update package EFI version implement UEFI 2.10 or 2.30.
Actually the mid-2011 Macs don't even implement the deprecated EFI 1.10 protocols.