Mojo

Great job on revision 253. It displays everything about the memory modules including Manuf during boot process after the boot0 easier to see now. Displaying the serial number is also a great feature because my modules have no obvious serial number written on them.

This post has been edited by osxfr33k: Jul 26 2010, 12:01 AM

Not only PLimitDict. You need also to exclude CStateDict and add RestartAction.
My sample.

Great work!
Revision 262 generates CStates on an overclocked GA-EX58 with GenerateCStates=yes and a DSDT with standard PR scope.
Memory is shown as 1333MHz, not the actual running speed as Asere's did, but it's not a deal breaker for me.

Thanks again Slice. That modification allowed P-States with the Model Identifier MacBook3,1.

Not sure if it is OK to continue this in this thread as my questions are no longer directly related to RC5...

I have been struggling with C-States. I have tried a number of different possibilities but still have this error:

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

It is NOT proceeded by any _CST evaluation errors.

I'm left wondering if C-States are possible on this system. Dell 1525, T5450, 2GB Mem, 1280x800 LCD... I have read most threads (some with the help of Google translate) here and a few on other forums.

So, I have spent some hours comparing the OEM SSDT tables extracted using Linux (and while running MAC OS, of course the same) and real MacBook3,1 and MacBook4,1 tables and reading the ACPI spec document (which makes my eyes hurt after a while). Thinking that the Chameleon RC5 generated tables are incomplete for this system I then tried a few different SSDT tables.

First one based on your commented out tables from your dsdt (changed for my p state specifics and the locations of the hidden tables.  JohnSSDTr2.zip ( 1.92K ) Number of downloads: 7


and a generic  GenericSSDT.zip ( 1015bytes ) Number of downloads: 23


What I have not tried is real MacBook3,1 Tables (Modified for my CPU of course). One, I have only been able to find MacBook4,1 SSDT Tables and, two, I don't know how I would find out the address the tables (were loaded to so I could change the hardwired values like these:




I'm have been using a slightly modified version of your dsdt for this testing.  dsdtslice3.dsl.zip ( 21.52K ) Number of downloads: 13


In E/E I have: LegacyHDA, LegacyBluetooth (to enable bluetooth on-off), VoodooBattery, VoodooPS2 and VoodooSDHC
In /S/L/E I have FakeSMC (2.7.2) and the 10.6.2 version of AppleHDA.

Here is a dump of my ioreg:  HackMacBook3_1.zip ( 80.74K ) Number of downloads: 13


I have done a few table dumps while trying different things and this caught my eye (not sure if it is relevant, but I don't know) in the FACP table.




The _CST Support is always 0 . Not sure if it is part of the cause or a symptom.

At this point I have exhausted what I can try given my skill and experience. If this is not possible, then I will waste no more time. If it is, I would be grateful for any help that you might offer.

This post has been edited by freeburma: Jul 31 2010, 11:36 PM

Hey, can someone here break it down with what I need to do to enable the native AppleIntelCPUPowerManagement. I'm unfamiliar with LPC, HPET, PStates, and CStates. I'm not afraid of the DSDT if I need to do anything there.

I doubt it, but if it has anything to do with it, I've got an Acer Aspire One ZG5 running 10.6.4 w/ legacy_kernel.

With the Chameleon from this thread, I don't need to null the APM anymore, but it still isn't enabled, and I'm very unclear of where to start to get it working.

Also, if I were to get this enabled, would I be able to natively hibernate? This Chameleon fixed my sleep, but only with SleepEnabler for 10.6.4 and only when using a disk image(hibernatemode=0). When I try to keep the ram active (hibernatemode=1,3), immediate KP.

Mojo quick question,

The Official Sources are at Assembla correct? I am a bit confused because your source is also at forge.voodooproject.org and it seems that the revision level have a much lower number and not sure how they correlate to your sources on Assembla?

Where do you suggest I grab the latest sources?

Thanks

osxfr33k,

the stuff at forge.voodooprojects is the most up to date, specially the trunk
Mojo been committing everything there.

Hello everybody,

I've try your work.
Very good work

With my first Hackintosh GA-EP45-DS3L + E1400@2Ghz
- temp IDLE from 50°C to 29°C, very good.

but with my second Hackintosh GA-P35-DS3P + E2180@2Ghz
- nothing better 50°C in idle.

Someone can help me for cleanup my DSDT because i've try myself and make KP.

Thank you for this version of chameleon.

Laurent

This post has been edited by Cyberdog!: Sep 8 2010, 10:18 AM

Hello,

and again i have to say, thats a great osx86 tool.
anway i have folowing suggestion:

would it be possible to merge this with netkas pcefi boot.
the reason is that pcefi has so great gfx recognition. I use a 9800gt, a 8600gts and a hd4670 just with vanilla kexts, no dsdt editing no efi strings. I sure use chameleon as bootloader, but as said with pcefi boot file.
with this release all my gfx are set into standard mode 1024x, so that I would have to add efi strings for the nvidia cards, and edit dsdt for the ati. with pcefi, all cards work native. so what about supporting most gfx?
the situation i as you have to choose between two great looking gils, but you would rather have them both
to get serious again. maybe its good to have different dev branches, as new ideas can be adopted faster, on the other hand i feel as in this case, already existing functionality get lost.

This post has been edited by dino42: Sep 14 2010, 06:36 AM

Hi Mojodojo,

congratulations for the great work on Chameleon.

I have a suggestion: what about a new version of your VoodooMonitor app that gets from ioreg the P-states generated by Chameleon, and gets status info from FakeSMC, instead of using its own kext?

Thanks for your great contribution to the scene.

Hi to all!
today I was fidling around with ssdt.

And this is mine test:

All major DSDT patches are added throught SSDT tables.
After making SSDT I have done BIOS update to see what will happen.
All went well and I got new DSDT, but I did not lost mine functions and modifications added over ssdt.

List of SSDT added:
SSDT.dsl - USB/EHCI
SSDT-1.dsl - HDEF/SMBUS
SSDT-2.dsl - Ethernet/Firewire/Airport
SSDT-3.dsl - C-states
SSDT-4.dsl - P-states

P-states are for Xeon X3440
Even I think that other devices can be added like TMR RTC and PIC for fixing IRQ confilicts.

 Custom_GD65_SSDT.zip ( 4.64K ) Number of downloads: 34

Hello jadran.. what mus i change for my Intel Prozesor i5-650 ?
I hva not to time a DSDT run. I hav load the new Chameleon RC5-518.
I will test with Speedstep with this prozesor and my MSI-P55-GD65
Motherboard.
DSDT is for me new, hav ever without this running my System 10.6.4 (64Bit).
Maby you hav Tipps for me, we i begin this DSTD Patch with combination
the Chameleon RC5-518 Version.

Greetings from Germany Pinarek

Wow! What I see? You override DSDT devices via SSDT! Need more investigation for this. Interesting trick.

Where is no longer VID values in P-States for newest Core ix cpus. I've stopped voodoomonitor development and I am afraid I'll not start it again

Only thing I did change in mine new DSDT is name of processors from P001 to CPU0 and so on... because mine ssdt with PStates are named CPU0. Even I think that is just cosmetics for IOReg.

One thing i tested your PstateGeneration on mine Xeon X3440 and it gives me instant reboot - used latest trunk from forge.voodoo

of course, your Xeon is core i7 i think (socket 1156) - where is no support for it for now. But you always could extract you P-States from native SSDTs of your motherboard (i didn't heard yet about 1156 mobo that can't generate beautiful P-States in SSDT).

But you're understand what does it mean, the feature you've discovered? DSDT is needless and we can patch it without difficult editing process. We could prepare generic patches for different mobos and devices and use it by a easier way: not so difficult like to patch DSDT itself.

This post has been edited by Mojodojo: Sep 21 2010, 04:20 PM

That was for chameleon test, speedstep works even without SSDT with Pstates on these boards.



Yes, I understand... I am not new in DSDT stuff... and the reason for finding it is because there was no AZAL/HDEF in mine MSI board, and in similar manner are added SSDT stuff in imac11,1

So, for Mac OS X SSDT has higher priority than DSDT for device declaration. Thats why SSDT device overriding works.

Yes, have a look at this ssdt from imac, and everything will clear for you.
 ssdt_override.zip ( 9.79K ) Number of downloads: 23


One thing, when U put DTGP method in ssdt it will be compiled and functional in OSX, but once U decompile that same SSDT, DTGP will be modified. Look at mine SSDT from previous post.

What would be the benefit to using a bunch SSDTs as opposed one DSDT? Organization? From a development standpoint I guess it would be easier to manage with several smaller SSDT patches rather than one large DSDT. Is this what you're suggesting?