Is there a tool to analyse the extensions hierarchy and versions?

[tempolo]

After many attempts with several different (and badly documented) installers, I have various working, non-working and partially-working Extensions sets and OS X systems assembled for running on a new Netbook system.

I still have trouble figuring out which modifications are responsible for certain working/nonworking parts of the system.

Problem is that sometimes not only the Extensions inside /Extra/ differ, but apparently also those inside /System/Library/. Now I have to figure out which extensions are really _effective in all these combinations.

Thus, a program would be helpful that looks into both (or more) places, reads all kexts, looks at their versions and other properties and creates a list that I can use to compare the various sets I have.

Does something like that exist already?

If not, I may have to write one. Any suggestions or feature requests? I suppose it just needs to read the plist of each kext in designated folders, read the version and bundle values, and list them?

[Gringo Vermelho]

kextstat can do some of those things.

type man kextstat in the terminal to learn more.

A quick way to see extensions versions through the finder is via the System Profiler. Click 'Extensions' on the left pane. It'll show all loaded kexts, modification date and version number.

As for dependencies (the most annoying issue when using /Extra/Extensions!) you can see those at the bottom of info.plist inside each kext.

There's a work-in-progress "Kernel Extension Encyclopaedia" type thing posted over at the ProjectOSX forums. You can look up each kext and see what functions it's responsible for.

I solved the problem you are having by only using /System/Library/Extensions for a while (and reading a lot) on a test system, until I discovered which vanilla extensions I couldn't use. When I was satisfied with the results I moved my modifications to /Extra and /Extra/Extensions and installed the full 10.5.6 combo update on top of my existing installation (it was iPC 10.5.6, running on the hardware in my signature except with a P4 CPU). Then I rebooted...and it still worked.

It's kind of living dangerously but you can safely do it this way if you have two OSX installs on the same drive. Then you can quickly boot into the other one if your experimental install implodes and fix things from there.

Today I've got a Core 2 Duo CPU and can run 10.5.7 retail, only modifications i need are

Patched BIOS (or DSDT.aml) with removed CPU aliases
smbios.plist spoofing a 2009 iMac9,1 + FSB and Clock Frequencies for my RAM and CPU
Patched AppleHDA or VoodooHDA to fix sound
NVEnabler.kext - even TV-Out works with this, it's amazing
LegacyAppleYukon2.kext to enable Marvell 88E8056 LAN
DSDT.aml with Marvell 88E8056 inserted in the device tree to fix UUID error 35 and Time Machine (thanks Krazubu)
AppleDecrypt.kext (required on all hackintoshes)
ICH10 Orange Icons fix included with Chameleon 2.0 RC1
Look mom, no disabler.kext!

The rest is pure vanilla 10.5.7.

[tempolo]

Thanks for your extensive answer. Especially the list of needed kexts with explanations is very helpful. I wish everyone writing a "guide" would do that.

I know kextstat etc., but they all do not the Extra folder. I used kextstat a lot to figure out that replacing some kexts in Extra did not have the desired effect.

Since then I learned to always create an mkext, and that makes it work with the Extra changes. Not sure why. Will have to look into the booter code someday about this.

So far, I did not need any dsdt patching on my netbook (Asus 1008HA). But I created one from scratch just make the boot much faster.

The only non-standard extension (for vanilla 10.5.7) I really need is AppleDecrypt. I also added 2 PS2 and a AppleAPCIBatteryManager, but they do not appear to be essential. I'm still experimenting.
Still no sound, however (that can wait).

Where can I find information on what AppleDecrypt does? Is it something originating from Apple? Who has the copyright on it, can I legally redistribute it publically (I'm having a hackintosh information page on my home page at tempel.org and want to guide others without getting into trouble with Apple)?

Finally, when you tried patching the SMBIOS values, e.g. using smbios.plist, did you try to change more than the product name? I tried changing "SMmanufacter" and similar texts, but instead System Profiler keeps showing only "Mac" as the Model Name. Is that normal?

[zef]

Where can I find information on what AppleDecrypt does? Is it something originating from Apple? Who has the copyright on it, can I legally redistribute it publically (I'm having a hackintosh information page on my home page at tempel.org and want to guide others without getting into trouble with Apple)?

It does the same binary decryption job what "Don't Steal Mac OS X.kext" does on real Macs. The main difference is while "Don't Steal" reads the required key from the SMC controller found only on real Macs, AppleDecrypt (dsmos, etc) already contains this key along with the commpage poem.

So it's better to not distribute it (same goes for dsmos, r2d2, r3d3). Read more about Apple's binary protection here:
http://osxbook.com/book/bonus/chapter7/binaryprotection/
http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/

[Blackosx]

Look mom, no disabler.kext!

Hi Beerkexd

By reading your replies to questions, I understand that are very knowledgeable and I'm interested in your build. I am working towards reducing my kexts in /Extra and currently I have to use disabler.kext to block AppleUpstreamUserClient and IntelCPUPM. Can I remove the need for disabler.kext by using DSDT instead? If so, can you give a couple of pointers for me?

[Gringo Vermelho]

My DSDT.aml was generated by koalala's ACPIpatcher (find it on InsanelyMac) with the Marvell LAN carefully inserted by hand following directions posted by Krazubu - which fixes the infamous UUID Error 35 and takes care of Time Machine as well (en0/internal fix). 

I discovered it by chance when I forgot to put disabler.kext on a Chameleon boot CD I made, and it could still boot the retail DVD. I don't know why it works but it works. I guess it has something to do the HPET patch in DSDT.aml. Plus a good bit of luck.
I'm also getting reasonable CPU temps, below 40 degrees celsius idle, a little higher than in Windows but nowhere near the high temps I've seen others talk about when using AppleIntelCPUPowerManagement.kext.

I don't think it's doing any speed stepping though, look:

sysctl -a | grep freq

kern.exec: unknown type returned
hw.busfrequency = 1332000000
hw.cpufrequency = 3160000000
hw.tbfrequency = 1000000000
hw.tbfrequency: 1000000000
hw.cpufrequency_max: 3160000000
hw.cpufrequency_min: 3160000000
hw.cpufrequency: 3160000000
hw.busfrequency_max: 1332000000
hw.busfrequency_min: 1332000000
hw.busfrequency: 1332000000

Maybe something can be done about that too.

Blocking AppleUpstreamUserClient.kext is not needed for me anymore after installing 10.5.7 and the iTunes/Quicktime updates that followed. I'm not getting the mouse jumping anymore.

[Blackosx]

I will do some experimenting with my system and try running without AppleUpstreamUserClient.kext and then also  AppleIntelCPUPowerManagement.kext. It might work, definitely worth a try.

As for koalala's ACPIpatcher, it looks a big thread so I will have a read and see what I can make of it.

Thanks Beerkexd

[Gringo Vermelho]

You're welcome. Please report back and let us know what you come up with.

Yeah that's a big ass thread. I tried to read all of it once, somewhere past the middle of the thread you'll find a summary that I made of some of the general points..then I gave up. Also look up fassl's original DSDT Patcher release thread over there, it's a gold mine as well.

Finally, when you tried patching the SMBIOS values, e.g. using smbios.plist, did you try to change more than the product name? I tried changing "SMmanufacter" and similar texts, but instead System Profiler keeps showing only "Mac" as the Model Name. Is that normal?

All I can think of is either there are some strings missing from your plist or you have another SMBIOS injector still present in your extensions folder causing a conflict. Make sure you have vanilla AppleSMBIOS.kext and no other kext with SMBIOS in its name in the extensions folder.

I had to use OSX86Tools to reset the 'about this mac' info and log out and in a few times before it showed up correctly there too. You can also do it manually, by editing SPPlatformreporter something or other. System Profiler showed the right information from the get go.

Here's my current smbios.plist spoofing a 2009 model iMac 9,1 with all the stuff I could find up until now.

Code: [Select]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>SMbiosvendor</key>
<string>Apple Inc.</string>
<key>SMbiosversion</key>
<string>IM91.88Z.008D.B08.0904271717</string>
<key>SMmanufacter</key>
<string>Apple Inc.</string>
<key>SMproductname</key>
<string>iMac9,1</string>
<key>SMsystemversion</key>
<string>1.0</string>
<key>SMserial</key>
<string>XXXXXXXXXXX</string>
<key>SMfamily</key>
<string>Mac</string>
<key>SMboardmanufacter</key>
<string>Apple Inc.</string>
<key>SMboardproduct</key>
<string>Mac-F2218FA9</string>
<key>SMexternalclock</key>
<string>333</string>
<key>SMmaximalclock</key>
<string>3160</string>
<key>SMmemtype</key>
<string>19</string>
<key>SMmemspeed</key>
<string>1066</string>
<key>SMmemmanufacter_1</key>
<string>Kingston Technology</string>
<key>SMmemmanufacter_3</key>
<string>Kingston Technology</string>
<key>SMmempart_1</key>
<string>KHX8500D2/1GN</string>
<key>SMmempart_3</key>
<string>KHX8500D2/1GN</string>
<key>SMmemserial_1</key>
<string>XXXXXXXX</string>
<key>SMmemserial_3</key>
<string>XXXXXXXX</string>
</dict>
</plist>
Of course values like the motherboard ID, boot ROM version and the mac model go together, so if you'd rather have an iMac7,1 you also have to change the other values, and not just the model ID. I found and verified these from various sources using google and I believe they are accurate.

The geekbench results site is a good place to start to grab some of the basic info, but be careful - many of the results posted there are clearly from hackintoshes with incorrect or incomplete smbios settings (Mac Pro with iMac boot ROM for example).
Authentic serial numbers, complete boot ROM strings and other stuff can be found on Apple and other Mac support forums. There are also threads on InsanelyMac, ProjectOSX and other OSx86 forums that have collections of some of the more hard to get info. Good hunting.

[tempolo]

Of course values like the motherboard ID, boot ROM version and the mac model go together, so if you'd rather have an iMac7,1 you also have to change the other values, and not just the model ID. I found and verified these from various sources using google and I believe they are accurate.

I don't get it. In which way to the values in the plist are related? Can't I just freely choose what I put into SMmanufacter, SMproductname, and so on? Where are the rules that I have to obey?

[Gringo Vermelho]

From my point of view, if your goal is to have your PC appear as an iMac7,1 you should enter the same values that you would find in the SMBIOS of an iMac7,1.

I don't remember if it's the same for all models but for example on a MacPro the SMbiosvendor is "Apple Computer, Inc" and on an iMac it's "Apple Inc".
 
The motherboard model string will of course differ as well depending on Mac Model, as well as the boot rom string and serial.

The SMFamily string is also different - on iMacs it's always 'mac', on Mac Pros and MacBooks it's something else (I don't remember right now).

I don't know how much it matters that all the values are totally accurate.

My primary concern is during installation - if I were to install with an smbios.plist spoofing a desktop mac on a laptop PC, would I still get the laptop power management stuff? I don't have a laptop to experiment with.

For example, I've discovered that I only get the "Allow Powerbutton to sleep the computer" option in energy saver settings when spoofing an iMac9,1, but not an iMac8 or 7,1.

And you can only run the PCI-Express configuration utility if you're spoofing a Mac that has PCI-E slots. Of course you can't do anything with that on a Hackintosh but still.

So there's definitely more stuff going on than just System Profiler cosmetics.

[tempolo]

For example, I've discovered that I only get the "Allow Powerbutton to sleep the computer" option in energy saver settings when spoofing an iMac9,1, but not an iMac8 or 7,1.

And you can only run the PCI-Express configuration utility if you're spoofing a Mac that has PCI-E slots. Of course you can't do anything with that on a Hackintosh but still.

I had no idea. OK, that should be noted. All the tools and infos about SMbios  values I found so far didn't mention this.

I'll see that I add this info to my own site eventually.