search

acidanthera / bugtracker

Acidanthera Bugtracker
385 stars 45 forks source link

Question regarding order of ACPI manipulation operations #627

Closed andreyakostov closed 4 years ago

andreyakostov commented 4 years ago

Hello,

I was trying to figure out why ACPI patching is not working for me. Of course, the issue was my (false) understanding of how it's implemented - I thought the order is Block -> Add -> Patch, while in reality it's Patch -> Add -> Block.

My question is: is there a technical reason it's not the other way around? I am trying to avoid having a hybrid between manually renaming a device in my DSDT and patching it in the other tables.

If there is no reason, can an ACPI -> Quirks flag that switches the order be added? As it would be a possibly breaking change otherwise.

PS: First issue opened here, so I wanted to say thanks for all your hard work! :)

Andrey1970AppleLife commented 4 years ago

Use forums for support.

vit9696 commented 4 years ago

Hello,

I will still provide some technical background, so that it is easier to find. But indeed such questions are better on the discussion forums.

When we were deciding on the order, it was chosen to be most transparent and convenient for the end user.

Imagine that you want to write a proxy for some _ABC method already present in other ACPI tables. Let's say this method is part of an ACPI spec, so your own method must have the same name to get called. If you add a patch to replace _ABC with XABC and add an SSDT with _ABC method calling XABC, it will work cleanly Patch → Drop → Add model. However, it will fail badly if patching happens after Add, as your added table will also get patched.

This issue can also be resolved by restricting the patch to a particular table, but sometimes it is undesired. Since the user as full control on the added tables, we believe the approach to patch before adding is more flexible. So far we do not plan to change it, even as a quirk.

andreyakostov commented 4 years ago

@Andrey1970AppleLife not trying to be rude, but the issue template said:

When to use issue tracker: ...

  • You want to discuss technical or legal stuff

I thought my question falls under technical stuff discussion, as I'm not actually looking for support, rather asking a question for the technical implementation of a feature.

If you do not agree, I will post in a forum.

Edit: sorry, posted this comment before I saw vit's reply. Thank you for providing the information. I will use a forum next time if I have similar questions.

Best regards!

vit9696 commented 4 years ago

It is ok, sorry if we offended you. In general design considerations are discussed on the mailing list (as it is not really a bug), but we have none. I think the reference you mentioned was added due to some weird posting restrictions on insanelymac developer forums. We should probably reconsider some of our policies and let technical questions in the bugtracker for the time being.

eweiman commented 4 years ago

Rather than open a new issue I thought I'd ask the question here as it seems related (ACPI manipulation order of operations). If this should be on its own or in the forums I'll gladly move it.

During boot of OC, it performs the patches to DSDT/SSDT before loading the boot selection interface. General order seems to be as follows (based on my skimming of the debug boot log and there are probably several other steps, just trying to stay out of the weeds) 

1. detect CPU(s) - which I wonder if we could just hardcode our own values in the classic MacPro world
 -- like say 2 packages, with X5482 installed in the config.plist somewhere (if we can't get detection working)
2. load drivers
3. patch ACPI
4. patch SMBIOS
5. patch NVRAM
6. display UI
7. scan for devices to boot from
8. pick thing to boot
9. inject kexts
10. exit OC and continue booting OS.

So assuming that understanding is correct, is there a technical reason that the ACPI changes need to be done at step 3 and couldn't be done later say between steps 8 and 9?

The reason behind my ask here is that I'm using DSDT/SSDT patches (via AML not on-the-fly) to disable the Mac EFI flashed GPU (GTX 650) installed in slot-3 in favor of being able to use the RX 580 in MacOS as the Nvidia card just doesn't get the job done these days.

So during boot I see an initial splash from OC and then the ACPI patch loads and the GTX turns off and the RX card wakes up but for reasons I don't know GOP isn't loading properly with OC (but it does with refind/clover) on the MacPro 3,1 and because the ACPI patch is so early I never see the boot selection screen as the GTX was turned off, and because GOP doesn't do anything but load a blank screen in OC I can't see the image on the other display either. (the 4,1/5,1 for unknown reasons is unable to use a GOP ROM card at all to display pre-boot via clover/refind/OC, only the 3,1 and presumably older can with clover/refind but not OC until the OS starts loading, a 3,1 can verbose boot / single user boot via OC/refind/clover if flags added to NVRAM / com.apple.Boot.plist using the RX 580 GOP ROM)

If this ordering could be changed, this would allow those with any cMP to be able to boot via OC with any EFI flashed card that gets disabled before the OS loads to prevent compatibility issues with the card and the OS, and they'd be provided the ability to see / use the preboot environment as needed, and even get to single user mode if needed by bypassing OC.

vit9696 commented 4 years ago

ACPI code does not execute at all before macOS kernel loads. Your whole claim is not valid, and I am not sure I want to make sense of it given the wrong assumptions and a wall of text. The issue with MacPro3,1 is that it uses UGA rather than GOP, but we do not particularly know why ordinary text display OpenCore uses for menu drawing does not work. Feel free to debug it if you have skills, we do not have hardware and enthusiasm for this.

Short answer for the order is: we will not change it and there are very good technical reasons for it to be done this way. They are described somewhere in the bugtracker.

eweiman commented 4 years ago

It looks like it loads the ACPI changes long before the macOS kernel based on the debug log, but I'll certainly defer to your expertise.

I do appreciate the time and quick response from you. I tried to avoid wall of text but I also wanted to include details behind the reason for the request.

I know the Mac Pro used UGA, but the 3,1 can use a GOP ROM when booting Clover or refind and get the 3rd party graphical boot screen to pick an OS to boot and when used with aptiofix driver get verbose/single user mode access as well, none of that works on the 4,1/5,1 though even though the GOP driver is loaded in EFI shell it never seems to initialize / attach to the card.

My understanding of the ordering was done based on the debug log from my machine below. 


00:000 00:000 OC: OpenCore is now loading (Vault: 0/0, Sign 0/0)...
00:077 00:077 OC: Boot timestamp - 2020.01.14 20:46:00
00:148 00:071 OCCPU: Hypervisor: 0
00:220 00:071 OCCPU: Found Intel(R) Xeon(R) CPU           X5482  @ 3.20GHz
00:291 00:070 OCCPU: Signature 10676 Stepping 6 Model 17 Family 6 Type 0 ExtModel 1 ExtFamily 0
00:365 00:073 OCCPU: Detected Apple Processor Type: 05 -> 0301
00:445 00:080 OCCPU: Ratio Min 0 Max 8 Current 0 Turbo 0 0 0 0
00:517 00:071 OCCPU: Timer address is 408 from LPC
00:689 00:172 OCCPU: CPUFrequencyFromTSC  3191999344Hz  3191MHz
00:767 00:077 OCCPU: CPUFrequency  3191999344Hz  3191MHz
00:839 00:071 OCCPU: FSBFrequency   398999918Hz   398MHz
00:911 00:071 OCCPU: Pkg 1 Cores 4 Threads 4 <<< should be 2x these values
00:983 00:071 OC: OcLoadUefiSupport...
01:055 00:071 OCC: Install console control 1 - Success
01:128 00:073 AmiEfiKeycodeProtocol is unavailable on gST->ConsoleHandle - Unsupported
01:200 00:071 EfiSimpleTextInputExProtocol is unavailable on gST->ConsoleHandle - Unsupported
01:272 00:071 gST->ConIn 7E776870 vs found 7E776870
01:344 00:072 OC: Missing GOP on ConsoleOutHandle, will install - Unsupported
01:426 00:082 OCC: Configuring console ignore 0 san clear 1 clear switch 0 replace tab 0s
01:506 00:079 OCC: Configuring behaviour 3
01:596 00:090 OC: Got 1 drivers
01:668 00:071 OC: Driver FwRuntimeServices.efi at 0 is being loaded...
01:756 00:088 OC: Driver FwRuntimeServices.efi at 0 is successfully loaded!
01:828 00:071 OC: Connecting drivers...
01:900 00:071 OC: OcLoadAcpiSupport...
01:972 00:071 OCA: Found 26 ACPI tables
02:044 00:071 OCA: Detected table 50434146 (003030656C707041) at 7F740000 of 244 bytes at index 0

<output removed of all tables>

03:965 00:081 OCA: Replaced DSDT of 17886 bytes into ACPI   <<<<<< that looks like being patched to me?
04:043 00:078 OCA: Inserted table 54445353 (0034343838696350) of 1334 bytes into ACPI at index 26
04:115 00:071 OCA: FACS signature is 0 (0)
04:187 00:071 OCA: Exposing XSDT table 50434146 (003030656C707041) at 7F740000 of 244 bytes at index 0

<output removed of all tables>

08:162 00:070 OC: OcLoadPlatformSupport...
08:240 00:077 OCSMB: SmbiosLookupHost failed to lookup SMBIOSv3 - Not Found
08:318 00:078 OCSMB: Found DMI Anchor 7F6EC000 v2.4 Table Address 7F67F000 Length 1754
08:392 00:073 OCSMB: Number of CPU cache entries is 16
08:472 00:080 OCSMB: Applying 3039 (1) prev 7F6EC000 (5972/31), 0 (0/0)
08:544 00:071 OCSMB: Patched 7F98F000 v3.2 Table Address 7F990000 Length 0BDF 1E FC
08:616 00:071 OC: OcLoadDevPropsSupport...
08:688 00:071 OC: OcLoadNvramSupport...
08:768 00:079 OC: Setting NVRAM 7C436110-AB2A-4BBB-A880-FE41995C9F82:boot-args - ignored, exists
08:840 00:071 OC: Current version is DBG-052-2019-10-30
08:914 00:074 OC: OcMiscLateInit...
08:989 00:074 OC: Setting NVRAM 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:b = PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x4,0x0,0x0)/HD(1,GPT,EBFD9C80-5C5C-47C6-AAD5-48F47BFA6C27,0x28,0x64000)/\EFI\BOOT\BOOTX64.efi - Success
09:060 00:071 OC: LoadHandle is 7DBFD818 - Success
09:132 00:071 OC: Requested resolution is 1920x1080@0 (max: 0) from 1920x1080
09:204 00:071 OCC: Requesting 1920x1080@0 (max: 0) resolution, curr 4294967295, total 7
09:276 00:071 OCC: Mode 0 - 1920x1080:1
09:348 00:071 OCC: Setting mode 0 with 1920x1080 resolution
09:432 00:083 OCC: Changed resolution mode to 0
10:856 01:424 OC: Changed resolution to 1920x1080@0 (max: 0) from 1920x1080 - Success
10:928 00:071 OC: Requested console mode is 0x0 (max: 1) from Max
10:999 00:071 OCC: Requesting 0x0 (max: 1) console mode, curr 0, max 1
11:071 00:071 OCC: Mode 0 - 80x25
11:149 00:078 OCC: Current console mode matches desired mode 0, forcing update
11:221 00:071 OCC: Setting mode 0 (prev 0) with 80x25 console mode
11:298 00:076 OCC: Changed console mode to 0
11:372 00:073 OC: Changed console mode to 0x0 (max: 1) from Max - Success
11:452 00:080 OC: Translated HibernateMode None to 0
11:524 00:071 OC: Hibernation detection status is Not Found
11:596 00:071 OC: OcLoadKernelSupport...
11:674 00:078 OC: OpenCore is loaded, showing boot menu...
11:746 00:071 OCB: Performing OcScanForBootEntries...
11:818 00:071 OCB: Found 21 potentially bootable filesystems

<output removed of scanning all bootable FS, which apparently takes about 110 seconds to complete>

122:726 05:106 OCB: Should boot from macOS Mojave (T:1|F:0)
122:799 00:073 OCB: Perform boot macOS Mojave to dp PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x4,0x0,0x0)/HD(2,GPT,02DE25C0-6380-4AAD-B42B-7C9CCA6B0CB4,0x64028,0x5FC1FDF0)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,7F2B0FFD43DADB499B56981778BF0860)/\8E4BA677-0580-4145-8A0B-0E1B3AE1B417\System\Library\CoreServices\boot.efi (0/0)
122:877 00:077 OCB: Matching <> args on type 1 0
122:949 00:072 OCC: Configuring behaviour 0
123:159 00:209 Trying XNU hook on System\Library\PrelinkedKernels\prelinkedkernel
123:334 00:175 Kext reservation size 6774784
124:535 01:200 Result of XNU hook on System\Library\PrelinkedKernels\prelinkedkernel is Success
124:629 00:094 OC: Read kernel version 18.7.0 (180700)
124:738 00:108 OCAK: PanicKextDump replace count - 1
124:817 00:078 OCAK: Patch success kext dump
124:968 00:151 OC: Prelink injection AAAMouSSE.kext () - Success
125:039 00:071 OC: Prelink injection AHCI_3rdParty_SATA.kext () - Success
125:193 00:153 OC: Prelink injection GenericUSBXHCI.kext () - Success
125:269 00:075 OC: Prelink injection LegacyUSBInjector.kext () - Success
125:353 00:084 OC: Prelink injection Lilu.kext () - Success
125:439 00:086 OC: Prelink injection SIPManager.kext () - Success
125:524 00:084 OC: Prelink injection WhateverGreen.kext () - Success
125:642 00:117 Prelinked status - Success
125:807 00:165 OC: OcAppleGenericInputKeycodeExit status - Success
vit9696 commented 4 years ago

Please read attentively what I say. I did say that ACPI code does not execute before macOS start. ACPI table patching done by OC has nothing to do to ACPI code execution. It will be great if you read ACPI spec before making thoughts.

As for GOP/UGA, refit/clover support rendering to UGA, so I do not think it proves anything. Just in case, may I see your config?

eweiman commented 4 years ago

I was reading what you wrote, I was explaining how I formed my conclusions.

Here is the OC config I'm using (0.5.2 debug, tried moving to 0.5.3 but I couldn't get it to boot, so rolled back): config.plist.zip

As a side note this is refind loaded claiming it is using GOP to display on the RX 580 in the 3,1 (rather than showing that it was using UGA Draw which you see with a standard Mac EFI flashed card). IMG_1976

With OC being reported as supporting GOP I expected that I'd be able to use a GOP card in the same manner as refind but it doesn't work until verbose boot starts.

contents of the EFI partition:

macpro-osx:EFI ludacrisvp$ find /Volumes/EFI/EFI|grep -v \._|sort
/Volumes/EFI/EFI
/Volumes/EFI/EFI/APPLE
/Volumes/EFI/EFI/APPLE/EXTENSIONS
/Volumes/EFI/EFI/APPLE/EXTENSIONS/Firmware.scap
/Volumes/EFI/EFI/BOOT
/Volumes/EFI/EFI/BOOT/BOOTx64.efi
/Volumes/EFI/EFI/BOOT/old.BOOTx64.efi
/Volumes/EFI/EFI/OC
/Volumes/EFI/EFI/OC/ACPI
/Volumes/EFI/EFI/OC/ACPI/DSDT.aml
/Volumes/EFI/EFI/OC/ACPI/SSDT-18-Pci8844.aml
/Volumes/EFI/EFI/OC/Drivers
/Volumes/EFI/EFI/OC/Drivers/FwRuntimeServices.efi
/Volumes/EFI/EFI/OC/Kexts
/Volumes/EFI/EFI/OC/Kexts/AAAMouSSE.kext
/Volumes/EFI/EFI/OC/Kexts/AAAMouSSE.kext/Contents
/Volumes/EFI/EFI/OC/Kexts/AAAMouSSE.kext/Contents/Info.plist
/Volumes/EFI/EFI/OC/Kexts/AAAMouSSE.kext/Contents/MacOS
/Volumes/EFI/EFI/OC/Kexts/AAAMouSSE.kext/Contents/MacOS/MouSSE
/Volumes/EFI/EFI/OC/Kexts/GenericUSBXHCI.kext
/Volumes/EFI/EFI/OC/Kexts/GenericUSBXHCI.kext/Contents
/Volumes/EFI/EFI/OC/Kexts/GenericUSBXHCI.kext/Contents/Info.plist
/Volumes/EFI/EFI/OC/Kexts/GenericUSBXHCI.kext/Contents/MacOS
/Volumes/EFI/EFI/OC/Kexts/GenericUSBXHCI.kext/Contents/MacOS/GenericUSBXHCI
/Volumes/EFI/EFI/OC/Kexts/LegacyUSBInjector.kext
/Volumes/EFI/EFI/OC/Kexts/LegacyUSBInjector.kext/Contents
/Volumes/EFI/EFI/OC/Kexts/LegacyUSBInjector.kext/Contents/Info.plist
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Info.plist
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/MacOS
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/MacOS/Lilu
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/arm.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/arm64.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/capstone.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/mips.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/platform.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/ppc.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/sparc.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/systemz.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/x86.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Headers/capstone/xcore.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/LegacyIOService.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/LegacyLibkernMacros.h
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/libkmod.a
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/security
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/wrappers
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/wrappers/build.tool
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/wrappers/entry32.S
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/wrappers/entry64.S
/Volumes/EFI/EFI/OC/Kexts/Lilu.kext/Contents/Resources/Library/wrappers/wrappers.inc
/Volumes/EFI/EFI/OC/Kexts/SIPManager.kext
/Volumes/EFI/EFI/OC/Kexts/SIPManager.kext/Contents
/Volumes/EFI/EFI/OC/Kexts/SIPManager.kext/Contents/Info.plist
/Volumes/EFI/EFI/OC/Kexts/SIPManager.kext/Contents/MacOS
/Volumes/EFI/EFI/OC/Kexts/SIPManager.kext/Contents/MacOS/SIPManager
/Volumes/EFI/EFI/OC/Kexts/WhateverGreen.kext
/Volumes/EFI/EFI/OC/Kexts/WhateverGreen.kext/Contents
/Volumes/EFI/EFI/OC/Kexts/WhateverGreen.kext/Contents/Info.plist
/Volumes/EFI/EFI/OC/Kexts/WhateverGreen.kext/Contents/MacOS
/Volumes/EFI/EFI/OC/Kexts/WhateverGreen.kext/Contents/MacOS/WhateverGreen
/Volumes/EFI/EFI/OC/OpenCore.efi
/Volumes/EFI/EFI/OC/OpenCore.efi.053d.053
/Volumes/EFI/EFI/OC/Tools
/Volumes/EFI/EFI/OC/config-053-broken.plist
/Volumes/EFI/EFI/OC/config-lkg.plist
/Volumes/EFI/EFI/OC/config.plist
/Volumes/EFI/EFI/OC/config.plist-052-debug-MP31-HEVC-ENC-VMWARE.zip
/Volumes/EFI/EFI/OC/config.plist.zip
/Volumes/EFI/EFI/OC/iMacPro-config-hevc-encode.plist
/Volumes/EFI/EFI/OC/iMacPro-config-rev1.plist
/Volumes/EFI/EFI/refind
/Volumes/EFI/EFI/refind.log
/Volumes/EFI/EFI/refind/REFIND.efi
/Volumes/EFI/EFI/refind/REFIND2.efi
/Volumes/EFI/EFI/refind/Shell64.efi
/Volumes/EFI/EFI/refind/icons
/Volumes/EFI/EFI/refind/icons/README
/Volumes/EFI/EFI/refind/icons/licenses
/Volumes/EFI/EFI/refind/icons/licenses/cc-3.0.txt
/Volumes/EFI/EFI/refind/icons/licenses/cc-by-sa-4.0.txt
/Volumes/EFI/EFI/refind/icons/licenses/gpl-2.0.txt
/Volumes/EFI/EFI/refind/icons/licenses/lgpl-3.0.txt
/Volumes/EFI/EFI/refind/icons/mouse.png
/Volumes/EFI/EFI/refind/icons/transparent.png
/Volumes/EFI/EFI/refind/refind.conf
vit9696 commented 4 years ago

Interesting, though I am not sure how much it is to be trusted. In any case, rEFIt is using GOP, while OpenCore is using text protocols and console for output.

Your configuration is written for Hackintosh, not Macintosh. It is a miracle it even somehow boots. Booter quirks, kexts, uefi quirks, all that is terribly messed up. I believe you did not read the manual, and I do not think it is reasonable to continue any discussion.

At the very least disable the following, these will definitely break Mac EFI. Most of your config is to be disabled as well, but I do not want it is worth for me to mess with it: