Looks like someone answered your question on the other forum.
"if you use clover, you can try the FakeID feature
http://clover-wiki.zetam.org/Configuration/Devices#FakeID
but cannot guarantee that it will work"
Would FakeID be an option?
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.
Resolved OS X Yosemite on Unsupported Macs [Guide]
- Thread starter TMRJIJ
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Looks like someone answered your question on the other forum.
"if you use clover, you can try the FakeID feature
http://clover-wiki.zetam.org/Configuration/Devices#FakeID
but cannot guarantee that it will work"
Would FakeID be an option?
I only have that mac at the moment, really don't want to mess it up
if some one else has a test machine and want to test would be very appreciated
I only have that mac at the moment, really don't want to mess it up
if some one else has a test machine and want to test would be very appreciated
What test machine? You have the test machine. Just attach a spare USB drive and do the installations in there. One for each partition you decide to make (30GB per partition are enough).
What test machine? You have the test machine. Just attach a spare USB drive and do the installations in there. One for each partition you decide to make (30GB per partition are enough).
Well, right now I'm working on this mac, even if apple thinks that is as improductive to don't upgrade it, I don't want to mess it all up while I don't have another operating machine around me.
Neither I have the knowledge to do this kind of things
It's easy, actually. What you do using the internal HDD can be done with an USB disk. This is how I proceeded:
- I took the old 80GB HDD I had before upgrading to my 500GB SSHD and put it in a USB case.
- Made 4 partitions (GUID table format) with Disk Utility
- Made the Mavericks install disk in the first partition
- Installed Mavericks in the second partition
- Made the Yosemite installation in the 3rd partition
- Installed Yosemite in the 4th partition
One just needs to be aware of using the right partitions when installing/making the installation "key" (Sfott terminology). Funny enough, the Yosemite installation even made the recovery partition in the USB! It never happened before.
You know, this isn't crappy Windows. One can choose any partition and once it boots it becomes the root one. You can also boot from your USB backups made with "Carbon Copy Cloner" or "SuperDuper!". It saved my butt a couple of times when my internal HDD(s) failed.
I'm not that stupid, I have 3 partitions on my mac: snow Leopard - Lion - Yosemite, but if I don't know how to patch kext adding partitions can't let me do that
I have a MacBook 3,1 and I installed Yosemite on it. I installed 64bit kext for my Intel gma X3100 (only frame buffer works) and for audio. Everything seems to work (expect full graphics support) and iMessage/FaceTime and Maps. How can I use these apps? iCloud works fine. I can't log in to my iMessage and FaceTime account. :'(
UPDATE:
What about Brightness? Why I can't change it? And sleep? Why I can't wake up my machine after it went to sleep? Anyone knows how to FIX this type of window glitch?
UPDATE:
What about Brightness? Why I can't change it? And sleep? Why I can't wake up my machine after it went to sleep? Anyone knows how to FIX this type of window glitch?
Last edited:
we are waiting for Wayne to release MacPostFactor to resolve all these issues
if you want you can try installing yosemite with clover faking the id of the video card to recognize that as a hd3000
http://www.tonymacx86.com/yosemite-desktop-guides/144426-how-install-os-x-yosemite-using-clover.html
I'm waiting for him too, but I am really upset for this new system, and I want to use it. I just wanted to know that everybody have the same problem that me...
I'm waiting for him too, but I am really upset for this new system, and I want to use it. I just wanted to know that everybody have the same problem that me...
yes, everybody had the same issues, try the link that I've posted above
I'm not that stupid, I have 3 partitions on my mac: snow Leopard - Lion - Yosemite, but if I don't know how to patch kext adding partitions can't let me do that
Not sure about what you want to do at this point. Whatever you do in the internal HDD can be done with an USB disk. Well, maybe recovery partition apart before Yosemite. If you know how to install a kext in a OS X partition in the internal HDD to do it in a partition in the USB disk is the same exact procedure. Just install Yosemite in a USB partition and boot from there. Then you can modify the kexts in /S/L/E without any worries about the one in the internal disk.
To make Messages/FaceTime working type this in terminal (one line per time if you copy&paste, because you must input the root password):
Code:
sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM=%61%d6%76%11%29%f2
sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB=CK148614DB6F940D2Then reboot.
Actually there might be an issue in the future because those key codes are over used (they come from an hackintosh web site). The best thing would be to be able to use the codes from the (supported) Mac of a friend. Not sure how to get them, though. Oh, and the same codes do not work in Mavericks.
Download "No Sleep" from the Mac Apple Store. It's the only workaround. The sleep/wake/brightness should be managed by the frame buffer kext. I see that if I modify the brightness in Lion Yosemite reports that number of bars (so it does read the value in NVRAM). But the brightness level is always at max. My only hope is that it has something to do with the boot.efi not communicating correctly, that could be fixed. Otherwise with the vanilla OS and these kexts I am afraid there is no solution.
Regarding the little glitch in the Messages window corner.. I dunno. It is there. But Messages works just fine (after you set the NVRAM). It isn't something to lose the sleep over.
https://pikeralpha.wordpress.com/2014/09/10/experimental-bin-patch-for-hd4600-mobile-gt2/comment-page-1/ something like this
----------
For iMessage/FaceTime I had no issues with mountain lion, didn't tryed with yosemite, maybe is because I've activated FaceTime with lion?
----------
For iMessage/FaceTime I had no issues with mountain lion, didn't tryed with yosemite, maybe is because I've activated FaceTime with lion?
https://pikeralpha.wordpress.com/2014/09/10/experimental-bin-patch-for-hd4600-mobile-gt2/comment-page-1/ something like this
Oh, I see it now. Basically they are doing what I suggested originally referring to the post of that user who tried with the HD3000 kexts (and forget about Clover. that's for people with hackintoshes):
1. Patch the Info.plist of the HD5000 kext adding the device-id for the HD4600
2. Patch the binary code of the kext substituting one of its device-ids with the one of HD4600. Which is what I meant when that time I spoke about using an Hex editor. I was right in the concept, so.
3. Be sure that no other kext for the same device-id is present in /S/L/E
4. Execute "sudo kextcache -Boot -U /" which should be equivalent to the dear, old "sudo touch /System/Library/Extensions" (and unneeded if one adds or remove a kext in that directory).
In our case just modifying the Info.plist file of the HD3000 kext the kext was loaded (I tested it myself), but then there is (obviously?) a check in the ASM code to verify that the device-id used is supported.
To do the same for the GMA 950 one must obviously use the hex codes for the device-ids of the HD3000 and GMA 950. The ones in the pike's forum would just either do nothing or break things even more.
Mah.. I may give it a try. Although I doubt it will ever work. The HD3000 and GMA GPU are supposed to be very different. As well as the fact that the kext was loaded makes me think that there is something else in the HD3000 kext. Or maybe no check at all, and in that case I tested already as not working.
With Mountain Lion (64 bits) or with MLPf? Also try with Yosemite and let us know, please.
Last edited:
With Mountain Lion (64 bits) or with MLPf? Also try with Yosemite and let us know, please.
MLPF, later I will try with Yosemite
just tried, neither FaceTime nor iMessage working here but html5 videos plays fine
edit: noticed that kernel task occupies almost 500MB, sounds weird
So what you guys are trying to do is make OS X recognize GMA as an HD3000? That's to enable QE/CI right?
Oh alright. Well I hope you guys can make it work. I would try it myself, but unfortunately, my knowledge in this area of expertise is limited. Plus, I don't have Yosemite on my Macbook 4,1 anymore(Issue came up. Had to erase HDD). I'm just waiting on Wayne's MacPostFactor to reinstall Yosemite.
Nah.. As I suspected. In the disassembled code there isn't even the check for the device-ids. Or if there is I sure can't find it, unlike in the HD5000. The Info.plist file should be all it needs to load (and keep in memory) the HD3000 kext. Then it does nothing, because the architectures are obviously totally different. Different families, registers, different everything.
We could have a chance if the X3100 kexts were supported. Looking at the Linux source codes the X3100 is just an extension of the GMA 950 (well.. not that this is really anything new). But since they aren't supported..
Instead I tried to compare the disassembled kext of the GMA 950 frame buffer with the Linux source code, to check about the backlight problem (the assembler procedures for it are very small, few lines). As much as I could, obviously, I am not Steve Wozniak.
The offsets seem to match. I don't get why it doesn't write the value, thus not setting the brightness. Unless the GPU isn't initialized properly, but that part is much more complicated. Or else, since it seems to be managed by the loginwindow process (it's the one reporting error in the console while trying to set the brightness with F1/F2) the API is simply missing (as in it changed name after SL) and so the routine doesn't get called.
I wonder if there is a way to write the brightness value straight in the GPU register, just for testing..
I patched mach_kernel, the one from DP of ML with the same timestamp compile, to allow 32bit extensions loaded for Mavericks 10.9.x.
32bit X3100 kexts are loaded at boot, so no more 6MB VM. GPU is identified as X3100 144MB.
However, I do not have time to play with OpenGL.framework which initializes unix core graphics animation.
64bit extensions for X3100 will never work on anything besides 10.6.2~ 10.6.8, so stop talking about them.
Mavericks and Yosemite could have QE/CI only when their mach_kernel allows hybrid loading of extensions x86_x64 and patched OpenGL.framework.
32bit X3100 kexts are loaded at boot, so no more 6MB VM. GPU is identified as X3100 144MB.
However, I do not have time to play with OpenGL.framework which initializes unix core graphics animation.
64bit extensions for X3100 will never work on anything besides 10.6.2~ 10.6.8, so stop talking about them.
Mavericks and Yosemite could have QE/CI only when their mach_kernel allows hybrid loading of extensions x86_x64 and patched OpenGL.framework.
Last edited:
Not sure I understood. Do you mean that you boot Mavericks with the 32bits ML DP1 kernel?
If you were referring to me I used the X3100 only as an example. I worded it wrong. With "not supported" I meant not working. But at least the Frame Buffer partially works with the 64 bits kernels, that's how people get the GPU identified as GMA X3100 with 144MB of video RAM. It's that the Backlight in both GMA FB kexts is screwed up.
Anyway, not sure if it is something new (it says available in OS X v10.0 and later) but Apple is publishing the APIs for the IOFramebuffer:
https://developer.apple.com/library...nce/index.html#//apple_ref/doc/uid/TP40011779
The IOAccelerator isn't there, though. I double checked few of them from the disassembled code (and cross verified them with the supported ones for HD GPUs), they match.
So now at least for the frame buffer it would be "just" a matter of porting the Linux GMA drivers
http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915
to OS X: Any volunteer?
PS: Just a weird note. I tried to recompile with "as" the disassembled kexts - one can get a disassembly with the command
Code:
otool -qXVt <Mach-O executable file>Xcode must be installed, I presume.
The i386 assembler code compiles (although it is unusable. The disassembly I get has hardwired jumps to fixed memory addresses instead of labels. Then I'm sure something else is missing, like the data section). Recompiling the 64 bits kext I get this:
Code:
admin$ as IntelIFBkext.asm
IntelIFBkext.asm:4228:32-bit absolute addressing is not supported for x86-64
IntelIFBkext.asm:4228:cannot do signed 4 byte relocation
IntelIFBkext.asm:7277:32-bit absolute addressing is not supported for x86-64
IntelIFBkext.asm:7277:cannot do signed 4 byte relocationWhere the two incriminated lines are:
Code:
movl $0x0, __ZN31AppleIntelIntegratedFramebuffer8doActionEPS_jPvS1_S1_(%rax) ## AppleIntelIntegratedFramebuffer::doAction(AppleIntelIntegratedFramebuffer*, unsigned int, void*, void*, void*)
addq $__ZN31AppleIntelIntegratedFramebuffer8doActionEPS_jPvS1_S1_, %rax ## AppleIntelIntegratedFramebuffer::doAction(AppleIntelIntegratedFramebuffer*, unsigned int, void*, void*, void*)At a first glance it looks like the 64 bits kexts are trying to call a 32 bits API (there is no doAction API in the IOFramebuffer class reference I posted above anyway). One wonders how that ended up there. Unless, seen that the FB kexts aren't fully working, the compiler messed up. I dunno, just guessing.
Not sure I understood. Do you mean that you boot Mavericks with the 32bits ML DP1 kernel?
If you were referring to me I used the X3100 only as an example. I worded it wrong. With "not supported" I meant not working. But at least the Frame Buffer partially works with the 64 bits kernels, that's how people get the GPU identified as GMA X3100 with 144MB of video RAM. It's that the Backlight in both GMA FB kexts is screwed up.
Anyway, not sure if it is something new (it says available in OS X v10.0 and later) but Apple is publishing the APIs for the IOFramebuffer:
https://developer.apple.com/library...nce/index.html#//apple_ref/doc/uid/TP40011779
The IOAccelerator isn't there, though. I double checked few of them from the disassembled code (and cross verified them with the supported ones for HD GPUs), they match.
So now at least for the frame buffer it would be "just" a matter of porting the Linux GMA drivers
http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915
to OS X: Any volunteer?
PS: Just a weird note. I tried to recompile with "as" the disassembled kexts - one can get a disassembly with the command
Code:otool -qXVt <Mach-O executable file>
Xcode must be installed, I presume.
The i386 assembler code compiles (although it is unusable. The disassembly I get has hardwired jumps to fixed memory addresses instead of labels. Then I'm sure something else is missing, like the data section). Recompiling the 64 bits kext I get this:
Code:admin$ as IntelIFBkext.asm IntelIFBkext.asm:4228:32-bit absolute addressing is not supported for x86-64 IntelIFBkext.asm:4228:cannot do signed 4 byte relocation IntelIFBkext.asm:7277:32-bit absolute addressing is not supported for x86-64 IntelIFBkext.asm:7277:cannot do signed 4 byte relocation
Where the two incriminated lines are:
Code:movl $0x0, __ZN31AppleIntelIntegratedFramebuffer8doActionEPS_jPvS1_S1_(%rax) ## AppleIntelIntegratedFramebuffer::doAction(AppleIntelIntegratedFramebuffer*, unsigned int, void*, void*, void*) addq $__ZN31AppleIntelIntegratedFramebuffer8doActionEPS_jPvS1_S1_, %rax ## AppleIntelIntegratedFramebuffer::doAction(AppleIntelIntegratedFramebuffer*, unsigned int, void*, void*, void*)
At a first glance it looks like the 64 bits kexts are trying to call a 32 bits API (there is no doAction API in the IOFramebuffer class reference I posted above anyway). One wonders how that ended up there. Unless, seen that the FB kexts aren't fully working, the compiler messed up. I dunno, just guessing.
I think you are in the right way to do something very awesome, go ahead with your research
maybe we get some 64bit working kexts
I think you are in the right way to do something very awesome, go ahead with your research
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...