Hat Trick?

Hello Everyone,

My sincere apologies for my extended absence. Many significant things have happened in my work and personal life since my last post, and I've had little (if any) time to work on Hackintoshes in general. As proud and amazed as I am at the community's progress, I must admit that buying an Apple-made OS X machine was/is a sound and enjoyed investment.

But... everyone needs a hobby.

In the last couple days I have been able to carve out some time to investigate the latest and greatest for OS X on some of my favorite pieces of hardware. Among these is my trusty E520, and it's GMA X3000 integrated graphics. And, unfortunately, the outlook isn't that good.

My best summary/theory on the status of things is that hardware acceleration is enabling, but the framebuffer keeps crashing late in initialization. If I had a working framebuffer, I think I'd have a new version to release. But, without it there is nothing useful - at all. I had a suspicion that Apple's updates would cause this back when I was creating the Snow Leopard drivers. The framebuffer was getting more and more finicky to the point that by 10.6.5 I couldn't get the framebuffer working at all. But... none of them crashed, they just left me with a black screen and no evidence of joy via SSH.

So, theoretically it might be possible. Lion's X3100 framebuffers do seem to behave differently than Snow Leopard's. But, I wouldn't give it a 2% chance at this point - at least with what ideas I have left. However, as some helpful visitors mentioned in the comments of my last announcement post, I believe you should be able to get 10.6.8 working fine if you carry forward some of the bundles (assuming you had it working in 10.6.2, I'm not saying it will magically fix blue screens). That's about the best I can offer right now, sorry!

Also, if anyone is interested, here is my current DSDT for the E520. When I moved to Lion I took a look to see what DSDTs were available for this model and didn't find anything terribly impressive. I didn't search for a really long time, but I took a quick glance around. I'm sure that someone somewhere has a better one, and if so please share it with the community, but this is what I'm currently working with. Use at your own risk, I am not providing support for it. Additionally, I found that AHCIPortInjector, AppleIntelE1000e, the latest FakeSMC, and VoodooHDA were all I needed to get a well-running system (aside from graphics, of course).

So... Leopard X3000, Snow Leopard X3000, but no hat trick


yet.

For the Want of a Boot

Good news, the boot1 error for the E520/XPS410/Dimension 9200 has been solved! A little over a week ago a user called rivig successfully diagnosed and provided a solution for the problem on the VoodooLabs Forums. User rals2007 indicates that other computers may be affected by this problem as well.

If I'm understanding it correctly, the problem stems from an incorrectly coded BIOS that does not accept negative offsets. Without correct offsets, the bootloader cannot load the data that is located on the HFS+/FAT partition and is stuck with just the MBR stage. This was not a problem prior to Chameleon RCx because it did not need to load "external" data such as a GUI. However, rivig came up with a solution that should be universal. Zef acknowledged the patch and said that it will be incorporated into the next version of Chameleon, in all areas that pertain to linear address mapping (eg. CDBoot).

Fortunately, all that most of us need at the moment is a patched boot1h. Sgerber has provided a compiled version at the XPS410 thread on insanelymac. Since all release candidates of Chameleon, and all PC EFI V10.x, use the same boot1h, this patch should be applicable for all GUI-capable, Chameleon-based bootloaders. I can verify that it works, as the computer I'm posting this from is my E520 rebooted in AHCI without a USB drive. I'm just glad that it wasn't in disk.c or sys.c; makes me feel a little more competent!

Enjoy!
theStevo

News, Discoveries, and Comments

So, I get my Latitude D830 to a place I'm really happy with and this inspires me to dive into my E520's DSDT. Well, unfortunately, it is not nearly as happy a place as the D830's DSDT. The E520/XPS410's DSDT is a pathetic showing that really disappoints me. Anyway, running into that broke my momentum of looking into hack stuff and brought me back to things in the real world. However, there are some things I would like to share.

Intel 965 Drivers

Netkas announced some great news on October 8th! The 10.6.2 beta contains 64bit drivers for Intel's IGPs, which means the X3000 and X3500 should have 64bit support soon. Now, I have not seen the driver yet which means that I can't make any guarantees. The relationship with the framebuffer is finicky enough that it may cause problems. I got the 32bit framebuffer to work, but you can't mix and match. It will be all or nothing. I'm in no rush to make a 64bit version for a couple reasons. One, I hear that the beta drivers are rather buggy. Two, I use a discrete card for normal operation.

Another thing I want to mention on this topic came to me when I was reading recent comments to a previous post. I've said this on various forums, but not yet on my blog and it is a good thing to discuss. I am not aware of any way in which the X4500(M)(HD) chipset could even theoretically work with X3100 drivers. Yes, I'm aware that people have got the X3100 framebuffer to work... but that is entirely different. Early on, I looked into getting the X4500 to work with the X3100 and I worked with others on the IRC who were attempting the same thing. I'd like to see it working. However, it soon became apparent that the architectures are just too different. Just reading the wikipedia article about GMA will explain that. However, there is another logical argument why it won't work. Apple doesn't have a history of packing multiple architectures into the same kext like Intel (Windows) does with the same driver package. You have GMA915/950 kexts (essentially the same architecture), GMA965, but nothing about X4500 anywhere. If X4500 functionality was added to X3100 kexts it would be completely uncharacteristic of Apple. The only hope for X4500 drivers, which basically isn't even a chance in hell, is for the nVidia/Intel lawsuit to force Apple into switching back to GMA. But, even if that did happen Apple would want a new IGP instead of the X4500. They already showed that it is a gutless wonder, even Steve would have a hard time selling that switch.

STAC9227 Audio

Ok, I'll admit it, Viki's legacy kext for STAC9205 on the D830 spoiled me. I like the idea of full functionality using Apple's own drivers. However, I've had a devil of a time trying to get STAC9227 to work the same way. I started by reading THe KiNG's guide and then solidified my understanding of those principals by reading Master Chief's guide, basically saying the same thing differently. The catch is that neither of them really go into pathmaps or layouts. I'm pretty confident I figured it out and created a correct pathmap and layout, but it isn't working. The reason why I think I created a valid pathmap and layout is because if I use otherwise working ones in the same kext I get the same errors. My guess is that the problem has to do with codec support, and therefore hex editing. I have no problem with that, but it isn't very "legacy." MacGirl created some legacy kexts for the 9228, which isn't a native codec either, but I can't seem to get the same type of modifications to work for the 9227. The odd thing? STAC9205 isn't natively supported either, yet it works without hex editing. I don't know, if somebody smarter than I could explain that to me I'm probably a few minutes away from providing a nice legacy kext for the E520/XPS410 - and I wasn't able to find one currently available.

I was hoping to have the legacy kext ready for a move to Snow Leopard, but being I wasn't able to figure it out I looked into VoodooHDA instead. I've used it before, but I thought that the project was largely stagnate these days. Not true. The famed Slice has adopted the project and made many recent developments. I have no complaints at the moment, though I'm not viewing it as a permanent solution yet. Many people are posting much higher functionality with this newer version. Some may already have been aware of this, but since I didn't know I thought I'd pass it along.

Also, a later post will outline my instructions for creating pathmaps and layouts. It may not be perfect, but I'm confident my understanding is functional. Being that I wasn't able to find any comprehensive guide to that part of the AppleHDA patching process, think of it as an appendage to THe KiNG's or Master Chief's guides until they post their own.

E520 Update

Currently I've modded the DSDT to enable my graphics card, correct the USB issue, show all devices, enable custom P-States, load vanilla AppleLPC, and load vanilla AHCI/ATA. However, I haven't been able to get C-States working... story of my life lately. For those of you that have the boot1h error, that is a problem with Chameleon. I talked to Kabyl about it and he said that it is likely a change introduced by RC1 in disk.c or sys.c. I compared the code of RC1-3 to 1.0.11 and I haven't been able to figure out where it is. I've sold applications I've written before, but that doesn't make me a professional coder :) I guess I'm just missing the change, I don't know. Maybe one of you is smarter than I and can figure it out. In the mean time I'm using an old 32MB flash drive I had laying around to boot Chameleon, and therefore launch OS X with the AHCI enabled.

D830 Update

Well, I think I've only got two things left to implement on this baby - then it will be as perfect if Apple made it themselves :) One would be C-States (see below). And the other would be shutdown/restart/hibernate. I'm curious as to whether graphics power management could have something to do with that, being that it happens once hardware acceleration is enabled, but I'm not sure that Apple's graphics power management kext applies to the 8 series GPUs (which the 140M is). Anyway, the thing is rockin'! It's Geekbench scores are higher than those of MacBook Pro's of comparable hardware!

C-States and Sound

Well, darn. I thought I had a brilliant idea for C-States, but no dice. The concept was to take out all the if statements and leave only packages for C1E and C2, because they are always the same within the respective P_BLK. I figured, if every "if" statement contains these two blocks of code in the same form, then it must be ok to take the conditionals out and just feed it direct (like _PSS). How I was going to get the rest of the C-States was a different matter, but at least I would have had something working. However, as I already said, it didn't work. No new error messages, same old LPC can't initialize blah blah blah. So... I wait for another epiphany. I tried the MacPro3,1 CSTs too, no go.

I did change the way I'm doing sound, though. As I mentioned in my previous post, I was using Brandon2004's legacy kexts with vanilla AppleHDA. However, I tried 04152viki's legacy kext (inside "D630 SL.zip" on first post) and it is much better. It lists internal/external mic and internal/external output in the system profiler instead of just externals, internal mic works, and switching works perfectly for both input and output. Basically, its perfect. So perfect that it doesn't even throw sound assertion errors! I have no clue why anybody would want to use VoodooHDA for a Latitude D830 now, though its still a great solution for other machines that aren't so lucky. I'm not aware of an audio feature on this laptop that this legacy kext doesn't cover! Great work viki!

theStevo

My DSDT-Focused Sabbatical

Hi all,

It isn't the end of this blog yet, I've just been very busy the last couple weeks and have been working on DSDTs in the evenings. Primarily, the DSDT for my Dell Latitude D830. Up until recently I had barely looked inside a .dsl file and had little clue of what was going on. However, I've finally come to some understanding of it and would like to share what I've found. My goal here is to look back and relate, to the best of my ability, what would have got me up to speed the fastest. I do have prior programing experience and that definitely helps.

General DSDT Editing Tips

1. Always have a working backup of your DSDT in the root folder. Sounds basic, and it is basic. However, its very easy to get ahead of yourself and rush to test your latest change. This can be especially painful when you are working on AppleIntelCPUPowerManagement without a backup. Why? Because most people can't just delete the DSDT and boot without one because you'll get an HPET kernel panic. Additionally, if you try to work in single user (CLI) mode to delete the poewr management kext it will often load before you are done typing the needed commands, and therefore panicking before you can fix it. When I have compiled a new DSDT that I want to test I first rename the current DSDT to bDSDT.aml (the name doesn't matter) and then paste the new one in. That way if it doesn't work I can reboot with the flag DSDT=bDSDT.aml
2. Make one change at a time until you are sure multiple changes would have isolated effects. Again, this is basic and conservative debugging. If your computer doesn't load with your next DSDT, you need to know for sure what change caused that. 
3. Start by cleaning up your DSDT. Don't go adding features while you are still getting warnings, as this makes it harder to figure out what's wrong if it doesn't work.
4. Be sure to watch your brackets. It usually pays (for me anyway) to spend the time formatting code properly, it helps identify those problems quicker.
5. I'm using DSDTSE, with the latest iasl dropped in, to compile. 

Vanilla Speedstep: P-States

P-States are actually pretty simple to get working, if you know what you are doing. In hindsight, I was two 'steps' away from having it working perfectly on my first try. However, it took a while to figure out what those were. This is the InsanelyMac thread that first got my attention, and it is a good place to start. I will assume you read the first post and have come to an understanding of what we are doing here. With that as a foundation, I'll simplify the procedure further. To the best of my understanding there are only two needed components to having working P-States controlled by AppleIntelCPUPowerManagement:

1. Copy "Name (_PSS, ..." into the definition of your first processor under "Scope (_PR)". Then, add a reference under all other processors. Ex. "Method (_PSS, 0, NotSerialized){Return(^^CPU0.PSS)}" Some computers have various other P-State tables under other names (Eg. NPSS, XPSS), you'll have to do some detective work to figure out which one is most likely right for your processor. More on this in a minute.
2. If you look in System Profiler and your Model Identifier is NOT MacBook5.1, MacBook5.2, MacBookPro5.1, MacBookPro5.2, MacBookPro5.3, MacBookPro5.4, MacBookPro5.5, MacPro3.1, Macmini3.1, or iMac9.1, you need to open info.plist in /System/Library/Extensions/IOPlatformFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents add an entry under "PlimitDict" for whatever your Model Identifier is. All the entries under that key are the same, just replace the name in one with whatever you have. In the thread referenced above, people elude to editing the plist for this kext, but there are at least three areas vaguely mentioned to edit. I believe this is the only edit needed for working P-States. Eventually I will incorporate this into a legacy kext.

Now, I originally got Step 1, but I missed Step 2. With both steps done, I believe the majority of people will have P-States working to some extent. I had P-States working at this point but it wasn't quite the way it should be. I had noticed for a while that the lowest state it would go into had the wrong voltage, and it wasn't the lowest listed by CPU-i. The long and short of it is that the P-States I dumped were incorrect... in some major ways. For one, I have a T9300 which has a maximum multiplier of 12.5x yet the highest P-State in the table was for a multiplier of 13.5x. It took me longer to figure this out because I was under the impression that CPU-i was supposed to list all the P-States known to the system. However, it was instead listing all the P-States that VoodooPower came up with for my machine. So, to correct this I used the P State Calculator available on the first post of the InsanelyMac thread by Mojodojo. If you temporarily load VoodooPower, it will spit out your _PSS for you and you can just put it into the DSDT. One word of caution though, it has problems calculating the CoreFreq with half multipliers (eg. 12.5x). You can correct this information with that from CPU-i. For more info on P-States, take a look here and here.

Vanilla Speedstep: C-States

I don't have C-States working yet, but I believe I'll have C1E and C2 working very soon. I'm not sure about C3 and beyond, but I think I know what is holding me up currently. I'll devote another post to this.

Miscellaneous Edits

The other DSDT edits I made were fairly small and came relatively easy. DSDTSE provides the code for nVidia injection, I just modified it for my NVS140M with an NVCAP from NVKush. I did the standard HDEF mod and coupled it with Brandon2004's LegacyAppleHDA. I added a firewire entry (In IOReg, Whatever@1,1 would have an _ADR of 0x00010001. Track down your device and adapt other DSDT device entries appropriately). And finally, I got a hold of a MacbookPro4,1 ioreg and modified my device names to match Apple's.

Final Comments

I'll be posting some more on DSDT in the coming days, but I also wanted to make mention that cleaning up your DSDT (before any mods) takes care of the D830 issue of AppleHPET knocking off the USB2.0 ports (which includes bluetooth). That means that if you can have AppleHPET, you can have AppleIntelCPUPowerManagement (even if you don't have vanilla speedstep yet), and therefore you can have sleep and your USB ports without using workaround solutions. Second thing I wanted to mention is that all these fixes work seamlessly into Snow Leopard in both 64 and 32bit. Great benefit of getting away from modifying kexts and instead using vanilla. Lastly, looks like sleep is a lot more stable and I don't get the sleepimage errors on boot anymore (go figure). So, to the more advanced this post didn't hold much (except for maybe info regarding Dell T9300 peculiarities), but hopefully it will help people in the position I was a couple weeks ago. It really does get a lot easier, looking at a DSDT now is wholly different than it was.

Stevo

Snow Leopard ICH8-R

9/3/09 Edit: I found the answer, thanks to frantisheq on the XPS410 thread on Insanelymac. Quite simple, actually. Snow Leopard needs to be SATA0 to load AHCI properly. That means that SL didn't like me loading AHCI devices when running from a USB drive, and it didn't like frantisheq loading AHCI devices when running from SATA1. This really won't be a problem for many people, though it is annoying if you like to have two drives (one with a test installation). It would still be nice to have "fixed" but maybe that's not feasible. I'm happy enough just to be booting from the HD!

It appears that some, if not all, ICH8 boards in RAID (AHCI) mode have some preliminary issues with Snow Leopard. I own a Dell E520 and have been trying to track this issue down, this is what I've got so far:

• The problem lies with ATAPI and does not appear to affect hard drives. So, if you are installing from a USB drive, you can get Snow Leopard working in AHCI by disabling the CD/DVD drives. Obviously, this is not a permanent solution but merely a temporary one that provides an easier way of further testing.
• I suspect SCSITaskUserClient.kext (plugin of IOSCSIArchitectureModelFamily.kext) to be the culprit. Seems like the ATAPI drives initialize correctly, SCSITaskUserClient attaches to the last ATAPI drive, and then stalls when another process asks for information about ATAPI. That requesting process could be Finder, System Profiler, Disk Utility, etc. Up until that time, everything is "reported" as being correctly loaded by IOReg.
• Running in 32 bit and using Leopard kexts has not got me anywhere yet. Apparently a Leopard SCSITaskUserClient wants a Leopard IOAHCISerialATAPI, and that mouse wants a cookie. Reverting to Leopard isn't a real solution anyway.

I've been searching for solutions to this, and asked on the IRC, nobody seems to have an answer they would mention. Any thoughts?

theStevo

X3000 and X3500 for Snow Leopard

To christen my new blog, I'd like to present some new and improved kexts! These complete G965 "family" support for Snow Leopard, just as my previous release did for Leopard. With that designation, it might be a good time to cover the following...

There is a difference between GMA 3000/3100 GPUs and GMA X3000/X3100/X3500 GPUs. Those without the X are related to the GMA 950. We are not discussing those in this post! Most desktop boards, that I have seen, are without the X and are related to the GMA 950. Quite commonly retailers, or even manufactures, mislabel the products and add Xs. Usually the chipsets are correct, so please reference below.

Chipsets not in scope of this post: 946GZ, GL960, GM965, Q965, Q963, G31, G33, Q33 and Q35

Chipsets in scope of this post: G965, G35

I'm fairly pleased that in my previous two threads on Insanelymac only two people posted questions regarding inapplicable hardware, hopefully we can even better that track record here. A little time spent researching your hardware on Google will assure that nobody wastes time diagnosing a problem that can't be fixed.

Now that the hardware warning is covered, let's talk about these new kexts. They are for Snow Leopard only, as they will not work in Leopard because of OpenGL issues. They are 32 bit only, just like the vanilla version I modified to create them. I did not magically recompile or otherwise add 64 bit capability to a closed-source driver. But, they do have a few new improvements:

• Performance is improved. I'm not talking about Snow Leopard vs. Leopard, I'm talking about the way I made the previous kexts vs. how I made these. I started making a Snow Leopard version using the old method and was later able to improve upon it. I believe, to the best I can tell, that has led to approximately a 1/8th increase in performance. Additionally, preliminary cross-platform benchmarks showed Snow Leopard X3000 performing 2/3rds again as fast as Vista.
  
• Sleep issues resolved (for me, anyway). I wasn't able to get Leopard to sleep with the X3000, but that appears to now be fixed. I don't own a machine that has had the 'blue screen' issue on boot, but theoretically there could be a relation. I'm just hypothesizing. Perhaps it could fix/help that issue as well?
  
• System Profiler now displays the correct chipset.
• Maybe a little future protection. Looking at the GMA-related changes that took place after 10.5.4, I think I may have found where some of the problems came from in later kext revisions. However, only time will show if I'm right. I may very well not be.

Before I leave you to the download links, I'd like to make two disclaimers: One, I don't have a machine with an X3500. I cannot guarantee that it will work, I only made the appropriate changes for what should enable that chipset. If you have errors, I need all the relevant information and offer no promises. Two, I don't have a machine on which I've ever been able to replicate the 'blue screen' error. If you have errors, I need all the relevant information and offer no promises.

Download the X3000 kexts here
Download the X3500 kexts here

I recommend using cVaD's Kext Utility to install kexts in Snow Leopard if you don't feel comfortable doing it manually.

Good luck,
theStevo