오픈코어 다운로드 - opeunko-eo daunlodeu

안녕하십니까 ZISQO입니다 오픈코어 부트로더 오픈코어 부트로더의 첫 개발자 프리뷰 버전인 0.0.1이 엊그제 나온 것 같은데 벌써 0.6.1까지 발행되었군요 참으로 시간은 빠르고 또 빠르다 여겨집니다 이제 서서히 오픈코어 부트로더의 안정성이 개선되고 설정이 손쉬워(?)지는 관계로 아님 말고 식의 세팅은 아직도 범람하고 있기에 조금은 어렵게 느껴질 수 있는 부분이기도 하겠지만 알기 쉽게 핵심만 정리해서 포스팅 하도록 하겠습니다

⌘ ACDT의 공식 Configuration.pdf 문서를 Insanelymac에서 네임드 유저끼리 뭉쳐 작업했던 영어 가이드를 토대로 한국어로 빼곡하게 언어 변환및 다양한 마더보드의 ACPI 정보를 제공했던 당사자로써 2019년 3월 티스토리를 만든다음 티스토리엔 제  부고 소식외엔 들리지 않아서 간만에 이곳에도 알기 쉽게 서술하도록 하겠습니다

단, 블로그에 포스팅 된 내용을 마치 자신이 알아낸 것 처럼 포장해서 노략질 하는 싸가지 없는 행동은 부디 삼가해 주시길 당부 드립니다

흔히 EFI 파티션에 복사해주세요라고 하시는데 ESP 파티션에다가 EFI 시스템 파일을 복사해주시면 되는 간단한 구조를 가지고 있습니다

물론, ESP 파티션은 FAT32로 포맷되어 있어야 하며 HFS+ 또는 FAT32로 디스크를 포맷하면 손쉽게 ESP 파티션을 사용할 수 있습니다

1. USB 부트로더만 사용하려면 FAT32로 포맷해서 거기에 부트로더만 넣으셔도 됩니다
2. USB 부트로더에 별도의 애플리케이션을 넣으실 것이라면 ExFAT로 포맷한 다음 ESP 파티션에 부트로더를 넣어도 됩니다
3. HFS+로 포맷하면 맥오에스에서만 애플리케이션 파일들이 보입니다 (단, ESP 파티션을 크게 만들면 윈도에서도 읽기/실행 가능)

ESP 파티션 구조

EFI 시스템 폴더는 다음과 같이 구성됩니다

• BOOT : BOOTx64.efi 드라이버 파일이 존재하는 곳
• OC : ACPI / Bootstrap / Drivers / Kexts / Resources / Tools 폴더및 해당 파일이 존재하는 곳
• OC - ROOT : Config.plist 및 OpenCore.efi 드라이버가 존재하는 곳

만약 오픈코어 부트로더 부팅중 문제가 발생하면 디버그 모드를 사용해야 하는데 이 때 모든 파일을 변경할 필요없이 다음 파일만 교체하면 됩니다

디버그 모드를 이용해 오픈코어 부트로더 로그 생성 방법

• EFI/BOOT/
  
  • BOOTx64.efi

• EFI/OC/Bootstrap/
  • Bootstrap.efi
• EFI/OC/Drivers/
  • OpenRuntime.efi
• EFI/OC/
  • OpenCore.efi

오픈코어 디버그 바이너리를 직접 빌드하거나, 식스플로우 자료실에서 배포하는 자료를 이용하거나 MykolaG(크로노커널)에서 운영중인 Dotrania 가이드 문서의 바이너리 히스토리 내역에서 디버그 버전을 내려 받아 테스트 하시면 됩니다

오픈코어 부트로더 폴더별 파일 용도

ACPI

1. SSDT-ALS0.dsl : 맥오에스 10.15를 사용할 때 Ambient Light주변광 센서를 사용하고자 할 때 활성화 시키는 SSDT이며, 센서가 존재해야 작동합니다 물론, VirtualSMC에 포함된 SMCLightSensor.kext도 Injection추가되야 합니다
2. SSDT-AWAC.dsl : 현재까진 300 시리즈 칩셋만 사용가능하며 BIOS GUI에서 Legacy RTC 옵션이 존재하는데 이를 활성화 할 수 없을 때 사용합니다 더군다나 맥오에스에선 AWAC를 지원하지 않기에 RTC를 강제로 활성화 시켜야 하니 SSDT-RTC0.dsl 또는 SSDT-RTC0-Range.dsl을 사용해야하는 경우도 발생 합니다 Wake Timer를 사용할 때 시스템이 S3 / S4 상태에서 S0 상태로 변경되 ㄹ수 있습니다만Real Time Clock 알람과 비교해 Wake 타이머 작동을 위한 유연성을 사용할 수 있게 됩니다
   
   ★ 특히, HEDT를 제외한 데스크탑 플랫폼에선 RTC 정보의 Method가 STAS로 되어 있으니 이 항목을 _OSI가 Darwin일 경우 STAS는 0이 아닌 1의 값으로 사용할 수 있도록 변경할 수 있습니다 따라서 만약 여러분의 시스템에서 RTC0.dsl 패치를 진행하기 전 AWAC을 이용해 RTC 정보의 STAS=0 값을 _OSI = Darwin then STAS=1로 작동하면 굳이 RTC0.dsl 패치를 사용하지 않아도 됩니다

   그러나, AWAC 패치를 했음에도 불구하고 Verbose 모드로 부팅했을 때 VirtualSMC 관련 KP이 발생할 경우 AWAC대신 RTC0.dsl 패치를 사용해야 합니다

3. SSDT-BRG0.dsl : _SB.PCI0.PEG0.PEGP.BRG0 장치를 _SB.PCI0.PEG0.PEGP.GFX0으로 설정하는 패치입니다 주로 SMBIOS에서 GFX0이 외장 그래픽으로 잡혀야 하는데 마더보드 펌웨어에서 BRG0으로 고정될 경우 사용합니다(WhateverGreen으로 장치 이름 변경이 안될 때 변형해서 사용 가능)
4. SSDT-USBX.dsl : 마더보드에 선언된 EC0 장치를 초기화 시킨 다음 SB.USBX 장치를 추가해 USB 장치에 필요한 전력 값을 설정하며 USBports.kext / USBInjectAll.kext에서 호출한 IOKitPersonalities 장치에 대해 전력 값을 설정합니다만 대부분 인텔 내장 USB 컨트롤러에 국한되는 상황이 많으며 DESIGNARE 보드의 경우 썬더볼트 3로 사용되는 USB-C 포트도 15포트 정리 범주에 들어감을 기억하고 계시면 됩니다 이 작업을 통해 AppleACPIEC.kext가 로드되어 추가 전력 설정 오류를 해결하는데 사용됩니다
5. SSDT-EC.dsl : Darwin으로 부팅할 경우에 국한돼 SB.PCI0.LPCB.EC0 / SB.PC00.LPC0.EC0 장치를 초기화 시키는 역할을 하고 SSDT-USBX.dsl과 같이 사용됩니다
6. SSDT-EHCx_OFF.dsl : 7,8,9 시리즈 칩셋을 이용해 맥오에스 10.11을 사용할 때 이용하는 패치이며, 이는 EHC1 / EHC2를 비활성화 시켜 XHCI 모드를 활성화 시키기 위해 사용됩니다 CMOS 바이오스에서 XHCI 모드를 Enable 시킨다음 사용해야 합니다
7. SSDT-IMEI.dsl : 마더보드 펌웨어에서 IMEI 장치가 없을 경우 사용하며 샌디/아이비 브릿지의 경우 DeviceProperties에서 설정해야 하기도 합니다
8. SSDT-PLUG.dsl : XCPM을 지원하는 CPU 제품군을 위해 Plug type = 1을 선언하는 역할을 합니다 다만 Arg0, Arg1, Arg2, Arg3 변수를 사용하므로 SSDT-SMBUS-MCHC.dsl 파일을 같이 사용해야 합니다
9. SSDT-PMC.dsl : Z390 칩셋과 PCM(D31:F2) X299 칩셋에서 MMIO를 통해 사용할 수 있습니다만 ACPI에서 PMC 표준장치가 존재하지 않으므로 AppleIntelPCHPMC 드라이버에서 PMC 장치를 접속하기 위한 장치 주소인 APP9786을 가지고 있습니다 이 값을 선언해 PMC 장치를 로드하도록 합니다만 보통 HID PNP0C02 / UID PCHRESV를 사용하고 있긴 합니다 맥오에스를 사용할 때 다른 운영체제와의 혼동을 피하기 위해 SSDT에서 사용된 값만 로드 되도록 합니다
10. SSDT-RTC0.dsl : 300 시리즈 마더보드에서 AWAC 적용이 되지 않을 경우 사용하는 패치입니다 DSDT에서 SB.PCI0.LPCB.RTC 장치의 Method에 STAS가 선언되어 있어야 합니다 Darwin에선 0x0F 주소를 반환시켜 작동하게 되고 그 외 운영체제에선 이 패치가 적용되지 않도록 Return (Zero) 값을 반환합니다
11. SSDT-RTC0-Range.dsl : 카탈리나까지 패치의 필요성을 못 느끼지만 빅 서 운영체제부터 대부분 X299 마더보드에서 필요한 패치입니다 만약 이 패치를 사용하지 않고 오픈코어로 부팅할 경우 VirtualSMC가 로드되는 과정에서 NVRAM 항목을 로드시 발생하는 문제점으로 인해 부팅 불가한 상태에 놓이게 됩니다 물론 RTC0-Range.dsl 패치 이전 Awac으로 문제 해결이 될 경우 RTC0-Range.dsl 패치는 진행하지 않아도 됩니다
12. SSDT-SBUS-MCHC.dsl : SMBUS 호환성 향상을 위한 패치이며 특히 썬더볼트3 장치 그리고 CPU Plug type에 포함된 Method 변수인 Arg0, Arg1, Arg2, Arg3를 관리합니다

한 마디로 ACPI 폴더엔 무 작정 때려 넣고 진행하는 것이 아니라, 다음과 같이 먼저 마더보드 펌웨어의 ACPI 정보를 교정하기 위한 SSDT 온-더-플라이 패치를 진행하게 됩니다

1. SSDT-PLUG.aml : XCPM을 지원하는 CPU 유형의 경우 Plugin type=1을 활성화 시키기 위해 사용되며,  만약 본인의 시스템이 샌디/아이비일 경우 XCPM을 지원하지 않으므로 이는 Config.plist/Kernel/Quirks/AppleCpuPmCfgLock과 AppleXcpmCfgLock을 활성화 시키면 강제로 AICPUPM을 로드하므로 Revo girl 스크립트인 ssdtPRGen을 이용해 CPU 스피드스텝을 선언하면 됩니다

2. SSDT-AWAC.aml : X299이외의 마더보드에선 RTC 메모리 선언 이슈가 없기에 AWAC만 사용해도 충분히 별 문제없이 작동합니다만 Big sur부턴 RTC0을 사용해야 별다른 문제가 발생하지 않을 수 있습니다 X299 플랫폼은 빠꾸없이 RTC_Range를 사용해야 합니다

3. SSDT-EC-USBX : 마더보드의 Primary USB 컨트롤러의 15포트에 대해 추가 전력을 보내려면 반드시 설정해야 하며 해킨 툴을 이용해 USBports.kext를 생성하거나 USBInjectAll.kext를 이용해 마더보드 Primary USB 컨트롤러를 15포트 이하로 설정하도록 합니다

번외, 만약 NVRAM이 제대로 구동이 안되는 것 같다 이를테면 Boot-args 값을 변경했는데 재부팅 후 적용이 안된다거나, Bless를 이용해 부트 디스크 설정이 안되는 경우 대부분 Z390 시리즈 마더보드 즉 Aptio 펌웨어 4부터 극한의 어려움이 발생하게 되는데 이 때 PMC를 선언해 NVRAM을 강제로 읽고 쓰기 가능하게 변경할 수 있습니다

DRIVERS

다양한 efi 드라이버가 있습니다만 보편적으로 사용하는 efi 드라이버 위주로 설명하겠습니다 (종류가 꽤 많아서;;; 그래요 ㅎㅎ)

• AudioDxe.efi : Goldfish64의 패치를 통해 오픈코어 부트로더 사용시 부트 차임을 들을 수 있습니다만 내장 사운드 후면 출력으로만 사용가능합니다
• CrScreenshotDxe : 오픈코어 부트로더의 부트 피커화면에서 f10 키를 눌러 화면 캡쳐를 위한 드라이버 (GUI/TEXT 모두 해당)
• HfsPlus.efi : 맥오에스에서 HFS 파티션을 읽/쓰 가능하게 해주는 efi 드라이버 자매품 VBoxHfs.efi 드라이버는 HfsPlus보다 다소 작동이 느린감이 있으니 잘 판단해서 둘 중 하나만 사용하시면 됩니다
• OpenCanopy.efi : 오픈코어 부트로더의 부트 피커를 GUI로 표시하는 efi 드라이버이며 OcBinaryData와 함께 사용해야 아이콘 및 사운드 파일등을 사용할 수 있습니다 (디스크 레이블 사용자화도 들어있지만 이런 내용은 다음에 설명하도록 할게요)
• OpenRuntime.efi : 맥오에스 부트 커널 진입전 메모리 맵을 패치하는 역할까지 포함되어 있으며 중기 버전까지 FwRuntime.efi로 사용되었습니다 한 마디로 클로버 부트로더에서 쓸데없이 되면 좋고 안되면 지우지 뭐 이런 식으로 추가되던 Aptio fix 관련들 EmuVariable등의 패치들이 따로 쓰기엔 불편하니 하나로 모아 놓은 것이며 오픈코어 부트로더를 사용할 때 필수 드라이버로 꼽힙니다  즉 HfsPlus.efi와 OpenRuntime.efi는 무조건 Drivers 폴더에 존재해야 합니다

KEXTS

Kexts는 Kernel EXTension의 약어로써 오픈코어는 맥오에스 운영체제의 순정 파일을 절대 건드리지 않으므로 SLE/LE등에 밀어넣는 무식한 행동을 절대 권장하지 않습니다

더군다가 vit9696이 주도적으로 만들어 패치하고 있는 Lilu를 통해 Lilu와 종속되어 작동하는 VirtualSMC, AppleALC, WhateverGreen, CPUFriend 등은 반드시 Config.plist에서 Lilu보다 이후에 로드되도록 설정해야 합니다

Lilu에 종속된 플러그인들이  꽤 되지만 본인의 시스템이 정말 듣보잡 시스템이 아닌 이상 Kext 파일을 많이 구겨 넣어야 하는 시스템이 되지 않을 겁니다 대부분 랩탑에서 BrcmPatchRAM이나 AirportBrcmFixup이라던가 NVMeFix라던가 필요하게 되겠죠

RESOURCES

OcBinaryData 패키지를 다운로드 받아 압축해제한 다음 ESP 파티션의 EFI 시스템  폴더에 해당하는 경로에 붙여넣기 하면 됩니다

Tools

이 폴더에서 사용되는 efi 드라이버는 오픈코어 부트로더 시작시 부트 피커 상에서 사용할 수 있는 UEFI 쉘 관련 도구들입니다 여러가지 용도로 사용되는 만큼 본인에게 필요한 efi 드라이버만 넣어 사용하면 됩니다 (시스템 전원 끄기라던가 UEFI Shell이라던가 혹은 CFG Lock 핫스왑을 통한 비활성화 작업을 위해 VerifyMsrE2 드라이버를 쓴다거나 말이죠)

AMD 사용자는 안되나요?

AMD 제품은 쓰레드 리퍼의 경우 KVM과 PCI PT(Passthrough)를 활용해 시스템을 구성합니다 그 외 라이젠, 불도저 등은 Config.plist/Kernel/Patch를 통해 CPU 특성만 패치해 네이티브 부팅 가능하게 할 수 있습니다 항간에 떠도는 오픈코어 부트로더는 AMD용이다 그러는 이야기는 사짜 냄새나는 뉘앙스로 이해하시면 됩니다

뱀발 #1)
오픈코어 부트로더는 EDKII UEFI 부트로더를 이용한 멀티 플랫폼 부트로더이며, "윈도10 / 리눅스 전 시리즈"등이 다중 부팅하여 사용하는데 하등의 문제가 발생하지 않으며 특히 애플 제품의 경우 애플과 호환되지 않는 장치에 대해 호환성 테스트를 하는 것에 더 큰 목적을 가지고 있습니다 유독 한국에선 해킨토시를 커스텀 맥이라고 포장해서 부르고 있으니 리얼맥 유저에게 비난의 화살을 받는건 당연한 이치가 아닌가 싶기도 합니다

해킨토시의 목적은 다양하겠지만 Acidanthera의 큰 목적은 제가 이야기한 바와 크게 다르지 않습니다 그렇다고 정당화를 시키려는 것의 반박성 변명이 아닌, 해킨토시는 작동 안해도 제 경우에도 리얼맥 그거 사면 되는건데? 라는 생각을 당연히 가지고 있습니다 (더불어 신형 ARM 맥 미니를 손꼽아 기다리는 1인입니다)

그저 남들이 하니까 나도 해킨토시 써보고 싶다 이런 호기심으로 시작하시는 분은 부디 목적에 맞게끔 사용하시길 권장합니다

뱀발 #2)
오픈코어 부트로더는 커널을 해킹해서 사용하는 것이 아니라 윈도우, 리눅스, 맥오에스등에서 발생하는 부팅 문제를 부트로더 단에서 해결하는 방식으로 진행됩니다 클로버 부트로더를 사용하지 않는 큰 이유는 다름 아닌 마더보드 ACPI를 자기 멋대로 변경해서 부팅하기 때문에 알수없는 오류가 산넘어 산으로 올라오는데요 오픈코어 부트로더는 마더보드 ACPI를 깔끔하게 있는 그대로 가져와서 ACDT에서 제공하는 SSDT를 이용해 핫픽스 하는 구조로 되어 있어 ACPI 정보를 수정할 수 있는 능력이 1g이라도 있으시다면 세상 편한 시스템 구성을 할 수 있습니다 다만 Tonymac의 중구난방 코드는 ACDT에서 수용하지 않고 있는 점 그리고 Insanelymac에서 주도적으로 오픈코어 부트로더 정보가 공유되고 있는 점에 대해~ 아하~ 그렇구나 하시면 충분한 것 같습니다

뱀발 #3)
개인적으로 기가바이트 보드가 해킨토시에  좋다는 이야기는 솔직히 동의하기 어려운 이유가 ACPI 테이블이 지 멋대로 생성된 부분이 있고 특히 X299로 갈수록 PCIE 장치 전력관리 문제로 인해 별도의 패치없인 모하비 운영체제부터 잠자기/깨어나기 이슈가 상당히 심했는데 그나마 얼마전에 DSDT부터 뜯어내서 싹다 패치를 하니 그나마 쓸만 해졌지만... 솔직히 이야기 드려 ASUS 마더보드에 비하면 ACPI 테이블 편차가 큰 편에 속합니다 특히 NVRAM 관련된 이슈가 은근히 발생하고 특히 내장 그래픽을 활성화 시킨 다음 작동 불안정을 보이는 모습을 보면... 애시당초 해킨토시를 써봐야겠다 하고 마음 먹으신 분께선 ASUS 마더보드를 사용하시길 권장하는 바입니다 더군다나 CFG Lock을 바이오스 펌웨어 단에서 해제를 시켜야 스피드 스텝/시프트 등이 XCPM임에도 불구하고 대충 대충 작동하는 모습이 사라지게 되는데 기가바이트 보드는 희안하게 CFG Lock을 변경 못하게끔 바이오스 펌웨어 안에서도 해당 내용이 누락된 것을 확인했습니다 

반면 ASUS 마더보드는 아주 쉽게 CFG Lock 해제가 되서 최신 3006 바이오스를 사용해도 카비레이크 X CPU나 10시리즈 i7/i9 등의 MSR Lock(CFG Lock) 해제를 영구적으로 패치할 수 있습니다

바이오스 설정화면에서 MSR Lock이나 CFG Lock을 Disable 시켜도 사실 그건 무늬만 해제고 운영체제에선 해제로 받아 들여지지 않는 버그가 존재합니다 :) 그래서 해외 사이트에서 CFG Lock 관련 이슈로 난리가 났었는데 그 사단을 피해간 것이 ASUS 마더보드 제품 군입니다

끝으로 오픈코어 부트로더와 관련된 바이너리는, 식스플로우 디스코드 채널에서 손쉽게 다운로드 받으셔서 테스트 해보실 수 있습니다

본인의 시스템 호환성이 과연 어디까지 확장될 수 있는지 확인하시고, 부디 시간이 급하다고 비싼 금액 지불하면서 해킨토시 의뢰를 할 이유가 점점 사그라 들기도 합니다 

요즘엔 바이러스가 참 무서운데 말이죠 커뮤니티에서 어떤 바이러스가 담긴 파일일지 모르는 패키지 다운받아서 고생할 바엔 Dortarnia의 자동 배포 서버 또는 저 또한 ACDT와 동일한 방식으로 구축한 Xcode 자동 빌드/배포 서버를 통해 디스코드로 실시간 알림을 보내고 있으니 이와 관련된 내용은 Dortania 깃북 가이드또는 식스플로우 디스코드 채널 서버를 확인하시면 됩니다

감사합니다

At your own risks