Contribute
Register

MSI GS70 Development Thread

Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
Completed


Processor (with speed-stepping)
  • Use MacBookPro11,2 SMBIOS
  • 8, 17, 24 | 25, 26, 28, 29, 30, 31, 32
Graphics
  • HD4600 works great with 10.9 frame buffer. Should work with 10.9.1. Anything over 10.9.2, you'll need to roll back.
  • GTX 765M works with external displays when using appropriate DSDT.
Sleep
  • Working through  Menu, energy saver timeout and lid sleep.
  • Lid sleep/wake has also been fixed with a quick GPE addition. Use darkwake=10.
Backlight
  • Backlight control has also been fixed and thanks to Rehabman's ACPI Backlight, has incredibly smooth control.
USB
  • EHCI/XHC seems to work fine. They've both been patched for wake capability. Ports multiplexing isn't an issue like it was with last generation's PCHs. Haven't tested for XHC speeds as I don't own any 3.0 devices, though I don't imagine they'll be a problem.
SATA
  • SATA works fine. Both MSATAs and the mechanical drive bays are detected fine.
Ethernet
  • Ethernet works thanks to Gamester3333's modifications here.
Audio
  • Working with toleda's AppleHDA. I've only changed the config data and path maps
Card Reader
  • Comes up as card bus. Meh.
Trackpad
  • Works
Keyboard
  • Works
Battery
  • Power is the only thing done right, really. They were helpful enough to use byte registers for battery information so ACPIBattery.kext is plug 'n' play.
  • 3 hours general browsing + continuous YouTube, 3-4 light applications running with GPU disabled.




Doing this over again, better this time. I got Mac OS going barely enough to get me through the semester and now I have some time to re-do things.


​Power Management and MSR: 0xE2

If you want to fix power management using the BIOS method, use CodeRush's tool. http://www.insanelymac.com/forum/topic/285444-uefipatch-uefi-patching-utility/page-76#entry2031914

You will need to flash the patched BIOS using "afuwinx64 bios-pmpatched /gan".

If you DON'T want to patch your BIOS, set up Clover appropriately (With pm kext patching).



Clover Configuration

Basic install is pretty straightforward. Clone base system and packages onto a usb drive as you normally would and install clover as usual. System configuration directory for this machine will be "/EFI/EFI/CLOVER/OEM/GS70 2OD/".

The only thing you need to make sure you have is Intel graphics injection with an ig-platform-id of "0x0a260005". I used the MacBookPro11,2 SMBIOS. This will give you proper speed-step and AGPM later. You may also need dart=0 as Vt-d can't be disabled from BIOS.


In the Clover kexts folder, you'll only need the bare essentials.



  • FakeSMC
  • PS2
  • ACPI Battery Manager
  • ACPI Backlight

Don't add the ACPI tables yet.



If you get stuck unable to boot after installation, go in with safe mode, go through setup and then reboot normally.

Both integrated and discrete graphics are recognised and loaded. GTX 765M works only through the DisplayPorts and presumably HDMI, though I haven't tested. Both DisplayPorts output fine and drive 2560x1600 without issues. The ACPI tables have been fixed for disabling the GTX should you want to. There are two DSDTs; DSDT.aml, which has the GTX disabled and DSDTnvidia.aml, which does not. To switch between the two, simply redirect the file accordingly in the Clover 'DSDT Fix Mask' menu.

If you have have problems with the camera, Fn-F6 just like Windows. The power to it is controlled by the EC. I suppose it could be permanently enabled by writing to the appropriate register in EC._REG but I can't
real be bothered. I rarely use the camera on my current MacBook Pro as it is.


ACPI Configuration

Before adding the ACPI tables, DUMP YOUR OWN. That means all of it. Then, download origin.zip below (these are my untouched unfixed tables) and do a diff against them. Region addresses are highly susceptible to change, even through BIOS option and of course system memory changes. If you do not do this step, there's a good chance things will not work.

Once you have found the differences, download finalDSL.zip. Open up my DSDT.dsl and DSDR(PEGP_Disabled).dsl. These two are identical except the latter has a few lines to disable the GPU. Update the region addresses as needed and compile. Save DSDT.dsl as DSDTnvidia.aml and DSDT(PEGP_disabled).dsl as DSDT.aml.

This next step is very important. You will do a diff for the SSDTs as well but only for SSDT-10/11. These two have been modified slightly in order to correctly disable the GPU. Copy over your own SSDT-1/8/9 amls untouched. Once you have updated the addresses for SSDT-10/11, compile them and save them as .aml files.

Lastly, head over to pikeralpha's github and grab SSDTPRGen. Generate yourself a CPU SSDT and save it to Clover.

Before restarting, rename all the SSDTs in Clover such that you have:
SSDT
SSDT-1
SSDT-2
...
SSDT-n

The order doesn't matter, just make sure the first one is SSDT not SSDT-0. Don't forget to drop OEM SSDT.
 

Attachments

  • origin.zip
    375.2 KB · Views: 360
  • DSL.zip
    423.1 KB · Views: 422
  • AppleHDA.kext.zip
    899.8 KB · Views: 367
Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
I've been away for the past few days but I spent tonight commenting some of this code. Most of it's just general stuff and quick notes on what registers are doing what.

I've also commented out a lot of junk code. Things like DOCK, NFCx, SCM0 (and the accompanying WMI1 in SSDT-9), Bluetooth kill switch BTKL. There are a few others like unused battery devices and an extra LID device that just returns 0. But these have a bit of dependent code that I'll need to run through before eliminating.

I've made some small optimisations to the EC.BAT1 status and info methods. I've also taken out all the junk debug stuff and replaced it with the more useful RMDT. I've scrapped all the OS branching. The OS is now identified as Windows XP.

I haven't really done any fixing. I had a quick jab at fixing the aforementioned brightness control issue. Didn't get very far before my head started drooping in fatigue. I figured I'd post this before heading to sleep.

There is also a peculiar problem with lid sleep/wake. The system sleeps fine when the clamshell's closed, but only wakes when the power button is pressed. I did some quick tests by throwing _PRW methods into (one or both) the LID0 device(s) and EC but the machine will then wake up after a few seconds into sleep. Probably has something to do with the rats nest they've got going with the LIDS register. For some reason, LIDS (lid state) is NOT in the GNVS field, but is defined (as LIDS) in the EC registers AND as a named object in the H_EC (Host-EC Interface). No wonder the bloody thing's confused.

Anyway. There are also a few comments here and there in SSDT-9 which is mainly for GFX0. The PEG related stuff is mainly in SSDT-11, which I'm yet to look at.
 

Attachments

  • commented.zip
    462.4 KB · Views: 188
Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
Some interesting developments. I fixed and compiled the SSDTs with iasl. I also fixed the lid wake issue by adding a _PRW package to LID0 and an accompanying GPE.

Code:
Device (LID0){
    Name (_HID, EisaId ("PNP0C0D"))  // _HID: Hardware ID
    Method (_LID, 0, NotSerialized)  // _LID: Lid Status
    {
        If (MYEC)    // If EC enabled
        {
            Store (LIDS, Local0)
        }
        Else
        {
            Store (One, Local0)    // Assume LID is open
        }


        Return (Local0)
    }
                
    Name (_PRW, Package (0x02)    // Added for wake resource
    {
        0x1B,
        0x03
    })
}
            
Scope (\_GPE)
{
    Method (_L1B, 0, NotSerialized)    // Wake notifier for LID0
    {
        Notify (\_SB.PCI0.LPCB.EC.LID0, 0x02)
    }
}

The machine now wakes from sleep when the lid is opened, but display still doesn't resume until further input from keyboard/trackpad or power button. Still... a step in the right direction.

Well that was stupid. Forgot darkwake.

The more interesting problem now is, every time the power brick is (un)plugged, the brightness goes down a bit. And not just in a background sense, the 'sun' hud comes up as if a keyboard event is being triggered. Bizarre... I've thrown in debug outputs into _Q and _L methods to see what's being triggered on power supply events.


  • _Q81 and Q82 are, but they're processor specific.
  • _L1E is but that's more of a general event with nothing seemingly relevant
  • _Q83 is also triggered. Now there's a BRLV object in here I can't identify. I tried commenting both instances out but it doesn't seem to change anything. Nor is it actually used anywhere from what I can see.

PNOT is also being called but again, I don't think it's relevant. I think it stands for ProcessorNOTifier or something along those lines.

I also went ahead and threw in EHCI/XHC injection so they would stop polluting wake reason.
 
Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
I've removed the obsolete PIC routing stuff and have also removed the UUID checks in the two _OSC methods. The IPIC device is is also gone since Mac OS won't use it anyway. I also got rid of a redundant branch in HPET._CRS.

Still don't know what's causing the mishaps with the adapter, so if anyone's seen this before, it would be very helpful.

Also there seem to be three timer devices implemented. RTC, TIMR and CWDT. The first two are pretty common but I'm not sure what the third one's doing. My best guess is it's a watchdog timer. It doesn't get initialised so for the time being I've commented it out.

I did a little digging in regards to the backlight issue.

Screen Shot 2014-07-12 at 4.06.56 pm.pngScreen Shot 2014-07-12 at 4.06.56 pm.png

After sleep, an additional key appears for "DevicePowerState". I'm not sure if this is relevant but it seems too perfect to be a coincidence. Unfortunately I don't know if there's a way to force this value.
 

Attachments

  • lidwake+cleanup.zip
    457.8 KB · Views: 158

RehabMan

Moderator
Joined
May 3, 2012
Messages
188,867
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
...
I did a little digging in regards to the backlight issue.
...

Haswell Brightness Fix:
DSDT Patches from here: https://github.com/RehabMan/Laptop-DSDT-Patch

Apply:
"Rename GFX0 to IGPU"
"Brightness Fix (Haswell)"
- rename patch must be done first and to all DSDT/SSDT that contain references to GFX0 that you're including in your final SSDT set
- Brightness patch must be done to the DSDT or SSDT that contains the definition for Device GFX0 (search for 'Device (GFX0)'
- Place DSDT and SSDT (if necessary) into a place where the bootloader will load them. For Clover, EFI/CLOVER/ACPI/patched (DSDT.aml, SSDT-x.aml where 'x' is a number). For Chameleon, /Extra/ssdt.aml, /Exra/ssdt-1.aml, /Extra/ssdt-2.aml, etc.

Install: https://github.com/RehabMan/OS-X-ACPI-Backlight
 
Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
Thanks for that. I did end up solving it with, like you said, the Haswell version of the patch. Looks like I need to update my library. The weird hud problem when AC power is toggled has also been resolved. I think there is some OSYS dependent code in the SSDTs (containing GFX0 and PEG) which causes it, so for now I've left that optimisation out.

But that's where the fun stops. When I decompiled the SSDTs, fixed the errors and loaded them up, things really started getting weird. The power supply state takes about 20 second to update with the SSDTs in place. And it doesn't stop there. It takes the backlight updating with it too (dim backlight when on battery), though everything else functions at regular speed. There's probably just some really crappy algorithm that it needs to process that's slowing everything down. I'll have to look into it tomorrow.

For now though I'll attach the pruned .dsl. On top of the previous optimisations, I've also taken out the PIC routing tables. Other than that, all seems fine.
 

Attachments

  • DSDT.dsl.zip
    35.9 KB · Views: 153

RehabMan

Moderator
Joined
May 3, 2012
Messages
188,867
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
...
The power supply state takes about 20 second to update with the SSDTs in place. And it doesn't stop there. It takes the backlight updating with it too (dim backlight when on battery), though everything else functions at regular speed. There's probably just some really crappy algorithm that it needs to process that's slowing everything down. I'll have to look into it tomorrow.
...

Most likely it is PNOT problem. Since you're likely dropping the OEM SSDTs for CPU, PNOT will be referring to objects that don't exist and causing failures/aborts to all ACPI code that calls it. One solution is to replace all the code in PNOT with nothing. It is crude and like a giant sledge hammer, but...

Either that or you don't have a correct AC adapter device and kext... See: http://www.tonymacx86.com/mavericks-laptop-support/116102-how-patch-dsdt-working-battery-status.html. My ACPIBatteryManager.kext includes an AC adapter device that provides the correct notifications (provided working _PSR).
 
Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
I think you're on the money for that one. I DO drop the 'x' appended SSDTs in favour of SSDTPrGen. Is PNOT even required? From the name I'm guessing it notifies the OS of P/C-state changes. With the generated tables, does that procedure become redundant? I'm all for cutting this thing down. I'll have a play with it tomorrow. Now, I can barely keep my eyes open.
 

RehabMan

Moderator
Joined
May 3, 2012
Messages
188,867
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
I think you're on the money for that one. I DO drop the 'x' appended SSDTs in favour of SSDTPrGen. Is PNOT even required? From the name I'm guessing it notifies the OS of P/C-state changes. With the generated tables, does that procedure become redundant? I'm all for cutting this thing down. I'll have a play with it tomorrow. Now, I can barely keep my eyes open.

Like I said eliminating it is crude, but does the job. The notifications seem to not be required. And check that you're using my ACPIBatteryManager.kext since if you're not, you won't get the needed AC adapter notifications into the system.

I have a patch for the PNOT in my laptop DSDT patch repo.
 
Joined
Jul 18, 2011
Messages
299
Motherboard
Z77X-UP5 TH
CPU
3570K
Graphics
R9 270X
Mac
  1. MacBook Pro
Classic Mac
  1. 512K
  2. LC
  3. PowerBook
  4. SE
Mobile Phone
  1. Android
Like I said eliminating it is crude, but does the job. The notifications seem to not be required. I have a patch for the PNOT in my laptop DSDT patch repo.

I'll have to check out your repo. I really liked your Haswell PNLF patch. Never would have thought to use RWeverything. I'll have to have a play around with it as it seems insanely powerful. Being able to load up the fixed SSDTs is a must since 95% of the graphics code is contained in there. And I'm not a huge fan of the idea of going through the whole thing bit by bit.

And check that you're using my ACPIBatteryManager.kext.

Yessir I am, thank you kindly for that as well.

On the topic of graphics, what's PCIe hotplug like under Mac OS? Can the _ON_ / _OFF methods be called within the same session, or is it one or the other?

Edit:

Either that or you don't have a correct AC adapter device and kext... See: How to patch DSDT for working battery status. My ACPIBatteryManager.kext includes an AC adapter device that provides the correct notifications (provided working _PSR).

My increasingly tired brain must have missed this. Battery is working fine. They were kind enough to make the registers byte length.
 
Top