833 replies to this topic

[neogeo]

Trying to digest this thread as best I can. I am just starting out with a build based on this board. Will there be a step by step guide on setting this up with revoboot? Would love to get this working but kinda lost at the moment...

[buoo]

Excuse me flAked

Do the values those we add in CPU/STATIC_DATA.C complete the job that the SSDT does to get the speedstep working? I mean.... if I don't add these values does the speedstep work in the same way ?
Looking around I could see that several users have a no complete working (9 different p-states, like you).
Probably they use Chameleon which doesn't allow to insert these values.

[flAked]

mrmojorisin17, on Jun 7 2011, 08:53 PM, said:

Can you make a test with onboard sound active?
Do you know where I can find AppleHDA source code?
Are you kidding me? After all the work that you and DHP had made it was the least I could do!

Sound is active at the moment, but I get assertions anyways, because I didn't patch AppleHDA, which is closed source btw. Otherwise we wouldn't need to bin-patch it.

Oh, well. I'm still grateful if people are doing experiments on their own, I constantly get angry at the "everything gets fixed for you" attitude.

neogeo, on Jun 7 2011, 09:40 PM, said:

Will there be a step by step guide on setting this up with revoboot? Would love to get this working but kinda lost at the moment...

I'll include a quick rundown of the important RevoBoot settings, yes.

buoo, on Jun 7 2011, 09:57 PM, said:

Do the values those we add in CPU/STATIC_DATA.C complete the job that the SSDT does to get the speedstep working?

You can use either the static or dynamic CPU detection in RevoBoot, it's just a speedup to the boot process.

The last time I checked the Chimera code there were still bugs for SandyBridge (wrong busspeed for example). RevoBoot was extended/developed to set up things correctly for SB.

And no, the CPU data is just for basic setup, the SSDT_PR includes the necessary P-State information.

[mrmojorisin17]

flAked, on Jun 7 2011, 10:22 PM, said:

Sound is active at the moment, but I get assertions anyways, because I didn't patch AppleHDA, which is closed source btw. Otherwise we wouldn't need to bin-patch it.

Ok, thanks. I'll make some other test when someone'll reply @ my post to ProjectOSX.

Quote

Oh, well. I'm still grateful if people are doing experiments on their own, I constantly get angry at the "everything gets fixed for you" attitude.

I like to make test because is a method to learn something new.
Naturally for things that don't require development knowledges

[flAked]

mrmojorisin17, on Jun 7 2011, 10:30 PM, said:

Ok, thanks. I'll make some other test when someone'll reply @ my post to ProjectOSX.

If you haven't seen it already, here is a in-depth tutorial: http://www.projectos...p?showtopic=465

[mrmojorisin17]

Yep, I've seen it
I think that the sound assertion that comes out in kernel.log depends on something on AppleHDADriver.cpp, so I asked you if you know where to get AppleHDA source code.
Or maybe it depends to something else in NVClockX code... I don't know

For sure sound assertion depends to NVClockX (I don't think it depends to IntelCPUMonitor) because the errors in kernel.log appears after upgrading this PlugIn!

But from what in particular?

[buoo]

Hei flaked could you verify the validity of this ssdt_pr for 2600k ?

Thanks

Attached Files

•  ssdt_new3.zip   1.51K   54 downloads

[flAked]

buoo, on Jun 8 2011, 02:59 PM, said:

Hei flaked could you verify the validity of this ssdt_pr for 2600k ?

Looks good. Have you changed anything? This looks like the standard SSDT_PR for 2600K.

mrmojorisin17, on Jun 7 2011, 11:16 PM, said:

For sure sound assertion depends to NVClockX (I don't think it depends to IntelCPUMonitor) because the errors in kernel.log appears after upgrading this PlugIn!

They have changed a lot in the NVClockX code, but I don't have the time to look into it.

I suggest posting this issue @projectosx in the FakeSMC thread.

[mrmojorisin17]

flAked, on Jun 8 2011, 03:44 PM, said:

They have changed a lot in the NVClockX code, but I don't have the time to look into it.

I suggest posting this issue @projectosx in the FakeSMC thread.

I posted and explained my issue yesterday but for the moment I get no-response.
I take a look at NVClockX code but I didn't find anything related to a possible sound assertion, surely because I don't know where I have to look exactly.

Any news regarding chipset? Is there a possibility to get correct info showed in System Profiler without plist injection in FakeSMC?

[flAked]

mrmojorisin17, on Jun 8 2011, 03:52 PM, said:

Any news regarding chipset? Is there a possibility to get correct info showed in System Profiler without plist injection in FakeSMC?

Either by using DSM (which is slow), making a dummy kext (so you haven't have to worry about FakeSMC updates) or the EFI injecting discussed here

EFI injection is favored, but as discussed in the thread I wasn't able to manually generate the injection data for my GFX.

[mrmojorisin17]

Sorry, maybe I explained in a bad way.
I know that instead of injection plist I can use a method _DSM in DSDT or a dummy kext
I just want to know if there is a method to get chipset perfectly recognized in a Vanilla way, only with AppleAHCPort that contains the id of our chipset.

flAked, on Jun 8 2011, 04:17 PM, said:

EFI injection is favored, but as discussed in the thread I wasn't able to manually generate the injection data for my GFX.

What are you using at the moment to get VGA working? Graphics Enabler? Or something else?
You can try to get your current VGA injection with Lizard and compare the plist-out with the one that you've created.

[flAked]

mrmojorisin17, on Jun 8 2011, 04:29 PM, said:

I just want to know if there is a method to get chipset perfectly recognized in a Vanilla way, only with AppleAHCPort that contains the id of our chipset.

Does it work if you delete Item1 in the AppleAHCIPort plist?

Looking at the iMac12,2 ACPI tables 1C,2 is actually the firewire device. That must mean that the SATA device is at 1C,3 and getting matched on that address. If we look at the device definitions there is actually no RP04 device defined, which would have the 1C,3 address.

In our DSDT we do have this:

Device (RP03) // Renamed from: PEX2
{
 Alias (AR13, _PRT) //changed from AR12
 Alias (PW94, _PRW)
 Name (_ADR, 0x001C0002)
}

So the device gets matched twice. Let's try and remove that.

That didn't change anything. Now let's remove Item1. That didn't change anything, either.

We have the identical plist definition and still no match. That can only mean that the kext probe() function is checking for more (IRQs?) where the dummy kext is just matching without probing.

[flAked]

mrmojorisin17, on Jun 8 2011, 04:29 PM, said:

What are you using at the moment to get VGA working? Graphics Enabler? Or something else?
You can try to get your current VGA injection with Lizard and compare the plist-out with the one that you've created.

Oh wow, that is very cool. It's actually doing what I was trying to figure out, getting the current injection, sweet
I'm currently using static injection data that I got from booting Chameleon with GraphicEnabler and the efi2struct tool.

[mrmojorisin17]

With Lizard I got my VGA injection (Graphics Enabler in com.apple.Boot.plist) that, after conversion in little endian format, is working great here in EFI/data.h.

[Regi Yassin]

can i ask my question here?

why my bdmesg showed me this,

ACPI CPUs not found: C-States not generated !!!
ACPI CPUs not found: P-States not generated !!!

how can i fix this?

[mrmojorisin17]

flAked, on Jun 8 2011, 05:00 PM, said:

Does it work if you delete Item1 in the AppleAHCIPort plist?

Nope. System Profiler always shows me Unknown AHCI Standard Controller.

Quote

Looking at the iMac12,2 ACPI tables 1C,2 is actually the firewire device. That must mean that the SATA device is at 1C,3 and getting matched on that address. If we look at the device definitions there is actually no RP04 device defined, which would have the 1C,3 address.

In our DSDT we do have this:

Device (RP03) // Renamed from: PEX2
 {
  Alias (AR13, _PRT) //changed from AR12
  Alias (PW94, _PRW)
  Name (_ADR, 0x001C0002)
 }

So the device gets matched twice. Let's try and remove that.

In my DSDT I have this:

			Device (RP03)
			{
				Alias (AR12, _PRT)
				Alias (PW94, _PRW)
				Name (_ADR, 0x001C0002)
			}

So have you changed AR13 with AR12?

Quote

We have the identical plist definition and still no match. That can only mean that the kext probe() function is checking for more (IRQs?) where the dummy kext is just matching without probing.

Any idea to solve this issue?

[buoo]

regae, on Jun 8 2011, 06:11 PM, said:

can i ask my question here?

why my bdmesg showed me this,

ACPI CPUs not found: C-States not generated !!!
ACPI CPUs not found: P-States not generated !!!

how can i fix this?

"not found" Did you name correctly the SSDT ?

[Regi Yassin]

buoo, on Jun 9 2011, 01:31 AM, said:

"not found" Did you name correctly the SSDT ?

Read HFS+ file: [hd(0,2)/Extra/DSDT.aml] 34179 bytes.
Table /Extra/DSDT.aml read and stored at: e5f000
Read HFS+ file: [hd(0,2)/Extra/SSDT.aml] 1304 bytes.
Table /Extra/SSDT.aml read and stored at: e68000
Read HFS+ file: [hd(0,2)/Extra/SSDT-1.aml] 1046 bytes.
Table /Extra/SSDT-1.aml read and stored at: e69000

its loaded, right?

[flAked]

buoo, on Jun 8 2011, 08:31 PM, said:

"not found" Did you name correctly the SSDT ?

You need the processor definitions in the PR scope of your DSDT. The factory tables don't include them.
You don't want any generated P/C-States by Chameleon, it is all done in the DSDT/SSDT.

mrmojorisin17, on Jun 8 2011, 08:15 PM, said:

So have you changed AR13 with AR12?
Any idea to solve this issue?

Yes I have updated all the AR definitions for the P8P67, anyone modifying DHP's DSDT to match their board must do the same, on top of additional differences.

I don't have an idea right now, but it's pretty low priority because it is only cosmetic and can be fixed by various means. I think DHP mentioned something about missing IRQs. Would be a lot of work figuring out why it doesn't match and emulating IRQs of a different hardware system is not something I'm keen to do.

[buoo]

flAked, on Jun 8 2011, 06:40 PM, said:

You need the processor definitions in the PR scope of your DSDT. The factory tables don't include them.
You don't want any generated P/C-States by Chameleon, it is all done in the DSDT/SSDT.

So in the DSDT there must to be

Scope (_PR)
{
	   Processor (CPU0, 0x01, 0x00000410, 0x06) {}
	   Processor (CPU1, 0x02, 0x00000410, 0x06) {}
	   Processor (CPU2, 0x03, 0x00000410, 0x06) {}
	   Processor (CPU3, 0x04, 0x00000410, 0x06) {}
	   Processor (CPU4, 0x05, 0x00000410, 0x06) {}
	   Processor (CPU5, 0x06, 0x00000410, 0x06) {}
	   Processor (CPU6, 0x07, 0x00000410, 0x06) {}
	   Processor (CPU7, 0x08, 0x00000410, 0x06) {}
   }

I got it. Right?


@edit: regae says that using the SSDT that I've posted before and adding this in DSDT he gets a kernel panic.