Jump to content
8755 posts in this topic

Recommended Posts

18 hours ago, vit9696 said:

AppleALC implements TCSEL reset register functionality (named as ResetHDA in Clover) via alctcsel boot argument or alctcsel device property. Just inject alctcsel <01 00 00 00> into HDEF or pass alctcsel=1 via boot-args, and it should work. To debug this you can always check for "updating TCSEL register" line in the joint Lilu/AppleALC log by adding -liludbgall liludump=60 arguments and then inspecting /var/log/Lilu_x.x.x.txt file after booting macOS and waiting for 60 seconds for the file to save.

Thanks for the hints, though it doesn't seem to be enough. The issue with my audio chipset is that it either runs in HDA or I2S mode, and booting macOS repeatedly results in audio only working the first time. I'd assume it would run in either mode reproducibly, but it doesn't. What APCI _REV value does Darwin run with? I know for a fact that Linux/Ubuntu now forces _REV 2 (not overridable via acpi_rev_override) for it to stay in HDA mode.

Also, I've been running with HPET patches in ACPI but they don't seem to change the situation.

 

In most cases where audio doesn't work anymore the PCI device disappears from Hackintool, leading me to believe the device falls off the bus completely, causing alctcsel not to trigger (can't verify though as the Lilu debugging args don't seem to drop logs at /var/log for me).

 

To fix audio I have to boot into Ubuntu twice. The second time HDA mode is used successfully. Then booting macOS works until the next reboot.

Edited by beidl

UPDATE: All fixed just needed to disable CFG Lock!

With the latest version of Geekbench 5.2.3 released 8/5/20 my system is crashing on the last step "machine learning" its a total freeze and I  have to manually reboot it with the power key. Tried with 0.5.8 and 0.6.0. Anyone else having this same problem?

 

Edited by syn909
update
59 minutes ago, syn909 said:

With the latest version of Geekbench 5.2.3 released 8/5/20 my system is crashing on the last step "machine learning" its a total freeze and I  have to manually reboot it with the power key. Tried with 0.5.8 and 0.6.0. Anyone else having this same problem?

No it works for me.   Geekbench 5.2.3 with Big Sur beta 4 Ryzen 3900X.   

  • Like 1
6 hours ago, vit9696 said:

So the decision to switch to HDA/I2S is done by the embedded controller, is there any subtle difference between OpenCore and Clover in handling the EC?

Пытаюсь установить Big Sur на Asus x99 Deluxe + e5 2640v3. OpenСore 060. На фото остановился, попробовал fakesmc - тоже самое. В чем может быть проблема? Спасибо за помощь!

20494922.jpg

config.plist

Edited by Антико
3 hours ago, beidl said:

So the decision to switch to HDA/I2S is done by the embedded controller, is there any subtle difference between OpenCore and Clover in handling the EC?

OpenCore does not approach the EC anyhow, likely Clover also does not, at least not from what I know.

1 hour ago, Антико said:

Пытаюсь установить Big Sur на Asus x99 Deluxe + e5 2640v3. OpenСore 060. На фото остановился, попробовал fakesmc - тоже самое. В чем может быть проблема? Спасибо за помощь!

20494922.jpg

config.plist

Don't run FakeSMC.kext only WirtualSMC.kext, Lastest OC, Lastest kext and boot arguments vsmcgen=1 try problem see fixed.

 

Edited by xKaoSx
2 minutes ago, xKaoSx said:

Не запускайте FakeSMC.kext, только WirtualSMC.kext, Lastest OC, Lastest kext и аргументы загрузки vsmcgen = 1 попробуйте исправить проблему.

I tried with virtualsmc, and arguments were written - so far without result

config.plist

14 minutes ago, Антико said:

I tried with virtualsmc, and arguments were written - so far without result

config.plist

Update OC 0.6.0 Release.

Delete FakeSMC.kext and install VirtualSMC.kext

Update all kext

Open config OpenCore Configurator and go to Kernel Tab delete FakeSMC kext and add VirtualSMC.kext.

Go to NVRAM Tab and 7C436110-AB2A-4BBB-A880-FE41995C9F82 UUID go Bootargs change "vsmcgen = 1"  "vsmcgen=1" and try.

Maybe change "vsmcgen=2" try.

27 minutes ago, xKaoSx said:

Обновление выпуска OC 0.6.0.

Удалите FakeSMC.kext и установите VirtualSMC.kext

Обновить весь кекст

Откройте config OpenCore Configurator и перейдите на вкладку Kernel, удалите FakeSMC kext и добавьте VirtualSMC.kext.

Перейдите на вкладку NVRAM и 7C436110-AB2A-4BBB-A880-FE41995C9F82 UUID перейдите в Bootargs, измените "vsmcgen = 1" "vsmcgen = 1" и попробуйте.

Может поменять "vsmcgen = 2" попробовать.

No difference. Everything is already updated on OC 0.6.1., everything is updated, the error persists. I try to install from a flash drive, and from under Catalina - the result is the same

6 минут назад xKaoSx сказал:

Поделиться в папку EFI

Спасибо, возможно, вы увидите то, чего не видел я.

EFI.zip

opencore-2020-08-06-170634.txt

Edited by Антико
6 minutes ago, xKaoSx said:

Отключите DSDT.aml и попробуйте еще раз.

Какие части вашей системы?

I've tried it before - the result is the same. Asus x99 Deluxe, E5-2640 v3, GTX 770, ssd 860 evo

7 minutes ago, xKaoSx said:

If you disable dsdt , I get a kernel panic. I'll try your links tomorrow. Thank you for your time

MVIMG_20200807_000404.jpg

2 hours ago, vit9696 said:

OpenCore does not approach the EC anyhow, likely Clover also does not, at least not from what I know.

I rechecked the Ubuntu dmesg and noticed it forces _REV to 5, I got it backwards. I assume I'd have to hot-patch AppleACPIPlatform now to return 5 instead too, but I'm afraid I don't know how to find the actual binary data in order to replace it, I'm not that familiar with reverse engineering in that way.

With 10.15.6 I needed to unlock the MSR in my bios otherwise my machine would freeze running Geekbench however without the Kernel Quirk: AppleXcpmCfgLock the machine is slow and wont resume from sleep. Anyone have any suggestions on what to patch in the bios.

Edited by syn909

Not sure where to post this, but AirportBrcmFixup breaks my wireless. Reverting back to 2.0.7 makes it work again.

 

More details here:

https://www.insanelymac.com/forum/topic/336089-airportbrcmfixup/?do=findComment&amp;comment=2733233

6 hours ago, pkdesign said:

Not sure where to post this, but AirportBrcmFixup breaks my wireless. Reverting back to 2.0.7 makes it work again.

 

More details here:

https://www.insanelymac.com/forum/topic/336089-airportbrcmfixup/?do=findComment&amp;comment=2733233

 

AirportBrcmFixUp 2.0.8 are two drivers inside: for Big Sur, you have to load only Brcm NIC using boot-args. See Readme file in AirportBrcmFixUp repo: something like that: Brcmfx-driver=2

@vit9696 So I decided to go ahead and patch the AppleACPIPlatforms AcpiGbl_PreDefinedNames table to return 5 instead of 2 for _REV, to no success.

My approach:

Find: 1E8HAAAAAAABAAAAAAAAAAIAAAAAAAAA

Replace: 1E8HAAAAAAABAAAAAAAAAAUAAAAAAAAA

Any other hints I could follow?

 

My guess is that ResetHDA works in Clover because there's nothing being able to query _REV at the point where the device is being reset.

10 hours ago, Matgen84 said:

 

AirportBrcmFixUp 2.0.8 are two drivers inside: for Big Sur, you have to load only Brcm NIC using boot-args. See Readme file in AirportBrcmFixUp repo: something like that: Brcmfx-driver=2

I'm still on Mojave and have fixed my issue. See link:

I am sure there is a better way but this works.

 

EDIT:

I went back through and tried -brcmfx-driver=0|1|2|3 respectively without using a fake device-id and it did not work.

 

With fake device-id and no boot arg it works just fine (this is installation option 2 in README)

 

I am on Mojave (see signature) if that makes a difference.

 

Edited by pkdesign
  • Like 1
×
×
  • Create New...