Jump to content

DSDT fixes for Gigabyte boards

iSoprano

By iSoprano,
in Guides

 Share
1,908 posts in this topic

Recommended Posts

Master Chief
Master Chief
Posted
Posted
I just got mine working. I got so interested in why USB2.0 hubs wouldn't work that I went out to buy one :P Now I can wake up using both my aluminium keyboard and a mouse connected to powered USB2.0 hub.

The red part might be key here. GigaByte USB hubs are underpowered?

 

It's a DSDT patch, my ehci devices now look like this:

Store (0xC9C2,\_SB.PCI0.EHC1.PMSS)
...
Store (0xC9C2,\_SB.PCI0.EHC2.PMSS)

Here we go. Bits 6-8 are the onces I was referring to with being underpowered.

 

BTW: I would have used PWRC instead of PMCR since that's what it is.

 

Edit: You don't need register 0x80 when you re-write it a little: 

OperationRegion (PWRC, PCI_Config, 0x52, 0x02)
Field (PWRC, ByteAcc, NoLock, Preserve)
{
	, 6,
AUXC, 3,  // Auxiliary Current.
	, 7
}

And then call Store (0x07, AUXC).

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
The red part might be key here. GigaByte USB hubs are underpowered?

 

 

Now try that with the vanilla DSDT :P

 

No, the key is that for some reason Gigabyte writes 0x0002 to register 52h when booting up and that is why OS X thinks that Ehci has no power. When board goes to sleep for first time and wakes up then it gets that value 0xC9C2 which it should have had originally. Yet again a Gigabyte bios bug I guess, same thing happens on Windows but it just doesn't seem to care about that value.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
No, the key is that for some reason Gigabyte writes 0x0002 to register 52h when booting up and that is why OS X thinks that Ehci has no power. When board goes to sleep for first time and wakes up then it gets that value 0xC9C2 which it should have had originally. Yet again a Gigabyte bios bug I guess, same thing happens on Windows but it just doesn't seem to care about that value.

That's exactly what I said: They are underpowered. To me it doesn't matter what the cause is, since it doesn't work without a patch. They are underpowered without the patch. That's key here.

 

p.s. Now do a search and find what I said about USB power since that was why I was so busy with all these ioreg outputs :P the changed registers after sleep. Remember? Let me quote that:

 

Edit: Here's something to think about:

 

Blackosx's ICH10 (EHCI controller #1:

Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

 

And this is what I have with my ICH9:

Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)

 

And that on both EHCI controllers! Which would mean, if the data can be trusted, that you first have to do a sleep-wake cycle, and then wake from keyboard works, or that the lspci output can't be trusted.

But good to see it nailed! Finally. Great work!

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
That's exactly what I said: They are underpowered. To me it doesn't matter what the cause is, since it doesn't work without a patch. They are underpowered without the patch. That's key here.

 

p.s. Now do a search and find what I said about USB power since that was why I was so busy with all these ioreg outputs :P the changed registers after sleep. Remember? Let me quote that:

 

 

But good to see it nailed! Finally. Great work!

 

That is exactly what I noticed when comparing lspci outputs before and after sleep. It just doesn't help even if the power value gets corrected after first sleep.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
That is exactly what I noticed when comparing lspci outputs before and after sleep. It just doesn't help even if the power value gets corrected after first sleep.

I'm not sure I understand you; You still can't wake from alu Apple keyboard – before sleep – with this patch? Only from the externally powered hub (with the patch)?

 

p.s. I'm sure that we are missing some kind of init() foo at boot time.

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
I'm not sure I understand you; You still can't wake from the keyboard – before sleep – with this patch? Only from the externally powered hub (with the patch)?

 

p.s. I'm sure that we are missing some kind of init() foo at boot time.

 

No, with the patch everything works fine. But patch has to be done on bootup, it doesn't help to write that register later.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
No, with the patch everything works fine. But patch has to be done on bootup, it doesn't help to write that register later.

But of course – the USB drivers need to know about it at load time (driver state differ).

 

I would also like to advise you to use Method (_INI) under Scope (_SB) { right above Device (PCI0) – which runs unconditionally, before anythings else – to make sure that it works, even when (load / init) delays hit you.

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
BTW: I would have used PWRC instead of PMCR since that's what it is.

 

Edit: You don't need register 0x80 when you re-write it a little: 

OperationRegion (PWRC, PCI_Config, 0x52, 0x02)
Field (PWRC, ByteAcc, NoLock, Preserve)
{
	, 6,
AUXC, 3,  // Auxiliary Current.
	, 7
}

And then call Store (0x07, AUXC).

 

Did you mean PWCR?

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
Did you mean PWCR?

I checked the datasheet to find: "Power Management Capabilities Register" so PMCR would be the right one to use, for both the OperationRegion and Field, but I am going to group things up as I want less code. Here's part I: 

			Method (_INI, 0, NotSerialized)	// USB hub power initialization.
		{
			Store (0x07, ^EHC1.AUXC)	// \_SB.PCI0.UHCI.AUXC
			Store (0x07, ^EHC2.AUXC)	// \_SB.PCI0.EHCI.AUXC
		}

Put that in your Device (PCI0) because that's what mm67 meant to do by using ^_INI. And this is step one, resulting in 10 optimizations and 55 bytes less AML code. More to come...

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
I checked the datasheet to find: "Power Management Capabilities Register" so PMCR would be the right one to use, for both the OperationRegion and Field, but I am going to group things up as I want less code. Here's part I: 
			Method (_INI, 0, NotSerialized)	// USB hub power initialization.
		{
			Store (0x07, ^EHC1.AUXC)	// \_SB.PCI0.UHCI.AUXC
			Store (0x07, ^EHC2.AUXC)	// \_SB.PCI0.EHCI.AUXC
		}

Put that in your Device (PCI0) because that's what mm67 meant to do by using ^_INI. And this is step one, resulting in 10 optimizations and 55 bytes less AML code. More to come...

 

Ok, did some more testing and those bits 8:6 don't matter, it's the bits 15:11 that do the business, writing 0x19 there is the key to working Ehci

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
I can even connect a mouse to keyboards hub and use that for wake up.

 

/edit

If you try this on something else than ICH10 check that your ICH has the same register on EHCI as ICH10 does

 

52h–53h

PWR_CAP

Power Management Capabilities

 

 

I have a ICH10 (GA-EP45-UD3P). Thanks for the tip.

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
But isn't that controlled by bit 8 in register 0x54? Is that bit set on your board? What happens when you set it?

 

Nope, ICH10 datasheet has this note under description:

Normally, this register is read-only to report capabilities to the power management software. To report different power management capabilities, depending on the system in which the ICH10 is used, bits 15:11 and 8:6 in this register are writable when the WRT_RDONLY bit (D29:F7, D26:F7:80h, bit 0) is set. The value written to this register does not affect the hardware other than changing the value returned during a read.

 

So this register really isn't needed for anything, it's just that because Gigabyte writes a stupid value there OS X is fooled into thinking that EHCI device has no PME capabilities.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
Nope, ICH10 datasheet has this note under description:

Normally, this register is read-only to report capabilities to the power management software. To report different power management capabilities, depending on the system in which the ICH10 is used, bits 15:11 and 8:6 in this register are writable when the WRT_RDONLY bit (D29:F7, D26:F7:80h, bit 0) is set. The value written to this register does not affect the hardware other than changing the value returned during a read.

That's is exactly the same note I have for register 0x52, for my ICH9. And something is initializing this register. Or should I say should as it doesn't appear to work on GB boards :P

 

So this register really isn't needed for anything, it's just that because Gigabyte writes a stupid value there OS X is fooled into thinking that EHCI device has no PME capabilities.

You think? So tell me; Why did Apple include this snippet: 

				OperationRegion (U7CS, PCI_Config, 0x54, 0x02)
			Field (U7CS, WordAcc, NoLock, Preserve)
			{
					,   15, 
				PMES,   1
			}

Why did they, when they don't need it? Again: Is bit 8 set, and if not, what happens when you set it? I mean the note: "This bit (8 and 15) must be explicitly cleared by the operating system each time it is initially loaded." can't be there too for nothing! What if bit 8 and/or 15 are not cleared at boot time?

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
That's is exactly the same note I have for register 0x52, for my ICH9. And something is initializing this register. Or should I say should as it doesn't appear to work on GB boards :P

 

 

You think? So tell me; Why did Apple include this snippet: 

				OperationRegion (U7CS, PCI_Config, 0x54, 0x02)
			Field (U7CS, WordAcc, NoLock, Preserve)
			{
					,   15, 
				PMES,   1
			}

Why did they, when they don't need it? Again: Is bit 8 set, and if not, what happens when you set it? I mean the note: "This bit (8 and 15) must be explicitly cleared by the operating system each time it is initially loaded." can't be there too for nothing! What if bit 8 and/or 15 are not cleared at boot time?

 

Bit 8 of register 54 is set if I boot without my patch and I don't know why Apple added that register to their DSDT. What I do know is that my MSI board has no such stuff in DSDT and value of register 52 is always C9C2 so I assume that bios is putting that value there.

 

/edit

With my patch bit 8 of register 54 is not set. Without patch value is 0x0100 and with patch 0x0000

Link to comment
Share on other sites
keeza
keeza
Posted
Posted
Bit 8 of register 54 is set if I boot without my patch and I don't know why Apple added that register to their DSDT. What I do know is that my MSI board has no such stuff in DSDT and value of register 52 is always C9C2 so I assume that bios is putting that value there.

 

/edit

With my patch bit 8 of register 54 is not set. Without patch value is 0x0100 and with patch 0x0000

 

I'll try this patch when I get back from a short break to see if it'll work with my white apple keyboard connected to my hub on my cinema display.

 

Nice work mm67!!!

 

p.s. care to share your latest and greatest?

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
I'll try this patch when I get back from a short break to see if it'll work with my white apple keyboard connected to my hub on my cinema display.

 

Nice work mm67!!!

 

p.s. care to share your latest and greatest?

 

This is what I am using at the moment:

dsdt.dsl.zip

 

Was already under 900 lines without these EHCI mods :)

  • Like 1
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Great work with your fix mm67 and I enjoyed your open discussion with MasterChief about it as it gives an insight in to the whole development process. Thanks

 

This is what I am using at the moment:

 

Was already under 900 lines without these EHCI mods :(

And your DSDT is amazing, as for me, it throws a whole new angle on this subject. It's as if you have started with a blank DSDT and only added what you've needed?

 

Thanks for sharing.

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted
I'd love to know why I can't get speedstep working with these mods.

 

Here's mm67's dsdt patched up for my p35 board - speedstep NOT working!

It worked for me, so I have done what I did for mine, with your data. Have a look at the attached and see if that works for you? (You might need other bits for your setup, but this is using just what I know)..

SuggestionForFormerly_DSDT.dsl.zip

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
It worked for me, so I have done what I did for mine, with your data. Have a look at the attached and see if that works for you? (You might need other bits for your setup, but this is using just what I know)..

 

Do you now have method PTS setup like mine, if you do then could you try some shutdowns without OHR.kext.

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
I am testing with your DSDT with only my data in Scope (_PR). Here it is...

dsdt.dsl.zip

 

As for Shutdowns, I can report 5 out of 5 so far :(

 

That's good, I have now been using shutdown without OHR for almost two weeks, haven't seen it fail even once.

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
That's good, I have now been using shutdown without OHR for almost two weeks, haven't seen it fail even once.

I know this is a lot to ask but would you happen to have your original unedited DSDT for comparison?

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...