Resolved OS X Yosemite on Unsupported Macs [Guide]

[jonobin]

Eh.. It's easier said than done. First I am sure not that skilled in assembler (let alone the one for x86_64. This is the very first time I took a look at it). Then to do any kext debugging and see what really is going on one needs a second Mac, as explained by Apple. Sure one can't put a breakpoint in the frame buffer code while using the same computer, can he?

Oh, and last but not least the assembler crashes. Bloody XCode 6.1...

try posting in the apple support forum, maybe someone can be more helpful that us

 

[Michelasso]

try posting in the apple support forum, maybe someone can be more helpful that us

You think so? I actually believe I would have better chances trying to win the lotto than to get an answer for this there..

 

[jonobin]

any update ?

 

[RV-ABZ]

.

 

[atvusr]

any update ?

Apple has now released the sources of the 10.10 Darwin/XNU Kernel 2782.1.97: www.opensource.apple.com - here the sources as Tarballs.

 

[jonobin]

Apple has now released the sources of the 10.10 Darwin/XNU Kernel 2782.1.97: www.opensource.apple.com - here the sources as Tarballs.

Recompiling at 32 bit can be helpful?

 

[jonobin]

even IO graphics released

 

[Michelasso]

even IO graphics released

IOGraphics has always been there. Apple never published any source code for IOFramebuffer e IOAccelerator kexts basically the ones of the 64 bits kexts we keep installing in the unsupported Macbooks (and different for each GPU). For the IOAccelerator they don't even publish the required APIs.

Having the original source codes of the GMA 950/X3100 kexts in 10.6.2 I don't believe it would take long to make them working compiling them at 64 bits against the last SDKs.

 

[jonobin]

IOGraphics has always been there. Apple never published any source code for IOFramebuffer e IOAccelerator kexts basically the ones of the 64 bits kexts we keep installing in the unsupported Macbooks (and different for each GPU). For the IOAccelerator they don't even publish the required APIs.

Having the original source codes of the GMA 950/X3100 kexts in 10.6.2 I don't believe it would take long to make them working compiling them at 64 bits against the last SDKs.

IO Accelerator

IO Framebuffer

are those what you were searching for?

 

[Michelasso]

IO Accelerator

IO Framebuffer

are those what you were searching for?

If it was that easy I think someone would have published some source code after ML first arrived.

Nah, the IOFramebuffer.cpp looks like the basic class for the frame buffer. I suspect it is the code that runs when the Mac boots in safe mode, w/o frame buffer kext. Then depending on the GPU the class gets extended (by AppleIntelIntegratedFramebuffer.cpp for GMA 950 I suppose), to enable more functionalities depending on the HW. I believe we see that when the background changes from bluish to light beige before the login screen.

From a fast look at IOAccelerator.cpp it seems like it is an interface to build a queue of accelerators, each with its own ID. The kext (AppleIntelGMA950.cpp?) calls it and adds all its accelerators to the kernel. But I really don't have a clue about how this works, I am just guessing. As I wrote this doesn't seem to be documented either in the Kernel Framework Reference.

This isn't really my area of expertise, the chances that I am writing a bit too much crap are high.

 

[jonobin]

If it was that easy I think someone would have published some source code after ML first arrived.

Nah, the IOFramebuffer.cpp looks like the basic class for the frame buffer. I suspect it is the code that runs when the Mac boots in safe mode, w/o frame buffer kext. Then depending on the GPU the class gets extended (by AppleIntelIntegratedFramebuffer.cpp for GMA 950 I suppose), to enable more functionalities depending on the HW. I believe we see that when the background changes from bluish to light beige before the login screen.

From a fast look at IOAccelerator.cpp it seems like it is an interface to build a queue of accelerators, each with its own ID. The kext (AppleIntelGMA950.cpp?) calls it and adds all its accelerators to the kernel. But I really don't have a clue about how this works, I am just guessing. As I wrote this doesn't seem to be documented either in the Kernel Framework Reference.

This isn't really my area of expertise, the chances that I am writing a bit too much crap are high.

these are from yosemite I think

 

[Michelasso]

these are from yosemite I think

It doesn't matter. Those modules you mentioned are already compiled, installed and working in any OS X installation. What is needed (and most likely will never see the light in public) are the source codes for the kexts themselves. The ones that interface (or whatever they do) with the two modules you posted. They are external pieces of SW, a different set for each different GPU.

It's like in Windows. One buys a new graphics card and get a DVD with the device drivers for it (well, I suppose they still give the DVD). Otherwise it can be downloaded from the web. All that additional software has been obviously compiled from some source code. We need the equivalent of that source code for OS X. At least for what pertains the GPU device drivers. Intel sure has it, but like Apple they don't disclose it (and so much for the "open sourceness" of OS X).

But you know, if you feel brave enough you may try contacting Intel and see if they can allow access to the 10.6.2 source codes for the GMA GPUs.

 

[Michelasso]

Interesting. I've found a project of a developer who has been faking the HW acceleration in the VMware OS X virtual machines:

http://sourceforge.net/p/vmsvga2/code/HEAD/tree/

That doesn't mean the OS X VMs get HW accelerated. Instead these kexts make OS X up to 10.8.5 (I think I've read some reporting it works in Mavericks as well, but it's broken in Yosemite) believing the HW acceleration is in place, which allows the VM to run graphics applications. Like the DVD player for instance (with the performances one may imagine. Apart that with an Intel i7 under the hood they might not be that bad). I wonder if it gets the translucent bar as well.

Too bad that guy (or girl) should be a PC user, without an unsupported MacBook with GMA graphics. These were the kind of skills needed to make this stuff working.

PS: jonobin, that is a possible extension of the IOFramebuffer and IOAccelerator, the stuff I was talking about. Obviously it works only with the virtual SVGA2 GPU in the VMware virtual machines..

 

[Chasez671]

So taking another look at our possible options for hardware acceleration, we have:

-Clover FakeID making HD3000 kext think GMA is a HD3000(Not yet tested)
-Source codes released(Not likely)
-Using MacPostFactor 32bit kext (Not yet released/Not confirmed)

Is that correct?

 

[jonobin]

https://twitter.com/wayne_819/status/528519862142763008

What the hell is wayne saying? This drives me mad

 

[maxevens]

Anybody know how to fix iMessage/FaceTime? Because I found solutions only for hackintosh with Clover method... It isn't work with real macs....

 

[jonobin]

just talking hypotetically, can be builded a kernel that runs 32 and 64 bits kexts?

here is the guy that has compiled a 32bit kernel for mountain lion, maybe we can ask him to do the same for yosemite

 

[jonobin]

a wrapper to load 32bit kext as 64 like this project http://nspluginwrapper.org/ can be a good "new" start

and

here is a decompiler, maybe someone can give it a try

and a post quoted from an unknown site
"you can use gdb (as nate c suggested) to inspect the assembly code of a kernel extension. i'm not aware of any decompilers for kernel extensions specifically.

you can use the kextload tool to create a symbols file that you can load into gdb. this will let you see decoded symbol names for functions, &c. there's a crash (haha get it?) tutorial here: http://praveenmatanam.wordpress.com/2008/05/22/kext-debugging-on-mac/ "

@michelasso can this help you?

 

[Michelasso]

So taking another look at our possible options for hardware acceleration, we have:

1. Clover FakeID making HD3000 kext think GMA is a HD3000(Not yet tested)
2. Source codes released(Not likely)
3. Using MacPostFactor 32bit kext (Not yet released/Not confirmed)

Is that correct?

1. Tested, for what it was worth it. Obviously not a chance
2. That would be the right solution
3. Well, we'll see. Although I'd love to know which 32 bits kernel they are using.

Anybody know how to fix iMessage/FaceTime? Because I found solutions only for hackintosh with Clover method... It isn't work with real macs....

Take a look at post #212

a wrapper to load 32bit kext as 64 like this project http://nspluginwrapper.org/ can be a good "new" start

That's to load 32 bits web plugins in a 64 bits web browser.. Totally useless.

and

here is a decompiler, maybe someone can give it a try

and a posted quoted from an unknown site
"you can use gdb (as nate c suggested) to inspect the assembly code of a kernel extension. i'm not aware of any decompilers for kernel extensions specifically.

you can use the kextload tool to create a symbols file that you can load into gdb. this will let you see decoded symbol names for functions, &c. there's a crash (haha get it?) tutorial here: http://praveenmatanam.wordpress.com/2008/05/22/kext-debugging-on-mac/ "

@michelasso can this help you?

Yes, that is how you debug a kext indeed, as the Apple documentation reports. But yet again, you need a second Mac. Then it isn't really possible to disassemble and recompile a Mach-O binary. I tried downloading the GNU binutils (with Brew). I get more detailed info and labels with offsets for the branches, but even getting a fully recompiled ASM code it would be a nightmare. Unless one speaks ASM as if it was his or her mother tongue, sure.

Also even in a magic world, where there is a wrapper for the 32 bits kexts, they couldn't work either. The I/O kit keeps changing, they could not hook correctly.

What pisses me off (pardon my French) anyway is the Backlight. I made a small Swift program to get and set the brightness. The reading is fine, the setting obviously doesn't work. The IO routine even returns a kernel error with a crazy error number.

I attach the code for anyone who is interested experimenting..

 

[jonobin]

Yes, that is how you debug a kext indeed, as the Apple documentation reports. But yet again, you need a second Mac. Then it isn't really possible to disassemble and recompile a Mach-O binary. I tried downloading the GNU binutils (with Brew). I get more detailed info and labels with offsets for the branches, but even getting a fully recompiled ASM code it would be a nightmare. Unless one speaks ASM as if it was his or her mother tongue, sure.

Also even in a magic world, where there is a wrapper for the 32 bits kexts, they couldn't work either. The I/O kit keeps changing, they could not hook correctly.

What pisses me off (pardon my French) anyway is the Backlight. I made a small Swift program to get and set the brightness. The reading is fine, the setting obviously doesn't work. The IO routine even returns a kernel error with a crazy error number.

I attach the code for anyone who is interested experimenting..

A VM can do the work?

posted on an hackintosh forum with some other people interested on this, hope someone can help :|

 

[Michelasso]

A VM can do the work?

posted on an hackintosh forum with some other people interested on this, hope someone can help :|

A what? A virtual machine? If the HW acceleration isn't enabled in the physical machine even less it can be done in a virtual machine.

I think you're putting too much hope into this. To get the HW acceleration w/o having any supported graphics kexts is a enormous task. It could be done on MLPf because ML DP1 was at 32 bits (and thus it was possible to squeeze the Lion kexts into it). With Mavericks/Yosemite we are lucky that Tiamo and Pike made the working boot.efi and that Apple included the infamous 64 bits kexts for GMA on SL 10.6.2, which partially work. Otherwise all MacBooks would have kissed goodbye to anything beyond Lion.

 

[jonobin]

A what? A virtual machine? If the HW acceleration isn't enabled in the physical machine even less it can be done in a virtual machine.

I think you're putting too much hope into this. To get the HW acceleration w/o having any supported graphics kexts is a enormous task. It could be done on MLPf because ML DP1 was at 32 bits (and thus it was possible to squeeze the Lion kexts into it). With Mavericks/Yosemite we are lucky that Tiamo and Pike made the working boot.efi and that Apple included the infamous 64 bits kexts for GMA on SL 10.6.2, which partially work. Otherwise all MacBooks would have kissed goodbye to anything beyond Lion.

a VM to debug kexts of course, I know that in a VM we can't get HW acceleration

 

[Michelasso]

Ô rage ! Ô désespoir...

No magic potion then, eh?

There are not magic potions in IT. They all are a bunch of 0 and 1. You can run OS X in your hackbooks only because some very skilled people spent a considerable amount of time developing, also for free, the needed tools, kexts and installers. Including patching at the byte level the official kexts when and if possible.

The GMA kexts for the frame buffers are indeed perfectly writable having the skills, the tools and the time. Not so much the accelerators, which are not publicly documented. If you want to give it a shot developing them in C++ (not just C, I was slightly wrong on this that time. Still the code inside the methods and functions is usually just C) be our guest.

 

[Michelasso]

a VM to debug kexts of course, I know that in a VM we can't get HW acceleration

That isn't possible first of all because the VMs do not use the GMA GPUs but instead their own virtual ones. And sure one can't debug from a VM guest the kexts of its hosts. Even if it would be possible to set up a remote debugging VM <-> Host via the virtual IP interfaces that can't be done for the hosting kernel. The VM obviously starts after the kernel has booted.

 

[jon8214]

Does anyone know as yet wether we can update to 10.10.1 ? Or has Apple forced the system check again?