Jump to content

Chameleon RC5 mode with mem detection enabled and automatic P-States & C-States generation for native power managment


kozlek
 Share

1,214 posts in this topic

Recommended Posts

Thanks for the suggestion Gringo Vermelho. Here is the com.apple.Boot.plist I'm currently using. I've already been using system-type=2 for a long while. I have the battery tab in energy saver, but my core i7 laptop is recognized as iMac11,1 core i7. I went back to using smbios.plist for now.

 

<dict>

<key>Kernel</key>

<string>mach_kernel</string>

<key>Kernel Flags</key>

<string>arch=i386</string>

<key>GraphicsEnabler</key>

<string>Yes</string>

<key>GenerateCStates</key>

<string>Yes</string>

<key>DropSSDT</key>

<string>Yes</string>

<key>Timeout</key>

<string>1</string>

<key>Hide Partition</key>

<string>hd(0,2) hd(0,3) hd(1,1)</string>

<key>EthernetBuiltIn</key>

<string>Yes</string>

<key>system-type</key>

<string>2</string>

</dict>

 

I still think it's at the code level that Chameleon has to be modified to accomodate the mobile core i5/i7 processors like on the MacbookPro6,1 and MacbookPro6,2.

Link to comment
Share on other sites

yeah... ProductVersion is not a user key, should be on another group at least. On my branch it's gone, so to say :P

Yes RestartFix it's a typo.

Link to comment
Share on other sites

Without the SMBios.plist, my DELL XPS 1530 is recognized as a MacBookPro4,1 which is a problem as my NVIDIA GeForce 8600M GT GPU performs VERY poorly with that model identifier (10:1), so I use a MacBookPro5,1 one instead. It also produces a brand new kernel warning message as follows:

 

kernel Debug WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for MacBookPro4,1 with 17 p-states, using default stepper instead

 

As I understand it, under the RC5 removing the smbios.plist causes Chameleon to misidentify my rig and lacking the GPU power states under that identifier, it apparently reverts it to the single lowest power state causing poor GPU performance.

 

Question to the devs: Is it possible to enable the RC5 to recognize my rig properly without the smbios.plist? If not, are there any other solutions to this issue?

 

Eternal gratitude for all your labors!

Link to comment
Share on other sites

Use trunk r517 and be happy that you have a P45/ICH10 based motherboard that works *perfectly* with Chameleon.

For us, it doesn't get any better than this I think, "official" or not.

Every single announced feature works flawlessly and on top of that we don't need to patch out the CPU aliases anymore, what else could you ask for, you're in Hackintosh Nirvana.

Link to comment
Share on other sites

The key is SystemType=x on Chameleon.

 

Azimutz, I agree with you system-type=2 is key and that's what I'm using, but chameleon still detects my mobile core i7 as a desktop core i7 and keeps giving me iMac11,1 core i7.

 

I believe I may have found the lines of code responsible for determining if it's a mobile CPU in cpu.c:

 

/* Mobile CPU ? */

if (rdmsr64(0x17) & (1<<28)) {

p->CPU.Features |= CPU_FEATURE_MOBILE;

}

 

Looks like this is the section that needs to be modified to account for mobile core i3/i5/i7 cpus maybe?

Link to comment
Share on other sites

I think you missed the point, the correct syntax is "SystemType". "system-type" will not work.

 

system-type=2 is from the AsereBNL bootloader and works just as well as SystemType=2. I get the battery tab in Energy Preferences in both cases.

 

Now, just to show you, i've removed smbios.plist and made sure to have SystemType=2 in com.Apple.Boot.plist

 

My mobile core i7 processor is detected as the desktop core i7 which wrongly gives me iMac11,1 core i7.

 

The section of code I mentioned in my previous post might be the key also.

 

post-104137-1285735809_thumb.pngpost-104137-1285735892_thumb.pngpost-104137-1285735929_thumb.png

Link to comment
Share on other sites

Make an smbios.plist with the MacBookPro6,2 model identifier:

http://www.everymac.com/systems/apple/macb...body-specs.html

http://browse.geekbench.ca/geekbench2/view/289782

dmi.bios.date: 07/26/10
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP61.88Z.0057.B0C.1007261552 <--- not a typo, it shares firmware updates with the MBP6,1!
dmi.board.name: Mac-F22586C8
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro6,2
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-F22586C8
dmi.product.name: MacBookPro6,2
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

(as found here: http://www.mail-archive.com/ubuntu-bugs@li...msg2483917.html )

SMC Version (system): 1.58f16 (for editing fakesmc.kext: http://prasys.info/2009/11/editing-fakesmc/ )

(as found here: http://discussions.apple.com/thread.jspa?t...=0&start=30 )

Link to comment
Share on other sites

Without the SMBios.plist, my DELL XPS 1530 is recognized as a MacBookPro4,1 which is a problem as my NVIDIA GeForce 8600M GT GPU performs VERY poorly with that model identifier (10:1), so I use a MacBookPro5,1 one instead. It also produces a brand new kernel warning message as follows:

 

kernel Debug WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for MacBookPro4,1 with 17 p-states, using default stepper instead

 

As I understand it, under the RC5 removing the smbios.plist causes Chameleon to misidentify my rig and lacking the GPU power states under that identifier, it apparently reverts it to the single lowest power state causing poor GPU performance.

 

Question to the devs: Is it possible to enable the RC5 to recognize my rig properly without the smbios.plist? If not, are there any other solutions to this issue?

 

Eternal gratitude for all your labors!

Link to comment
Share on other sites

How did you get your cpu-type 0x602 to be recognized?

 

My laptop core i7 keeps getting recognized as a desktop core i7, so I keep getting iMac11,1 core i3/i5/i7 instead of a MacbookPro.

 

Looks like the code for MacBookPro core i5/i7 processors still has not been included in smbios_patcher.c of Chameleon v2 RC5 as of revision 517.

I changed the Chameleon source code so that my HP notebook works. This however is a bad change. It will affect other hardware, in a bad way, and thus should not be used by other people. I think that the smbios.plist override is the way to go when it isn't recognized, simply because there are now i5's for both the iMac and MacBookPro's.

 

Please note that it might simply be my use of cpus=1 which may affect the check if (Platform.CPU.NoCores > 1) { in sm_get_defstr but I'm not a developer so I can't really tell. Anyone?

Link to comment
Share on other sites

As I understand it, under the RC5 removing the smbios.plist causes Chameleon to misidentify my rig

I don't believe that was ever part of Chameleon's job description.

You're expected to do your own matching by using smbios.plist - this is clearly stated in the first post in this thread:

To enable native power management you should use proper mac model (...)
Link to comment
Share on other sites

I don't believe that was ever part of Chameleon's job description.

yep... there was a time when we had to use kexts. Then the smbios patcher was added to the booter; it has some default settings but, if none of them matches what we need, rool up the sleeves and use smbios.plist. In a sense, that's in fact the main way to do it, since the smbios.plist values "always" override the defaults!

And the default values stored on the booter can be easily changed in this case (and others). Just change the values here; replace the ones Chameleon is setting by default with the ones you need.

 

Now, about the code...

Jingu, SystemType key works a bit diff on Chameleon, but yes, the end result is the same on Cham or Asere's booter; my intervention was based on the fact that we are on a Chameleon topic. This key only sets the property value on ioreg and it doesn't interact with smbios patcher or cpu detection (which interact together). Maybe it should/could?!

That CPU_FEATURE_MOBILE bit you pointed, it's the only place were that variable is being set;

it's not setting it for you or you would get sm_macbookpro_defaults (MacBookPro4,1) which isn't also what you need.

So, for now the best choice is, do it your self :(

Link to comment
Share on other sites

yep... there was a time when we had to use kexts. Then the smbios patcher was added to the booter; it has some default settings but, if none of them matches what we need, rool up the sleeves and use smbios.plist. In a sense, that's in fact the main way to do it, since the smbios..plist values "always" override the defaults!

And the default values stored on the booter can be easily changed in this case (and others). Just change the values here; replace the ones Chameleon is setting by default with the ones you need.

 

Done and done, no more smbios.plist! Thank You for the tip....

Link to comment
Share on other sites

Doesn't work memory speed detection, shows 1066 instead 1333 (or 1328 as shows the post screen, and AsereBLN 1.1.9 as well).

I don't know how to do the bug report, as I am not chameleon coder.

As I said, I didn't know if AsereBLN posted or not the mem detection, but the page that I refer is different than chameleon web page. So maybe is there, maybe not...

Sorry if I am bothering someone, maybe my english is not very good and there is a misunderstanding.

 

Cheers.

 

If someone want to see the comparisson of AsereBLN and C2RC5 in images.

http://www.insanelymac.com/forum/index.php...t&p=1556261

 

Cheers.

Link to comment
Share on other sites

That CPU_FEATURE_MOBILE bit you pointed, it's the only place were that variable is being set;

it's not setting it for you or you would get sm_macbookpro_defaults (MacBookPro4,1) which isn't also what you need.

So, for now the best choice is, do it your self :)

 

Azimutz, thanks for the pointers. I took your advice and fixed myself the Chameleon SMBIOS injection so that my mobile core i7 is recognized as mobile core i7 MacbookPro6,2.

 

in smbios_patcher.c, right underneath the MacbooPro section, I added a section for the Core i5/i7 MacBookpro

 

// defaults for a MacBook Pro core i5/i7
static const SMStrEntryPair const sm_macbookpro_core_defaults[]={
{"SMbiosvendor",	"Apple Inc."			},
{"SMbiosversion",	"MBP61.88Z.0057.B09.1004161215"	},
{"SMbiosdate",		"04/16/2010"			},
{"SMmanufacter",	"Apple Inc."			},
{"SMproductname",	"MacBookPro6,2"			},
{"SMsystemversion",	"1.0"				},
{"SMserial",		"SOMESERIAL"			},
{"SMfamily",		"MacBookPro"			},
{"SMboardmanufacter",	"Apple Inc."			},
{"SMboardproduct",	"Mac-F22586C8"			},
{ "",""	}

 

Then I went i cpu.c, I had to fix the core i7 mobile detection. Right underneath

		/* Mobile CPU ? */
	if (rdmsr64(0x17) & (1<<28)) {
		p->CPU.Features |= CPU_FEATURE_MOBILE;
	}

 

I added

     		if ((p->CPU.Family == 0x06 && p->CPU.Model == 0x1e)) {
		p->CPU.Features |= CPU_FEATURE_MOBILE;
	}

So that my particular processor model and family is detected as mobile.

 

Then I went back in smbios_patcher.c and changed:

 

                if (platformCPUFeature(CPU_FEATURE_MOBILE)) {
	if (Platform.CPU.NoCores > 1) {
		sm_defaults=sm_macbookpro_defaults;
	} else {
		sm_defaults=sm_macbook_defaults;
	}

 

to:

        	if (platformCPUFeature(CPU_FEATURE_MOBILE)) {
	if (Platform.CPU.NoCores > 1) {
		sm_defaults=sm_macbookpro_core_defaults;
	} else {
		sm_defaults=sm_macbook_defaults;
	}

 

Now Chameleon SMBIOS injection is correctly giving me mobile core i7 MacBookPro6,2 on trunk revision 517

Link to comment
Share on other sites

hello i decided to remove smbios.plist and memory detects well, even the timings at 4-4-12!

problem is that now i dont have any serial number in about this mac and i dont know if this is good in updates etc

what should i do to inject?

also macpro 3.1 is ok?

 

since last year i have a perfect SL and i dont want to risk reinstall

 

 

 

post-59183-1285890626_thumb.jpg

Link to comment
Share on other sites

 Share

×
×
  • Create New...