[pre-release] macOS Sonoma

[ANTIKO]

13 hours ago, chris1111 said:

Its not 6 its 7

What kind of model? thanks

[chris1111]

15 minutes ago, ANTIKO said:

What kind of model? thanks

 

TL-WN821N -V5 

⬇︎

Spoiler

 

[eng_redaesm]

6 hours ago, SavageAUS said:

Can you share your config.plist please.

 

here it is

 

config.plist

[Takiller]

1 hour ago, ANTIKO said:

It's very long🙂, it takes me about 8 seconds, but I haven't measured it.

I would really love my boot time to be 8 seconds 😂

[surenmunoo]

2 hours ago, MorenoAv said:

Hi guys good afternoon,

Quick question your SoNoWifi takes how much time to boot ?, mine takes almost 5 minutes to boot, it's annoying...

At this moment I'm not home, so no EFI to send but later today I'll post it here.

Thanks

 

Boots really quick for me, a few seconds and I am in the desktop screen 

[MorenoAv]

Now I'm at home, and here it is my EFI Folder, OpenCore 0.9.4 and all kexts updated...

Thanks for all your responses, but I don't know what Im doing wrong, if one of you could review my EFI and point me in the right direction, I'll appreciate it..

 

EFI.zip

Edited June 26, 2023 by MorenoAv

[cankiulascmnfye]

@MorenoAv Why are you using a patched DSDT by MaLDon?

[chris1111]

55 minutes ago, cankiulascmnfye said:

@MorenoAv Why are you using a patched DSDT by MaLDon?

Because @MaLd0n is the best and its a Legend on Hackintosh World for a 15 years is helping people here and everywere.

So are DSDT is perfect

[SavageAUS]

Hi guys good afternoon,
Quick question your SoNoWifi takes how much time to boot ?, mine takes almost 5 minutes to boot, it's annoying...
At this moment I'm not home, so no EFI to send but later today I'll post it here.
Thanks
 

Mine takes quite a while as well on my dell laptop but on my AMD desktop and Metabox laptop it’s very fast.


Sent from my iPhone using Tapatalk

[MorenoAv]

2 hours ago, cankiulascmnfye said:

@MorenoAv Why are you using a patched DSDT by MaLDon?

It's a custom DSDT made for me by MaLDon...

Edited June 26, 2023 by MorenoAv

[bisdak4920]

Old Haswell - no issues at all OC-094

 

[cankiulascmnfye]

7 hours ago, MorenoAv said:

It's a custom DSDT made for me by MaLDon...

 

Well, then you know now who to ask for for supoort…

[SavageAUS]

All of the lines in the attached image is why my Sonoma boots so slow every time on my dell laptop.
Lots of ALUC, methodsetclientdomain,registernotificationport, tx rx stuff.
Is this because of Broadcom or something else wrong in my settings?
Once it is booted it works perfectly besides wifi.



Sent from my iPhone using Tapatalk

[deeveedee]

32 minutes ago, SavageAUS said:

Is this because of Broadcom or something else wrong in my settings?

 

Should be extremely easy for you to isolate.  Do you know how to temporarily disable the Brcm kexts in your OC config.plist so that you can test?  Best to copy your EFI to a bootable USB stick and test mods on the USB EFI.

 

Without seeing your current EFI, there's nothing to do but guess.

Edited June 27, 2023 by deeveedee

[aben]

34 minutes ago, SavageAUS said:

All of the lines in the attached image is why my Sonoma boots so slow every time on my dell laptop.
Lots of ALUC, methodsetclientdomain,registernotificationport, tx rx stuff.
Is this because of Broadcom or something else wrong in my settings?
Once it is booted it works perfectly besides wifi.

The kernel is clearly stalling when attempting to initialize PXSX device, which is most likely your BCM4352 card. My best bet would be that you're loading AirportBrcmFixup.kext, (which is typically required for this Broadcom chipset); if so remove it, as this kext has NO support in Sonoma. If that doesn't help, then you'll probably have to disable the device (via device property or SSDT).

[deeveedee]

I didn't think there was anyone left in this thread who didn't already know this. 😂

 

See here.

Edited June 27, 2023 by deeveedee

[Cyberdevs]

1 hour ago, aben said:

The kernel is clearly stalling when attempting to initialize PXSX device, which is most likely your BCM4352 card. My best bet would be that you're loading AirportBrcmFixup.kext, (which is typically required for this Broadcom chipset); if so remove it, as this kext has NO support in Sonoma. If that doesn't help, then you'll probably have to disable the device (via device property or SSDT).

Yep you're right on the money, in many cases disabling or removing the AiportBrcmFixup.kext will suffice there's no need to disable the device in device properties, removing it will fix the stalling issue.

 

P.S.

One issue that I can't figure out is when I use SSDT for WiFi it doesn't change the device properties, I need to add the device properties via config to override the settings.

[cankiulascmnfye]

@SavageAUS Just change MaxKernel for AirportBrcmFixup to 22.9.9 so it doesn't load in Sonoma.

Edited June 27, 2023 by cankiulascmnfye

[Cyberdevs]

I checked a 2020 iMac today and even on Big Sur it uses two different kexts for WiFi:

1. AppleBCMWLANBusInterfacePCIeMac.kext

2. AppleBCMWLANCoreMac.kext

The compatible WiFi's Device IDs are: pci14e4,4464 and pci14e4,43dc so in my opinion AirPortBrcmNIC.kext doesn't need to be injected we need to find a way to add the Device ID 14e4:43a0 to AppleBCMWLANBusInterfacePCIeMac.kext somehow.

 

Any ideas?

[cankiulascmnfye]

In the meantime, I actually contacted Fenvi and asked if they had any products with BCM4355, BCM4364, BCM4377b chipsets. Sometimes it's all about creating demand…

[deeveedee]

2 hours ago, Cyberdevs said:

One issue that I can't figure out is when I use SSDT for WiFi it doesn't change the device properties, I need to add the device properties via config to override the settings.

 

It's usually the other way around - if properties already exist or the ACPI object is not named, OC may not be able to change the property via config.plist.  As far as I know, you should always be able to change / add properties with SSDT, as long as your SSDT scope is correct.

 

See this response from Vit9696.

 

EDIT: The failure of the SSDT to add/modify properties is frequently because there is a config.plist patch or a kext that is renaming the ACPI object BEFORE your SSDT add/modifies the property.  For example, if you use AirportBrcmFixup.kext, it renames PXSX to ARPT.  If you have an SSDT that references PXSX, it won't find the device (because it is renamed).

 

Conversely, if your SSDT references ARPT and your don't rename PXSX to ARPT (e.g., you disable AirportBrcmFixup.kext), your ACPI patch won't find the ARPT object (because it is PXSX).

Edited June 27, 2023 by deeveedee

[cankiulascmnfye]

@Cyberdevs Utilizing the new IO80211Family kext seems to be difficult because of the Skylake stack which handles the packages. The dev of the AiportItlwm is struggling with this as well: https://github.com/OpenIntelWireless/itlwm/issues/883

[deeveedee]

2 minutes ago, cankiulascmnfye said:

Utilizing the new IO80211Family kext seems to be difficult because of the Skylake stack which handles the packages. The dev of the AiportItlwm is struggling with this as well: https://github.com/OpenIntelWireless/itlwm/issues/883

zxystd knows his $H%#.  Impressive.

Edited June 27, 2023 by deeveedee

[Cyberdevs]

40 minutes ago, deeveedee said:

It's usually the other way around - if properties already exist or the ACPI object is not named, OC may not be able to change the property via config.plist.  As far as I know, you should always be able to change / add properties with SSDT, as long as your SSDT scope is correct.

Yeah I know that but it doesn't seem to work properly.

 

12 minutes ago, cankiulascmnfye said:

@Cyberdevs Utilizing the new IO80211Family kext seems to be difficult because of the Skylake stack which handles the packages. The dev of the AiportItlwm is struggling with this as well: https://github.com/OpenIntelWireless/itlwm/issues/883

Well I just thought that might be possible to inject the device ID the kexts I mentioned but that might not even work because there are tons of differences between those chipsets and the kexts they need to operate.

[deeveedee]

2 minutes ago, Cyberdevs said:

Yeah I know that but it doesn't seem to work properly.

It's really the only probably cause, so if you post your EFI with the non-working SSDT, we can take a look and debug it.