Hackintosh Acpi

0 views

Skip to first unread message

Dinah Lianes

unread,

Aug 3, 2024, 4:24:32 PM8/3/24

to blosrockpersma

Parameter group affecting various corrections of ACPI tables. This is a rather complex topic. There are several versions of ACPI specifications and additionally Mac has its own requirements. Often vendors are too lazy to write proper tables and internal devices may not be listed or CPU definitions are missing completely.

These two parameters serve a very important purpose: to fix restart. These values theoretically should be in the FADT table, but it is not always the case. Furthermore, FADT may be shorter than required and not contain them at all. Default values are 0x64/0xFE, which means a restart through the PS2 controller.
However, this does not work on every system and you can alternatively use 0x0CF9/0x06, which indicates a restart though the PCI rail. This is the default value for real Macs but does not always work on a hackintosh. The difference is clear: a hackintosh additionally has a PS2 controller, which may prevent rebooting, if not disabled.
Last but not least you can set them to 0x0/0x0 to allow the use of default FACP values. If not present, the default values states above will be used instead.

Clover will choose between 1 and 2 according to the mobility bit and according to the Mobile parameter in SMBIOS. It is, for example, possible to fake a mobile MacMini. Value 3 will be chosen if this parameter is enabled.

Some systems can either be started using the kernel parameter cpus=1, or by using a patched kernel (Lapic NMI). It turns out that in these case the table MADT is incomplete and missing the NMI section. Enabling this parameter will cause Clover to automatically correct this table. If the table already is complete, then nothing will be changed.

To calculate the mask you can use the Calculator app, switch into Programmer view and turn on the hexadecimal numbering system. Switch bits 0 to 15 to generate the required mask. Example with enabled FIX_DTGP and FIX_MCHC:

Some OEM DSDT already contains Method(_DSM...) for some devices. It has another structure, another logic, and another results then we need. But we can't modify this method, and we can't create own method with the same name, so DropOEM_DSM was created to drop these OEM _DSM.

Some OEM DSDT contains some device with Name (_ADR, 0xFFFF). This is a big problem as I can convert it to ADR=0 and inject properties but this is dangerous patch, it may lead to panic on IOPCIFamily.kext. So this key is proposed which will convert this device to (ADR, 0) and reused for injection. (FakeID for example)

Drops all internal SSDT tables to avoid conflicts when generating an SSDT for your processor, which contains P- and C-States. Clover can do this automatically or you can specify an external file, which will be loaded from EFI/OEM/[model]/ACPI/patched.

Automatic SSDT table generation, which extends the processor section with _CSTmethods for each core. _CST generation is affected by parameters EnableC2, EnableC4, EnableC6, EnableISS, C3Latency. There is no need to comment them as everything will work either way. Experiment by yourself.
Besides, Clover already has obtained the processor type and core count.
Not using this parameter will result in following error message:ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed.

This parameter lowers the CPU voltage and indirectly affects the temperature. Possible values are 0, 1, 2, etc. Clover will only allow sane values, meaning it is safe to increase this value until the CPU stops working correctly.

First sudo systemctl suspend or closing the lid works perfectly! No matter what amount of time it stays sleeping, it never wakes up by mistake, but if i try to do any suspend from here on it will always wake up instantly

I'm really new towards linux and programming in general, so the ideas i've had to try to fix this were all around what i found over this forum by searching "SUSPEND", most of them only goes towards the idea that XHC or XHC1 is still enabled hence its causing the issues. I've also read something about completely disabling bluetooth/usb driver (or thats what i understood), since it was too radical(and I'm not sure what it actually implies) i haven't done it yet and decided to try my luck on this post first.

I've also found someone complaining that it was a bug on the kernel version 4.19 / 4.20, but i've lost this link and i can't seem to find this reference again to search for some fix or what it was about.

Hi there! I'm also new in the community and I have a MacBook Pro 12.1 early 2015 . I had the very same issue as you do for a long time. Recently, I've decided to get rid of this issue once and for all! I discovered that the SD card reader disappears at the first sleep and never come back! As I never use it I decided to completely disable the device. To check if your problem is the same as me, you can do a simple lsusb before the first suspend and another after to confirm that the Apple SD card reader has disappeared.

After that, you can reboot and you are good to go! Personally, I have also disabled the LID0 event in /proc/acpi/wakeup, because when you suspend the machine and you close the lid after, it wakes up. That makes no sense for me...

Attention to all users, please note this guide and other khronokernel sites will be shutting down on April 16th, 2020. Reason for this is we've decided to move the guides to a dedicated organization to help simplify the hackintosh process and provide a single, trusted source for hackintosh information. This new organization will be known as Dortania.

ACPI l viết tắt của Advanced Configuration and Power Interface, dịch ra tiếng việt l Cấu hnh nng cao v Giao diện nguồn do Intel, Microsoft v Toshiba cng đề xuất v xy dựng vo năm 1997, sau đ c thm HP, Huawei v Phoenix tham gia. ACPI xc định giao diện giữa phần mềm hệ thống BIOS hoặc UEFI v hệ điều hnh, giao diện trừu tượng ha phần cứng.

N gip hệ điều hnh kiểm sot v phn phối hợp l sức mạnh của cc thiết bị phần cứng my tnh. Với ACPI, hệ điều hnh c thể tắt cc thiết bị phần cứng khc nhau khi cần theo tnh hnh thực tế của thiết bị.

Như đ đề cập ở trn, DSDT v SSDT l một phần của ACPI c tc dụng phc thảo cc thiết bị phần cứng như bộ điều khiển USB, luồng CPU, bộ điều khiển nhng, đồng hồ hệ thống, hệ thống cc luồng PCI, ...

SSDT (Secondary System Description Table) l bảng phụ của DSDT, sẽ được gộp vo DSDT khi nạp hệ điều hng, thường chứa cc một hoặc một t giao thức về CPU, GPU, hệ thống cảm biến, SATA, ...

Khi Hackintosh, DSDT thường được trch xuất đầu tin, sau đ SSDT tương ứng được ghi theo nội dung của DSDT để sửa DSDT gọi l hot patch đy l điều m khiến hackintosh dễ dng hơn v dễ tiếp cận hơn. Tất nhin, cũng c thể sửa đổi DSDT trực tiếp m khng cần sử dụng SSDT gọi l static patch, ngy xưa lc ti bắt đầu chơi th vẫn dng cch ny l chnh. Patch DSDT/SSDT l cần thiết để thực hiện khắc phục sự cố v điều chỉnh code DSDT cho tương thch với macOS.

Những kiến thức ny hiện tại đang rất trừu tượng, nhưng n rất quan trọng với hackintosh. Đơn giản bởi v macOS cũng l hệ điều hnh v n cần ACPI để nhận diện v điều khiển phần phần cứng. Cc thiết bị real mac như macbook, iMac, mac mini đều c bộ ACPI ring, vấn đề ở đy l qui định về tn v cc thnh phần trong DSDT/SSDT của real mac n khc so với những mainboard thng thường khc.

VD đối với card đồ hoạ onboard, trong DSDT my mac n tn l IGPU, nhưng trong DSDT mainboard thường th n lại tn l GFX0, vậy nếu để nguyn GFX0 th macOS sẽ khng nhận ra card onboard v khng khởi động được. Do đ cần phải sửa GFX0 thnh IGPU trong DSDT trước khi nạp vo hệ điều hnh, c thể l hot patch hay static patch đều được. Sẽ cần phải đổi tn nhiều device khc nữa, hiện nay đa số việc đổi tn ny đều do kext WhateverGreen đảm nhiệm nn bạn sẽ khng cần thm cc hot pach rename như lc xưa!

macOS sẽ c yu cầu một số hiện diện device m khng c hoặc bị tắt đi trong DSDT, v vậy chng ta cần khắc phục vấn đề ny. Cc device cần thiết phải được chỉnh sửa để macOS c thể khởi động động bnh thường:

OpenCore should be considered in Public Beta stage at this time and is intended to be used by experienced hackintosh users, developers, or users who are happy to recover a system which fails to boot or becomes broken in some way.

This guide may not always be able to keep up with every change to OpenCore, (currently OpenCore is in active development,and therefore a moving target) please keep that in mind when compiling the latest version of OpenCore.To be safe, use release versions of OpenCore rather than the latest commits. (0.0.4 Current Release)

USB drive formatted as MacOS Journaled with GUID partition map. This is to test opencore without overwriting your working Clover.Knowledge of how a hackintosh works and what files yours requires.A previously setup and functioning hackintosh is assumed: which you are happy to potentially break.Time and patience. Without these, you are wasting your effort.*Sign out of all apple services until you are sure you have MLB and ROM sections of smbios set to match your previous Clover set up. Not doing so could cause said services to cease to function, or worst case block your machine.

While sharing the name, the config.plist in OpenCore, is very different from Clover config.plist, they cannot be mixed and matched. It is also not recommended to duplicate every patch and option from your clover config.