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

Introduction

Hello Everyone,

Given the recent dispersal of OSx86 developers and participants away from Insanelymac I have decided to create my own blog. Though I will likely focus on OSx86 projects, we'll see where things lead. I would love to get into reviewing products. I don't exactly know how one gets into such a position, but if you are a representative of such a company please feel free to contact me. I feel that many product reviews (though certainly not all, there are some sites I very much respect) are very limited in scope and come from a biased position. I'd like to see if I could offer a more helpful perspective.

Anyway, let's get to it...

theStevo