Jump to content

[pre-release] macOS Sonoma


1,844 posts in this topic

Recommended Posts

1 hour ago, draylax said:

Ah this ought to be a sticky thread, it’s a query that’s going to be repeatedly asked from now on, that and the question of Airdrop with existing still working BT Broadcom we already have on the M.2 module boards.

Where are these “6 adapters” listed? They’re not on this Sonoma 14 page link.

Its not 6 its 7 And all 7 adapter works in Sonoma 14

Spoiler

image.jpeg

 

 

  • Like 2
Link to comment
Share on other sites

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 😂

  • Like 1
  • Haha 1
Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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 by MorenoAv
Link to comment
Share on other sites

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

  • Like 5
  • Haha 2
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

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.
38d5a8cc66901b1899f7f6230196e27e.jpg


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

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 by deeveedee
Link to comment
Share on other sites

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).

  • Like 6
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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?

  • Like 5
  • Confused 1
Link to comment
Share on other sites

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).

1643820896_Screenshot2023-06-27at1_28_11PM.png.eee74f10e88ad244c1656cacd6e32cc7.png

 

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 by deeveedee
  • Like 6
Link to comment
Share on other sites

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 by deeveedee
  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...