윈도우용 컴퓨터든 맥이든 ACPI 테이블이 있어서 각 장치에 필요한 정보를 불러올 수 있습니다. 다른 특성을 넣어주고 싶으면 ACPI 테이블을 수정합니다.
커맥은 윈도우용 컴퓨터를 기반으로 하기 때문에 맥에 호환이 잘 이루어지기 위해서 여러가지 패치를 합니다. IGPU, OS Fix, EC 등. 그런데 만약 하드웨어를 바꾼다면 ACPI 테이블 자체가 바뀌기 때문에 안정적으로 사용하기 위해서는 다시 한 번 ACPI를 패치해주어야 합니다.
하지만 매번 다시 패치하기는 정말 불편합니다. 비교적 스마트하게는, 본인에게 필요한 패치들을 하나의 텍스트 파일로 묶어서 하드웨어 변경할 때마다 클릭 세 번 정도로 끝낼 수 있겠지만, 만약 배터리라면 패치코드 생성하지 않았을 경우는 일일이 복붙해야 해서 상당히 피곤합니다. 그래서 사용하는 방법이 Clover(OC) on-the-fly 패치입니다. 부트로더가 자동적으로 ACPI 단계에서 ACPI 테이블을 수정해주고 수정된 ACPI로 컴퓨터를 작동시킵니다. 따라서 하드웨어 교체 시 매번 DSDT나 SSDT에 직접 패치를 가하는 static 패치보다 훨씬 부담이 적습니다. 비슷한 방식으로 WhateverGreen이 필수적으로 바꾸어야 하는 이름들을 바꾸어주거나 장치를 IOReg에서 단계에서 추가해주고 있습니다.
보통의 static 패치 가이드를 보시면 기본적인 Rename(GFX0, HDEF 등) 외에
1. "Fix _WAK Arg0 v2"
2. "HPET Fix"
3. "SMBUS Fix"
4. "IRQ Fix"
5. "RTC Fix"
6. "OS Check Fix"
7. "Fix Mutex with non-zero SyncLevel"
8. "Fix PNOT/PPNT" (use only if you're dropping CPU related SSDTs)
9. "Add IMEI" (do not use if your DSDT or SSDTs already have IMEI/HECI/MEI device)
10. "6-series USB"
11. "7-series/8-series USB"
12. _PRW patches
13. MCHC Fix
14. PluginType
가 있습니다. Fix_WAK의 경우 Yosemite 기준으로 필요 없게 되었고, USB는 10.12 기준으로 다른 종류의 패치를 사용합니다. 빨간색은 있어도 상관은 없습니다. HPET Fix, IRQ Fix, 그리고 RTC Fix는 Broadwell 포함 이전 세대 컴퓨터에만 해당합니다. Fix PNOT/PPNT는 3세대 CPU 이하인 경우 ssdtPRGen.sh으로 SSDT.aml을 생성했을 때 사용합니다. Add IMEI는 IMEI(MEI/HECI) 장치가 없는 경우에 새로 생성합니다. PluginType은 ssdtPRGen를 사용하지 않는 경우에 사용합니다. 즉 4세대 이후 CPU나 3세대 이하 CPU중 적당히 OEM SSDT를 손 본 경우입니다. 보라색은 해당하는 경우에만 적용합니다. 결국 남는 것은 파란색 패치들입니다. 또한 클로버 패치 말고 SSDT Injection이 비교적 쉽기 때문에 SSDTs로 대체하는 경우가 많습니다.
Clover:
클로버로 대체 가능한 패치들이 있습니다.
2. "HPET Fix"
3. "SMBUS Fix"
4. "IRQ Fix"
5. "RTC Fix"
7. "Fix Mutex with non-zero SyncLevel"
9. "Add IMEI" (do not use if your DSDT or SSDTs already have IMEI/HECI/MEI device)
13. MCHC Fix
14. PluginType
클로버의 Fixes 부분에 보시면 각각 해당하는 IRQ Fix를 제외하고는 각각 해당하는 이름이 있습니다. IRQ Fix는 중복되는 부분이 있으며, FixIPIC, FixTMR를 추가하면 됩니다. PluginType은 Generate Options에 PluginType을 체크하면 됩니다. Broadwell 포함 이전 세대 컴퓨터에서는 HPET Fix, IRQ Fix, RTC Fix를 적용하지 않으면 부팅시 확률적으로 소리가 나지 않는 경우가 있으므로, 적용하시는 것을 추천드립니다.
클로버는 패치된 DSDT와 OEM SSDT에 on-the-fly patch를 적용할 수 있습니다. 즉 DSDT를 패치해서 사용하는데, GFX0가 있다면 클로버에서 GFX0 to IGPU를 해주시면 됩니다. SSDT의 경우 patched 폴더에 들어갈 때 on-the-fly 패치가 적용되지 않습니다. 따라서 OEM이던, 직접 넣어주는 SSDT던 최종적으로 사용되어야 할 이름으로 저장해야 합니다.
예를 들면 그램 노트북은 GFX0등 많은 내용이 SSDT-XnSsdt.aml에 들어가는데, SSDT이기 때문에 SSDT 자체에 IGPU로 바꾸어주지 않으면 전력 관리가 제대로 이루어지지 않고, 클로버나 OC로 on-the-fly 패치를 적용하면 동일한 장치가 서로 다른 이름으로 기재되기 때문에 (DSDT에는 IGPU, SSDT에는 GFX0) 오류가 납니다. 하지만 WhateverGreen을 이용한다면, 장치 이름을 변경하지 않고 IOReg에서 IGPU로 인식되기 때문에 오류가 사라집니다. 조금 아래에 설명이 추가됩니다.
OpenCore
클로버에 있던 Fix가 오픈코어에 없기 때문에 모든 Fix들을 Add와 Patch로 추가해야 합니다.
2. "HPET Fix"
3. "SMBUS Fix"
4. "IRQ Fix"
5. "RTC Fix"
6. "OS Check Fix"
8. "Fix PNOT/PPNT" (use only if you're dropping CPU related SSDTs)
12. _PRW patches
13. MCHC Fix
14. PluginType
한 가지 비슷한 기능을 하는 것이 있는데, DisableIOMapper Booter Quirk입니다. 이는 클로버에서의 dart=0와 비슷하여, VT-D를 활성화시키고 macOS를 안정적으로 사용하고 싶을 때 사용합니다. 오픈코어를 이용한 멀티부팅에서는 DisableIoMapper가 필수입니다.
클로버와 다른 방식으로는 패치를 적용할 OEM DSDT/SSDTs를 선택할 수 있다는 점입니다. TableSignature에 DSDT/SSDTs에 해당하는 것을 선택해서 on-the-fly 패치를 적용할 수 있습니다. ACPI를 면밀히 살펴서 특정 테이블에만 오브젝트 정의를 적용해야 할 경우에는 OemTableId와 TableSignature에 테이블 정보를 입력하면 간혹 유용한 경우가 있습니다만, 매우 특수한 케이스입니다. 가령 SSDT 테이블에 매우 비슷한 문구가 있어서 고안한 패치 코드가 분명 여러 테이블에 적용될테지만, OemTableId를 입력함으로서 하나의 테이블에만 패치를 적용할 수 있습니다.
OC가 ACPI를 로드하고 윈도우를 부팅시키기 때문에 대부분의 패치는 윈도우와 호환되게 만들어야만 합니다. 기본적인 것들은 _STA method를 추가하거나 If (OSI("Darwin)), 추가한 _DSM을 DTGP 등으로 맥과 윈도우 내용을 분리해야 합니다. 이를 간소화하기 위해 WhateverGreen이 커맥 부팅시 IOReg DeviceTree에 기본적인 장치 이름들을 macOS에 호환되는 이름으로 바꾸어주고 있습니다: GFX0 to IGPU, HDAS/AZAL to HDEF, BOD3 to HDAU, HECI/MEI_ to IMEI. 즉 macOS에서는 패치된 이름으로 장치를 관리하고, 기타 OS에서는 기존 이름으로 장치 이름을 관리합니다.
기타 내용을 바꾸거나 새로 추가해야 하는 장치나 Method에 대해서는
Method (Mori, Num, xS)//기존 Method 이름
{
If (_OSI ("Darwin"))
{
...
}
Else {Xori (ARG 개수에 따라 Arg0, Arg1, Arg2,... 또는 없을 수도 있음)}//config.plist에서 헤더와 같이 패치된 이름 Xori
}
Method (Mnew, Num, xS)//새로 생성한 Method
{
If (_OSI ("Darwin"))
{
...
}
Device (Dwin)//윈도우용 Device
{
Method (_STA, Num, xS)
{
If (_OSI ("Darwin")){Return (Zero)}//_STA OFF
Else {Return (0x0F)}//_STA ON
}
...
}
Device (Dmac)//macOS용 Device
{
Method (_STA, Num, xS)
{
If (_OSI ("Darwin")){Return (0x0F)}//_STA ON
Else {Return (Zero)}//_STA OFF
}
...
}
등으로 입력합니다.
예를 들면 레노버 S340-14IWL의 I2C 터치패드는 polling mode로 작동하도록 다음의 SSDT를 적용할 수 있습니다: SSDT-TPAD.dsl
기존 장치인 TPAD의 _STA를 사용하지 않도록 config.plist에서 XSTA로 바꾸고 SSDT에 TPAD._STA를 macOS에서는 OFF, Windows에서는 기존 내용으로 설정합니다.
새로운 장치인 TPXX에 패치된 터치패드 코드를 복사하고 _STA를 macOS에서는 기존 TPAD 내용, Windows에서는 OFF로 설정합니다.
Find: <5f535441 08085f54 5f3000a2 3c017054 5044445f 545f30a0 11935f54 5f3000a0 05ff>
Replace: <58535441 08085f54 5f3000a2 3c017054 5044445f 545f30a0 11935f54 5f3000a0 05ff>
변경해주는 HEX가 긴 이유는 I2C0.TPAD._STA와 LPCB.PS2M._STA의 앞 부분이 상당히 비슷해서 그렇습니다. config ACPI 패치 하나당 한 Method에만 적용시켜야 안정적이기 때문에 그렇게 했습니다. TPAD만 수정하려고 했는데 PS2M까지 수정해버리면 이 장치는 제대로 작동하지 않겠죠. 굳이 둘을 같이 패치해서 새로운 SSDT에 PS2M에 해당하는 _STA를 입력해야 할 이유도 없고요.
더 다음의 글을 참고하시면 이해하기 훨씬 쉽고, 이 패치를 다른 것으로 대치할 수 있는 방법을 알 수 있습니다.
이런 방법으로 WhateverGreen을 이용하지 않을 경우 두 장치(기존 장치와 추가한 장치)로 macOS 패치를 적용할 수 있습니다. 하지만 장치 전체를 SSDT로 가져오고, 타장치에서 GFX0, BOD3, HDAS, IMEI와 정보를 주고받는 경우에 대해서 각 ACPI 부분을 SSDT로 가져와야 한다면 Static 패치를 하는 것과 다름 없습니다. 컴퓨터 부품을 바꿀 경우 새로 ACPI를 패치해야 할 가능성이 커집니다. 또한 IGPU, HDEF, IMEI의 이름은 맥에서 주로 사용되지만, 부트캠프에서도 동일한 이름이 사용될 것이기 때문에 해킨토시 사용에 필요한 필수 장치 오브젝트 이름 패치(GFX0, HDAS, HECI 등)는 config.plist의 패치를 사용해도 괜찮습니다.
OpenCore와 더불어 이 패치/Fix들을 SSDT로 대치해보고자 합니다. OC를 사용하고 윈도우와 듀얼부팅한다면 위 설명대로 각 Device와 Method에 적절한 Darwin과 DTGP 코드를 입력해야 합니다. OC에서의 IMEI의 경우는 WhateverGreen을 이용하거나, WhateverGreen를 이용하지 않을 경우 Darwin 코드를 이용해서 macOS에서는 _STA ON, Windows에서는 _STA OFF로 설정해야 합니다.
config.plist에서 ACPI Find/Replace를 하기 위해서는 다음의 방법을 알면 매우 수월합니다.
DSDT나 SSDT의 Hex 코드를 보고 싶다면
.aml을 ByteCode Listing으로 디컴파일하면 됩니다. iasl -l DSDT.aml SSDT*.aml로 디컴파일하고 필요한 테이블을 열어보면 각 코드에 해당하는 ByteCode가 적혀있습니다: 예를 들면
1159: A4 00 // ..
Method (GLUX, 0, NotSerialized)
{
115B: 14 46 07 47 4C 55 58 00 // .F.GLUX.
If ((DLMS == 0x07))
{
1163: A0 21 93 44 4C 4D 53 0A 07 // .!.DLMS..
M(GLUX,0,NS)를 M(XLUX,0,NS)로 바꾸고 싶다면 < 47(G) / 4C(L) / 55(U) / 58(X) / 00>를 < 58(X) / 4C(L) / 55(U) / 58(X) / 00>로 바꾸면 됩니다. 여기에 더해 해킨툴이나 클로버 컨피규레이터 계산기로 Hex와 ASCII를 변환하면 편리합니다.
이제 각각 어떤 패치를 적용해야 하는지를 알아보겠습니다.
3, 9, 13, 그리고 14는 Device/Method를 추가합니다:SSDT-SMBUS.dsl SSDT-IMEI.dsl SSDT-MCHC.dsl SSDT-XCPM.dsl
6번 패치는 종류가 매우 많습니다. 간략하게 설명을 먼저 하자면 _로 시작하는 Method들은 대부분 이름에 의미가 포함되어 있는데, _STA: Status, _PRW: Power Resources for Wake 등과 같이 _OSI도 마찬가지입니다: Operating System Interfaces. _OSI는 하나의 Argument를 가지는데, 부팅한 OS에 해당하는 Argument라면 True(0xffffffff)를 Return합니다. 커맥에서는 패치를 적용할 때 본인에게 알맞는 Windows를 선택해야 하며, 이는 ACPI를 잘 분석해야 할 수 밖에 없습니다. 하지만 최근 나오는 대부분 컴퓨터는 Windows 10 이상으로만 선택해주면 잘 돌아갑니다. VoodooI2C에서 Windows 10을 기본 패치로 선택하라고 하는 것도 OS fix는 이것으로 충분하기 때문이라고 볼 수 있습니다.
6. OS Check Fix-Clover: 여기서는 장치를 윈도우 성격으로 관리할 경우에 필요합니다. 주로 I2C 터치패드에 자주 사용됩니다. Windows 8 이하는 I2C 장치가 제대로 활성화되지 않습니다. 그런데 노트북에서 OS를 명시해주지 않는다면 많은 경우 default OS 버전으로 Windows 8 이하가 할당되기 때문에 OS를 첫 번째 버전의 Windows 10 이상으로 패치를 해주는 것이 좋습니다. 최근에 들어서는 Windows default OS가 높거나, I2C 장치에 OS를 기본 Windows 10으로 인식하도록 설정해서 OS check fix가 필요 없는 경우도 있습니다. Static 패치로서는 Darwin이라는 _OSI 코드 자체를 추가하지만, config.plist에서는 중간에 Darwin을 넣기 힘들기 때문에 (RehabMan은 클로버 Fix로 잘 안된다고 합니다) SSDT로 XOSI라는 이름 자체 아래 윈도우 정보를 넣어줍니다. 기존 _OSI 위치마다 XOSI라는 이름으로 패치가 적용되어야 하기 때문에 _OSI to XOSI 패치를 합니다. 또한 충돌방지를 위해 비슷한 이름인 OSID를 XSID로 바꾸어줍니다.
SSDT-XOSI에 Windows의 정보를 함께 Return하게 되어있는 것을 확인할 수 있습니다.
DSDT를 보시면 하이라이트한 부분이 있습니다. 이제 macOS가 인식한 system DSDT에서 XOSI에 대한 Initialization을 보면 SSDT XOSI에 들어있는 최종 OS 정보인 "Windows 2015"와 DSDT의 XOSI의 "Windows 2015"가 일치하기 때문에 macOS는 "Windows 2015", 또는 Windows 10처럼 작동합니다.
6. OS Check Fix-OC: OC가 패치된 ACPI를 윈도우에서도 로드하는 만큼 모든 _OSI를 XOSI로 변경시킨다면 윈도우에서 문제가 발생합니다. 그래서 _INI method에서 다른 정보를 추가해서 넣을 수 있도록 method 앞 부분을 수정해 보았습니다. 제 DSDT를 bytecode listing mode로 decompile하면 _OSI에 대한 _INI가 다음과 같이 코딩되어 있습니다.
그 중 제일 처음 부분인 OSYS에 관한 값 할당 부분은 제가 하이라이트한 부분에 해당됩니다: OSYS = 0x07D0
이 부분을 수정해서 다른 Method를 불러오도록 수정해보고자 합니다. XINI라는 method를 불러오도록 수정하자면 config.plist/ACPI/DSDT/Patches에 < 07 0B (할당) / D0 07 (reverse 07D0) / 4F 53 59 53 (OSYS) >를 < 58 49 4E 49 (XINI) / A3 A3 A3 A3 (아무 의미 없는 skipping code) > 로 변경합니다. 그러면 하이라이트 한 부분은 다음과 같이 변경됩니다.
이제 새로운 SSDT에서 XINI Method를 작성하면 됩니다.
기존에 config.plist/ACPI/DSDT/Patches에서 변경한 OSYS = 0x07D0를 새로 할당해주고, "Darwin", 즉 macOS인 경우에는 0x07DF를 OSYS에 할당해서 시스템을 Windows 10처럼 작동하도록 합니다. 전체적인 코드는 다음과 같이 인식됩니다.
macOS와 Windows에서도 큰 문제가 없을 것으로 예상됩니다.
분명 주의할 점은 본인의 _OSI에 해당하는 config.plist 패치 코드가 다를 수 있다는 점입니다. 각자의 DSDT를 iasl -l DSDT.aml로 확인해보셔야 합니다. SSDT-_OSI-XINI.dsl
이 패치는 강제로 다른 종류의 코드를 XINI로 맞추기 때문에 불한정합니다. (Noop으로 바꾸는 바이트는 제한되어 있는데, Scope를 정확히 명시하려면 부족하고, Scope 안 맞아서 DSDT가 SSDT를 스캔하다 오류로 인식하고 버려버린 경우가 생겼습니다...) 어쨌든 아래가 끝판왕.
6. OS Check Fix-Both for Clover and OC: github에서 발견한 방법입니다.
config.plist에서 _OSI to XOSI를 진행하면 대부분 DSDT는 다음의 내용과 비슷하게 If (XOSI ("abcdef"))가 여러 개 있는 것을 볼 수 있습니다.
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
Store (0x07D0, OSYS)
If (CondRefOf (\XOSI, Local0))
{
If (XOSI ("Linux"))
{
Store (0x03E8, OSYS)
}
If (XOSI ("Windows 2001"))
{
Store (0x07D1, OSYS)
}
If (XOSI ("Windows 2001 SP1"))
{
Store (0x07D1, OSYS)
}
If (XOSI ("Windows 2001 SP2"))
{
Store (0x07D2, OSYS)
}
If (XOSI ("Windows 2001.1"))
{
Store (0x07D3, OSYS)
}
If (XOSI ("Windows 2006"))
{
Store (0x07D6, OSYS)
}
If (XOSI ("Windows 2009"))
{
Store (0x07D9, OSYS)
}
}
...
맨 처음 OS fix에서는 package로 Windows들을 전부 다 포함했는데, 다음 SSDT를 보시면 이번에는 어떻게 XOSI로 의미를 부여하는지 알 수 있습니다. (c) athlonreg, github.com/daliansky/oc-little
DefinitionBlock ("", "SSDT", 2, "hack", "XOSI", 0x00000000)
{
Method(XOSI, 1)
{
If (_OSI ("Darwin")) // Darwin, 즉 macOS로 부팅한 경우에는
{
If (Arg0 == "Windows 2009" // = win7, Win Server 2008 R2 //만약 XOSI의 argument, 즉 If (XOSI ( ))에서 내부 괄호 안에 들어간 값이 "Windows 2009" 이라면
)
{
Return (0xFFFFFFFF) // True로 Return한다.
}
Else
{
Return (Zero) // macOS로 부팅했지만 위에 XOSI의 argument와 매칭되는 값이 없다면 무효가 된다. 즉 제대로 된 값을 위 "Windows 2009" 자리에 넣어야죠.
}
}
Else // macOS로 부팅한 경우가 아니라면
{
Return (_OSI (Arg0)) // XOSI (Arg0)를 _OSI (Arg0)로 간주한다. 즉 DSDT가 원래 _OSI였던 것처럼 인식하도록 합니다.
}
}
}
ACPI에서 정의하는 _OSI의 specification과 조화를 상당히 잘 이룹니다.
https://docs.microsoft.com/en-us/windows-hardware/drivers/acpi/winacpi-osi
본인 컴퓨터에 잘 맞는 _OSI Argument 값 맨 앞의 //를 지워주면 됩니다. 그 대신 본래 //가 없는 값은 //를 추가해서 comment out 시켜야됩니다. (Argument가 Arg0로 하나이기 때문에...)
파일: https://github.com/daliansky/OC-little/blob/master/02-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%A1%A5%E4%B8%81/SSDT-OC-XOSI.dsl
7. Mutex Fix는 Sync Level이 0으로 맞추어지지 않으면 Mutex와 관련된 정보를 주고 받을 때 문제가 발생한다고 합니다. Mutex Object는 Mutex(XXXX,Hex)로 되어있는데, 이 전체를 Mutex(XXXX,0x00)으로 맞추어주어야 합니다. 전체를 바꾸기 위해
<5B 01(Mutex) / Xx / Xx / Xx / Xx / HEX>를 <5B 01 / Xx / Xx / Xx / Xx / 00>으로 바꾸어줍니다. 예를 들어 제 DSDT에
Mutex (BATM, 0x01)
6FC5: 5B 01 42 41 54 4D 01 // [.BATM.
가 있다고 하면 저는 <5B 01 / 42(B) / 41(A) / 54(T) / 4D(M) / 01>을 <5B 01 / 42(B) / 41(A) / 54(T) / 4D(M) / 00>으로 바꾸어줍니다.
최근에 나오는 노트북은 대부분 Mutex가 0으로 설정되어 있는 것 같습니다. 클로버로 ACPI를 추출해서 확인해보시기 바랍니다.
또한 윈도우에서는 Mutex Object level이 0이 아닌 경우 오류가 무시되기 때문에 오픈코어에 패치를 주어도 상관이 없습니다.
8과 12는 기존 Method definition을 사용하지 않고 새로운 definition을 사용하는 Rename Replace 방식입니다.
8. PNOT/PPNT/PNTF에서는 해당 Method에서 아무것도 하지 않기 위해서 기존 Method(PXXX,Number,xS) Method 헤더를 Object 이름과 함께 아무 상관 없는 새로운 Object 이름, 즉 기존 ACPI에 존재하지 않는 이름으로 바꾸어주고, SSDT로 PXXX에서는 아무 내용을 수행하지 않도록 합니다. 제 예전 삼성 시리즈 5 울트라북에 PNOT이 있었는데 이름을 PYES로 바꾸었습니다: <50(P) / 4E(N) / 4F(O) / 54(T) / 08>를 <50(P) / 59(Y) /45(E) / 53(S) / 08>로.
다른 PXXX도 있다면 비슷한 방식으로 바꾸시면 됩니다. SSDT-Pstuff.dsl
12. _PRW patches는 잠자기에서 곧바로 깨어나버리는 현상을 패치합니다. 코드 중
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x6D, 0x03))//또는 0x6d 대신 0x0d
}
나 GPRW 대신 UPRW 등 다른 이름이 있는데, 뒤 3 또는 다른 숫자를 0으로 맞추어주어야 USB로 인해 잠자기에서 깨어나는 현상을 방지할 수 있습니다. 이 GPRW 부분을 (0xXX,0)로 바꾸어주도록 합니다. 그러기 위해서는 Method 이름을 헤더와 같이 바꾸어줍니다: <47(G) / 50(P) / 52(R) / 57(W) / 02>를 XPRW <58(X) / 50(P) / 52(R) / 57(W) / 02>로. 그리고 딱 이 부분만 (0xXX,Hex)를 (0xXX,0)으로 대치하기 위해서 다음의 SSDT를 사용합니다.SSDT-GPRW.dsl SSDT-UPRW.dsl
.dsl 열어보시면 Return값에 (0xXX,0)로 바꾼 GPRW(이제는 XPRW)를 수행하도록 되어 있는 것을 확인할 수 있습니다.
추가적으로 오래된 컴퓨터는 GPRW이나 UPRW이 없고 _PRW만으로 여러 장치들을 관리하기도 합니다. 또는 최신 컴퓨터에서도 _PRW 코드가 약간 다를수도 있습니다. 이럴 경우는 TGTBridge (Target Bridge, 즉 Scope를 읽고 그 아래 코드를 패치하는 방식) 으로 패치하면 됩니다. config-Sleep_PRW-0D:6D.plist SSDT-Sleep_PRW-0D:6D.dsl
물론 필요한 부분만 확인하셔서 사용하세요.
2, 4, 5는 SSDTTime을 적용하면 됩니다. 단, 그대로 사용한다면 윈도우까지 패치가 적용됩니다. 위에서 소개한 Rename Replace 방식으로 IRQ의 _CRS를 패치하면 됩니다.
여기까지 제가 알고 있는 기본 패치입니다. 조금 더 리얼맥과 가깝게 만들기 위해서 Memory Fix나 다른 장치를 추가하기도 하지만, 실사용에 그렇게 차이나는지 모르겠네요. 주로 SLPB, DMAC, MEM2, PWRB가 있습니다. 그리고 데스크톱에서는 NVRAM에 버그가 있는 보드(X299, Z370)에서 PMC 장치를 추가하여 NVRAM을 활성화할 수 있습니다. 구글에 검색해보시면 여러 자료 찾으실 수 있습니다.
1. 간단한 예를 하나 적용해보자면 제가 사용하고 있는 ASUS 노트북의 터치패드입니다. 무한클릭을 수정하기 위해서는 Integer USTP=1이라는 정보를 ACPI 테이블에 집어넣어야 합니다. 하지만 기존 테이블에 FieldUnitObject로 USTP가 존재합니다. 그렇다면 저는 이 USTP 전체를 원래 그대로 사용할 수 있도록 USTP to XSTP로 바꾸어줍니다: <55(U) / 53(S) / 54(T) / 50(p)> to <55(X) / 53(S) / 54(T) / 50(P)> 그리고 저는 새로운 SSDT에 USTP 이름의 항목을 생성하면 됩니다.
2. 컴퓨터마다 USB와 관련해서 XWAK, XSEL, ESEL 등의 이름이 있습니다. 전원과 관련해서 문제가 되기 때문에 Rename Replace로 헤더를 포함한 Method 이름을 다음의 SSDT의 코멘트와 매칭되게 바꾸어줍니다: SSDT-ESEL.dsl SSDT-XSEL.dsl SSDT-XWAK.dsl
USB
EC__라는 이름이 10.12-10.14(10.15 이후로는 USB와 관계는 없지만 부팅 필수)까지 USB 전력 관리에 사용됩니다. 또한 XHC 컨트롤러는 XHC_라는 이름으로, 그리고 EHC 컨트롤러는 EH0x라는 이름으로 사용되어야 USBInjectAll.kext가 제대로 적용되며, 만약 이름을 변경하지 않겠다면 해킨툴의 빗자루+주사기 버튼을 사용하면 됩니다.
1. 위 파일의 IOKitPersonalities에 있는 모델은 EC__라는 Device가 ACPI에 존재하면 추가전력이 활성화됩니다.
2. 위 파일의 IOKitPersonalities에 없는 모델은 EC__라는 Device가 ACPI에 존재하고, 별도의 USBX 장치 아래 kUSB properties가 존재하면 추가전력이 활성화됩니다. 해킨툴로 USBPorts.kext 생성시 이 켁스트의 info.plist에 kUSB properties가 있는 것을 확인할 수 있는데, 이것으로 추가전력을 활성화시킬 수도 있습니다.
EC__라는 이름이 EmbeddedControl과 비슷하기 때문에 이를 관리하는 H_EC, EC0_ 등의 Device의 이름을 EC__로 바꾸어주는 유저가 많았습니다. 하지만 리얼맥에서 EC와 성격이 다르고, AppleACPIEC가 잘못 로드되면 부팅 오류나 여러 버그가 발생할 수 있습니다. 데스크탑은 EC가 필요 없는 경우가 많기 때문에 PNP0C09의 _HID에 해당하는 Device의 _STA를 OFF로 return해야 한다고 합니다. 하지만 노트북은 대부분 PNP0C09의 device에서 여러 부분을 관리하기 때문에 Acidanthera에서 추후 이 문제를 해결할 수 있는 EC emulator를 개발할 예정입니다. 어찌되었던 그때까지는 EC를 새로 생성해주는 것이 가장 좋습니다. 문제가 생길 여지가 있는 PNP0C09과 USB 전력을 따로 분리하기 때문이죠. 리얼맥의 경로를 따라 _SB.PCI0.LPCB.EC를 생성합니다.SSDT-ECCorrect.dsl
대부분의 논맥 장치의 경우 EC__의 이름은 없지만, 혹시라도 존재한다면 EC0_로 변경하고, 새로 EC__를 생성해주는 것이 권장됩니다. 이 경우에 만약 ACPI에 ECDT.aml이 존재한다면, 변경한 이름에 맞추어 제대로 ECDT.aml이 로드되기 위해서 이 파일을 열어 기존 EC__의 이름을 EC0_로 변경시켜주세요.
배터리
배터리가 제대로 작동하기 위해서는 ACPI의 EC region의 FieldUnitObject들이 사용될 때 8비트씩 사용되어야 합니다. 그러기 위해서는 원도리님의 가이드나 RehabMan의 가이드를 읽어보시면 static patch를 적용할 수 있습니다. 원도리님은 Buffer를 전부 8비트로 나누어서 적용하셨고, RehabMan은 Buffer를 8비트씩 읽는 Method와 쓰는 Method를 사용했습니다. 그리고 직접 패치를 써보기 전에 본인 EC에 해당하는 패치가 있는지 macIASL에서 확인해보시고, 있으면 사용하고, 비슷하면 수정하시면 됩니다.
배터리 핫패치는 주로 Rename Replace를 사용합니다. 그리고 원래 EC region의 FieldUnitObject가 8비트 이하인 경우는 그대로의 EC region을 사용하도록 하고, 8비트 이상인 경우 새로 생성한 EC region을 사용하도록 합니다.
OEM table에 EC region의 16비트 이상 FieldUnitObject들이 아무곳에서도 사용되지 않는 것처럼 보이고, 아래 내용을 전부 진행했지만 배터리 표기가 정확하지 않을 수도 있습니다. 이 때 이 FieldUnitObject들이 다른 OEM table에서 사용되는지 확인해보세요. 사용된다면 8비트로 나누고, 다른 OEM table에서 이 변수를 사용하는 Method를 Rename Replace해주어야 합니다. 이는 LG 노트북에서 자주 발생하는 케이스입니다. 예: https://github.com/whatnameisit/LG-Gram-15ZD970-GX50K/tree/master/patches
터미널에 *는 제외하고
grep -rl "*변수이름*" *여기에 ACPI 폴더 끌어오기*
입력하시면 변수이름이 적혀있는 ACPI 테이블이 조회됩니다. ACPI 테이블을 열어 cmd+f로 찾아보세요.
배터리 hotpatch는 static 패치를 먼저 진행한 후 SSDT를 만들면 편리합니다. 이를 위해 DiffMerge라는 앱을 다운로드 받아, 패치 전 .dsl과 패치 후 .dsl을 비교하면서 SSDT를 만들 수 있습니다. 앱을 다운로드 받고(.pkg 확장자 추천. .dmg로는 터미널로 .sh 먼저 실행해야 합니다.) 터미널에서 패치 전/후 .dsl 경로에서
diffmerge U*.dsl P*.dsl
를 입력하면 둘을 비교하는 앱이 열립니다. 예로 사용되는 DSDT/SSDT는 그램 노트북의 EC region이 있는 SSDT-XnSsdt.dsl입니다.
PatchedBattery.dsl UnpatchedBattery.dsl
Rename Replace를 이용하기 위해서는 사용하고자 하는 Method 일부분을 새로 생성할 SSDT로 가져와야 하지만, 복잡하기 때문에 패치된 Method 전체를 복사합니다. 또한 Buffer나 비트를 같이 읽거나 쓰는 Method 역시 SSDT에 가져와야 합니다. 이 때 주의할 점은 Scope (디렉터리)를 명시해야 한다는 점입니다. DiffMerge가 패치전과 후가 다르다고 하는 부분을 macIASL로 보면 일부분은 Scope (\), 즉 (root) scope 아래 있습니다. 이 경우 Scope를 명시하지 않아도 되지만, Buffer를 읽도록 도와주는 Method는 H_EC Scope 아래 있습니다:
그렇다면 저는 두 경우를 각각 다음과 같이 SSDT로 가져옵니다:
DefinitionBlock ("", "SSDT", 2, "hack", "Battery", 0)
{
Method (GLUX, 0, NotSerialized)
{...
}//end glux
Scope (\_SB.PCI0.LPCB.H_EC){ //RE1B와 RECB를 H_EC device 하위항목으로 넣었습니다.
Method (RE1B, 1, NotSerialized)
{
OperationRegion(ERAM, EmbeddedControl, Arg0, 1)
Field(ERAM, ByteAcc, NoLock, Preserve) { BYTE, 8 }
Return(BYTE)
}
Method (RECB, 2, Serialized)
// Arg0 - offset in bytes from zero-based EC
// Arg1 - size of buffer in bits
{...
} //end re1b and recb
}//end h_ec device
}
GLUX는 root 경로에 있고, ReadBuffer는 EC 하위항목으로 들어갑니다.
이런 방식으로 Diffmerge에서 패치 전/후에서 다른 모든 Method를 Scope에 맞추어서 SSDT로 가져옵니다.
그 다음은 EC region입니다. 주의할 점은 원래의 8비트 이하 FieldUnitObject는 그대로 사용하고자 한다는 점입니다. 그렇다면 EC region을 다른 이름으로 사용해야 충돌하는 경우가 사라질 것입니다. 그리고 새로 생성한 EC Region에서 패치되지 않은 FieldUnitObject는 사용하지 않기 위해 EC Region 상에서 이 Object들을 Offset으로 무시합니다. Offset은 바이트(8=1)로 숫자를 세고 Hex라는 점에 주의해야 합니다. 나뉘어진 FieldUnitObject의 Offset을 계산하면 됩니다. 아래에 CBT0,8,CBT1,8,가 있는데, 이 위치를 찾기 위해서 0x83부터 숫자를 셉니다. 저는 항상 헷갈리는데, Hex는 1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,0순서입니다.
OperationRegion (ECX4, EmbeddedControl, Zero, 0xFF)//ECF4에서 ECx4로 변경
Field (ECX4, ByteAcc, Lock, Preserve)
{
Offset (0x01),
VER0,8,VER1,8,VER2,8, //나뉘어진 FieldUnitObj
CMC, 8,
...
Offset (0x81),
BT, 2,
BPU, 1,
Offset (0x82),
BST, 3,
Offset (0x83), //BTY의 위치를 알려주는 Offset. 앞으로의 숫자를 세는 것에 대해 이전 내용과 전혀 상관 없기 때문에 이 부분부터 숫자 세기 시작.
BTY, 8,
BDCH, 8,
BDCL, 8,
BFCH, 8,
BFCL, 8,
BDVH, 8,
BDVL, 8,
BWCH, 8,
BWCL, 8,
BLCH, 8,
BLCL, 8,
BCG1, 16,//여기까지 90, bcg1 시작점은 8e. 당연히 bcg1은 2로 세야 합니다.
BCG2, 16, //90부터 시작
BSNH, 8,
BSNL, 8,
BPRH, 8,
BPRL, 8,
BRCH, 8,
BRCL, 8,
BPVH, 8,
BPVL, 8,
BTP, 16, //여기까지 9c
CBT0,8,CBT1,8, //나뉘어진 FieldUnitObject. 9c부터 CBT0 시작
...
}
Field (ECX4, ByteAcc, Lock, Preserve)
{...
}
정리하면 다음과 같습니다.
이제 컴파일 누르면 에러가 뜹니다. 하지만 이 에러를 통해서 External Declaration, 즉 이 SSDT에 사용하는 Object 중 기존 ACPI 테이블에 존재하는 Object name과 경로를 어떤 것으로 추가해야 하는지를 알 수 있습니다. 제 경우 다음과 같은 에러가 생깁니다.
DLMS가 어떤 Object인지 모르겠다고 하네요. Statically 패치 된 SSDT를 열어서 Cmd+f로 DLMS를 검색하면 Definition을 찾을 수 있습니다:
Name(DLMS,0)로 되어있는데, Name(XXXX,Hex)는 Integer Object를 의미합니다. Scope는 root 경로이구요. 따라서 모든 Scope 바깥에 External Declaration을 추가합니다:
이런 식으로 External Declaration을 추가해 나갑니다. PkgObj(Name(XXXX,Package(Hex)), FieldUnitObj(Field 하위항목), DeviceObj(Device(XXXX)), IntObj, MutexObj(Mutex(XXXX,Hex))까지 보았습니다.
만약 패치된 SSDT를 찾아봤을 때 Object Directory가 root가 아니라면*
루트 경로부터 External Declaration을 입력하거나 해당 scope 아래 Declare합니다:
이런 컴파일 에러 없을때까지 모든 External Declaration을 마치고 무조건 .dsl로 저장합니다. 그 이후 다른 이름으로 .aml로 저장합니다.
닫고 나서 .aml을 열어서 External Declaration을 확인해야 합니다. macIASL 자체 오류가 있습니다. DefinitionBlock body 내에 Object가 경로가 명시되어 있지 않는 경우 .aml로 저장했을 때 macIASL이 자동적으로 루트 경로에다가 External을 생성하는 경우가 생깁니다. 이는 이 External Object가 작성중인 SSDT에 정의되어 있지 않기 때문에 macIASL이 잘못 컴파일하게 되는 것입니다. macIASL이 판단하기에 부족하다 싶으면 경우에 따라서 가짜 External declaration이 생성될 때가 있고, 그렇지 않을 때가 있지만, 잘못된 External declaration이 생긴다면 사용했을 때 배터리 표기가 오작동합니다. 예를 들면
이 부분에서 macIASL 자체 오류가 생깁니다. 저장하고 나면
로 잘못된 External Declaration이 생깁니다. 이 경우 저는 그램 노트북을 부팅시켰을 때 배터리 표기가 항상 100 %이었습니다. 오류를 수정하기 위해 다음과 같이 body 내에 경로를 추가해줍니다:
잘못된 External declaration을 지우고 저장하고 다시 열어보면 루트 경로에 TMP1이 없는 것을 확인할 수 있습니다. 그래서 * 표시한 부분과 같이 External Object가 루트경로가 아닌 경우 차라리 처음부터 그 Object를 루트 경로를 추가해주면 편리할수도 있습니다. Cmd+F로 찾아보기를 열면 오른쪽 끝에 Replace를 체크하고, Find에 원래 Object 이름을 넣고, Replace에 루트 경로를 포함한 Object의 Full Name을 입력해줍니다. **주의** 한꺼번에 바꾸면 원래부터 경로가 지정되어 있는 Object는 경로가 복잡해질 수 있습니다. 예를 들면
\_SB.PCI0.LPCB.EC.MAP1.MAR1인 경우 \_SB.PCI0.LPCB.EC.MAP1.\_SB.PCI0.LPCB.EC.MAP1.MAR1가 될 수 있겠죠. 새로운 경로마다 external declaration을 해야할 것처럼 컴파일 안되고, 컴파일되게 만들었다 하더라도 배터리 오작동합니다.
이제 B1B2, Read/WriteBuffer Method 등을 제외한 Method들, 즉 기존 ACPI 테이블에서 가져온 Method 이름들에 대해 config.plist 패치를 해주어야 합니다. 기존 Method와 충돌을 방지하기 위해 헤더를 포함해서 패치해줍니다. 제 경우 iasl -l SSDT-X*.aml로 디컴파일 해서 헤더 포함된 ByteCode를 찾아 기존 ACPI와 전혀 상관 없는 이름으로 바꾸어줍니다.
완성: SSDT-GramBAT.dsl
만약 여러 개의 SSDT hotpatch를 동일한 Method에다가 적용해야 한다면 패치한 모든 definition을 하나로 묶어서 한 개의 SSDT 안에 적용시킬 수도 있습니다. 예를 들면 위에 _Q67는 EC 키보트 코드에 해당할텐데 배터리에도 사용되었습니다. 제가 만약 디버깅으로 _Q67가 무슨 키인지 확인해보고, 적당한 Action을 선택했다면, 배터리 SSDT 안에 새로 넣어주고 싶은 _Q67 패치를 넣어주면 되겠죠. _Q67 자체는 몇 줄 되지 않기 때문에 전부 다 바꾸면 될겁니다.
다른 예로는, 삼성 논옵티머스 노트북 중 옵티머스 코드가 들어있는 노트북이 있습니다. 이 노트북에 _PTS와 _WAK가 배터리와 관련되어 있어서 패치해야 합니다. 동시에 _PTS와 _WAK에 옵티머스를 켜고(enable dGPU on _PTS: Prepare to sleep) 꺼야(disable dGPU on _WAK: Wake) 잠자기와 일어나기가 정상적으로 작동하는 경우가 있습니다. 이 경우에는 두 가지 결과가 따를텐데, 옵티머스에 해당하는 코드에 배터리 패치가 중복된다면 이 옵티머스 코드를 제거하고 배터리 패치를 적용할 필요가 없습니다. 결과적으로는 _PTS와 _WAK 내용을 지워야 하기 때문에 배터리 hotpatch 내용이 줄어듭니다. 만약 옵티머스에 해당하는 코드와 배터리 코드가 중복되지 않는다면 그대로 _PTS와 _WAK에 배터리 패치를 적용해주면 됩니다. 물론 옵티머스 부분을 한 번에 읽어내긴 어렵고, 그냥 있는 그대로 배터리 코드를 패치하는 것이 더 쉬울 수 있습니다.
외장그래픽 (옵티머스 기능) 전원 끄기
옵티머스 기능은 macOS와 호환되지 않기 때문에 외장그래픽 자체 전원을 꺼서 전력을 아끼도록 합니다. boot-args에 -wegnoegpu를 넣고, _PTS와 _WAK를 패치하면 잠자기에서 문제 없이 작동한다고 합니다.
읽어주셔서 감사하고, 혹시 제가 틀린 부분 지적해주시면 수정 반영하겠습니다~ 부탁드려요~
참고한 분들: RehabMan, 원도리님, oc-little
댓글로 잘 정리해주셔서 그런데 본문에 복붙해도 괜찮을까요?
사실 저는 외장 없는 노트북만 사용해보고 직접 안 해본 외장패치라 내용에서 제외했습니다. 그리고 WhateverGreen으로 부트옵션이나 Devices/Properties에외장 끄는 옵션을 넣어주면 아예 전원이 안들어온다고 하는데...모르겠어요. 직접 쓰는 노트북이 그렇다면이것저것 더 알아볼텐데요 ㅎㅎ;
구글링하면 젤 위에 뜰정도로 흔한 내용이라 그냥 원하시는대로 해주시면 됩니다
이젠 SSDT로 삽질 안 해도 WEG으로도 되나보네요 (이넘은 이것저것 너무 많은 기능을 가지고 있어서 기능 파악이 잘 안 됨)
저도 해당되는 기종을 현제 가지고 있진 않지만, 삽질해볼일이 있어서 그당시 쓰던 파일입니다
다만 개인적으로는 좀 귀찮아도 DSDT를 집어넣으시길 추천합니다
심지어는 아무 패치 안 하고, 에러 잡은후 넣는것만이라도 필요하다고 보는편입니다
가끔 DSDT가 없으면 작동이 좀 이상하거나, 업데이트가 제대로 안 되는 컴도 있습니다 (제경우 config.plist만으로 때운후 보안때문에 몇달에 1번 나오는 마이너 업데이트인 0.0.1단위 업데이트후 PCH랑 CPU 비호환 에러를 뿜으면서 부트자체가 안 되었었는데, DSDT 넣어준후 멀쩡하게 잘 되더군요 (이후 몇번 업데이트해도 멀쩡) )
이외에도 장치 인식이 좀 이상해서 붙었다가 잠자기후 떨어져서 안 돌아오는 경우도 있었습니다
결국 매번 좀 귀찮아도 DSDT를 생성하고 있습니다 (좀 귀찮은 작업이지만, PCIe장치등을 그렇게 자주 바꿀일 있는게 아니므로 패치 목록을 메모해두면 10분정도만에 끝납니다)
추신 : 다만 DSDT패치후 PS/2포트가 안 되는건 여전히 어떻게 고치는지 모르겠습니다 (전에 질문글 올린적 있지만 미해결) (DSDT없을때는 아무것도 안 해도 잘 되던게, DSDT가 있으면 Voodoo조차 안 먹히게 변합니다) (심지어는 DSDT에 PS2K/PS2M이 있어도 미작동)
추신2 : OpenCore는 아직까지 Clover랑 달리 Configurator같은 편한 설정 엡이 없고, ACPI쪽을 핫패치하기 귀찮아서 사용 안 해보고 미루고 있습니다 (시간이 해결해줄꺼라 믿습니다)
이 부분도 괜찮으시면 본문에 넣을게요.
저는 DSDT 없어도 노트북들이 잘 돌아가기 때문에 사용하지 않고 있습니다. 한가지 의심이 가는 부분은 1님 기존 DSDT와 macOS가 최종적으로 인식하는 DSDT가 달라서 그렇지 않을까 싶네요. 마치 추출한 DSDT와 macIASL로 열어본 System DSDT나 patchmatic으로 추출한 DSDT가 다른것처럼요.
잘 돌아간다면 DSDT 없는게 편합니다
PCIe나 BIOS옵션에 영향을 받기때문에 심지어는 NVMe 1개 교체해도 다시 해야하니 은근히 귀찮습니다 (무선랜, SSD등은 새로 안 해도 잘 돌긴하는데, 가끔 호환 안 되기도 해서 추천은 재추출입니다) (한떄 반짝(?)했던 BIOS개조해서 부트로더 심는 가이드에 따르면 심지어는 BIOS옵션까지 원하는대로 다 맞춘다음에 DSDT를 추출할것을 추천하고 있습니다)
기존에 잘 안 되었을때는 데탑이라 DSDT/SSDT 생성 안 하고, Clover에서 핫패치만으로 모든걸 떄웠었는데, 업데이트후 저래서 당황했습니다 (과거랑 달리 요즘은 업데이트후 이상 생기는일 거의 못 봤기때문에 더 당황)
Clover ACPI 핫패치는
https://www.tonymacx86.com/threads/clover-dsdt-fixes.176195/
를 보시면 좀 더 설명이 적혀있습니다 (덧글 수정할려니 답글때문에 안 되어서 여기 답니다)
엄청 좋은 정보인데 넘 어려워서 잘 따라 할수 있을지 모르겠네요. ㅠㅠ
이럴땐 리얼맥이 진리하는 생각이 ....
일단 사이다.
선 사이다 후 정독 해도 이해할 수 있을런지 모르겠지만,
고급 정보 감사합니다^^
좋은 글 감사합니다.
이 글을 읽으면서 많은 정보를 얻게 되었고
DSDT & SSDT 와 한 발짝 더 가까워지는 느낌입니다.
그리고, DSDT & SSDT 에 대해서 궁금했던 점들도 많이 풀렸습니다. :)
나중에 또 읽어봐야 겠어요~.
"님의 댓글"
이 댓글을 신고 하시겠습니까?
제목 | 조회 수 | 날짜 | 글쓴이 |
---|---|---|---|
macOS Sequoia 15.0.1 24A348 정식버젼 고스트 이미지 OC 1.0.2 ft: 전체공개 +30 | 944 | 24.10.1121:10 | 좌절금지 |
오픈코어 1.0.2 +23 | 579 | 24.10.0900:22 | 줌바이퍼 |
[중급편] 노트북 해킨 +16 | 1407 | 24.07.1219:19 | Stultus |
macOS Ventura 13.7 22H123 정식버젼 고스트 이미지 OC 1.0.1 ft: 전체 공개 +17 | 577 | 24.09.1917:09 | 좌절금지 |
macOS Sonoma 14.7 23H124 정식버젼 고스트 이미지 OC 1.0.1 ft: 전체공개 +31 | 910 | 24.09.1723:58 | 좌절금지 |
[초급편] 문제 스스로 해결하기 +20 | 4005 | 24.03.2920:07 | Stultus |
[입문편] 첫 해킨 길라잡이 +40 | 5090 | 24.01.1218:54 | Stultus |
[필독 - 안정화] macOS 해킨토시 설치 후 안정화 작업 목록 및 글타래 모음 총정리 📋 +67 | 5.1만 | 23.01.0913:39 | shl628 |
Hot AMD Sequoia용 AppleALC 1.9.2 +3 | 110 | 24.10.2319:04 | 사노라맨 |
Hot [Sequoia 15.0.1, OC r1.0.2] ASUS TUF B550-PLUS / RYZEN 5 5600X / RX470 +2 | 106 | 24.10.2322:26 | 뿌엥 |
Hot OCLP로 지원되지 않는 기기/dGPU를 사용하는 해킨토시의 사이드카 품질 문제 해결방법 +1 | 122 | 24.10.2321:29 | 해킨도전자 |
106 | 24.10.2322:26 | 뿌엥 | |
123 | 24.10.2321:29 | 해킨도전자 | |
111 | 24.10.2319:04 | 사노라맨 | |
791 | 24.10.1412:27 | shl628 | |
681 | 24.10.1316:00 | 수박 | |
346 | 24.10.1222:56 | Stultus | |
944 | 24.10.1121:10 | 좌절금지 | |
736 | 24.10.1115:53 | 수박 | |
579 | 24.10.0900:22 | 줌바이퍼 | |
1407 | 24.07.1219:19 | Stultus | |
1218 | 24.10.0500:31 | 줌바이퍼 | |
569 | 24.10.0410:49 | Tamy | |
749 | 24.09.2923:48 | 머트 | |
629 | 24.09.2822:28 | 머트 | |
463 | 24.09.2808:22 | Tamy | |
895 | 24.09.2321:32 | Stultus | |
995 | 24.09.2210:59 | 좌절금지 | |
646 | 24.09.2203:23 | 누림어멈 | |
1191 | 24.09.1919:17 | 좌절금지 | |
577 | 24.09.1917:09 | 좌절금지 | |
498 | 24.09.1813:37 | Stultus | |
910 | 24.09.1723:58 | 좌절금지 | |
602 | 24.09.1722:40 | 좌절금지 | |
453 | 24.09.1717:13 | 맥가즈아 | |
562 | 24.09.1708:13 | 김경석 | |
234 | 24.09.1617:47 | Panictosh | |
768 | 24.09.1504:35 | Tamy | |
584 | 24.09.1319:18 | Stultus | |
706 | 24.09.1019:44 | 치토 | |
484 | 24.09.0118:13 | 머핀X | |
463 | 24.09.0112:54 | 해킨도전자 | |
546 | 24.08.3115:34 | 머핀X | |
306 | 24.08.2601:42 | 화정큐삼 | |
306 | 24.08.2422:59 | 하나브 | |
319 | 24.08.2316:25 | 화정큐삼 | |
416 | 24.08.1810:56 | CanBe | |
363 | 24.08.1800:04 | 화정큐삼 | |
300 | 24.08.1722:03 | 화정큐삼 | |
201 | 24.08.1710:14 | jbhlyk | |
312 | 24.08.1622:06 | Stultus | |
218 | 24.08.1511:16 | hackillious | |
169 | 24.08.1421:30 | 세유니 | |
419 | 24.08.1419:58 | Stultus | |
377 | 24.08.1311:26 | 오디세이 | |
270 | 24.08.1115:46 | 좌절금지 | |
186 | 24.08.1111:21 | 티타보르 | |
233 | 24.08.1022:46 | Stultus | |
539 | 24.08.1022:10 | 오디세이 | |
168 | 24.08.1019:05 | jbhlyk | |
200 | 24.08.0923:20 | RogerT |
정리하느라 수고하셨습니다
하나 빠진것 있어서 추가합니다
SSDT-DDGPU.aml
Nvidia계열 그래픽이 달렸는데, Mojave 이상을 설치해서 정상 인식 안 되는경우 필요합니다
대게의 경우 SSDT없어도 부트는 잘 됩니다
다만 잠자기에 문제가 생기거나, 미사용인데도 전력이 공급되어 베터리 사용시간이 줄어듭니다
이걸 막기 위해 외장 GPU를 죽일 필요성이 생깁니다
기본적인 사항은
https://www.tonymacx86.com/threads/guide-disabling-discrete-graphics-in-dual-gpu-laptops.163772
에 나오므로 기술을 안 하겠습니다
dump된 ACPI의 aml을 죄다 dsl로 푼다음 검색해서
grep -l Method.*_OFF *.dsl
grep -l Method.*_INI *.dsl
를 줘서 나오는 결과물을 기준으로 양쪽 다 해당되는 파일을 열어서 장치의 주소를 찾아내면 됩니다
이후 첨부된 파일을 받아서 주소 부분만 수정해서 쓰시면 됩니다 (잘못 넣으면 부트 안 되거나하니 반드시 부트 USB 준비해주세요)
전력 관리이므로 EC 장치가 필요하므로 EC0 -> EC를 하는등의 방법 (이 게시물 본문에 적혀있으니 안 적습니다)으로 EC를 만드셔야 합니다