Jump to content

[pre-release] macOS Sonoma

fantomas

By fantomas,
in New Releases and Updates

 Share
1,844 posts in this topic

Recommended Posts

aben
aben
Posted
Posted
23 hours ago, miliuco said:

WhateverGreen developers instructions:

 

Note that this alternative fix is only available for users who have laptops using Coffee Lake's graphics driver and running macOS 13.4 or later. You can add the property `enable-backlight-registers-alternative-fix` to `IGPU` or use the boot argument `-igfxblt` to enable this new fix and remove the boot argument `-igfxbls` and/or the device property `enable-backlight-registers-fix`. If you wish to use the Backlight Smoother on macOS 13.4 or later, you need to add both `-igfxblt` and `-igfxbrs` to the boot arguments.


This section of the documentation from WEG manual covering the use of new blacklight submodule BLT (for Coffee Lake/Whiskey Lake laptop users affected by the 3-minute backlight delay on 13.4 and Sonoma Beta 1), actually has a couple of critical typos around the usage of the relevant boot-arguments. The correct description should be:

"You can add the property `enable-backlight-registers-alternative-fix` to `IGPU` or use the boot argument `-igfxblt` to enable this new fix and remove the boot argument `-igfxblr` and/or the device property `enable-backlight-registers-fix`. If you wish to use the Backlight Smoother on macOS 13.4 or later, you need to add both `-igfxblt` and `-igfxbls` to the boot arguments."

A PR correcting this info has been submitted (by myself and approved by the developer), which should be merged to WEG master branch shortly.  More details here: https://github.com/acidanthera/WhateverGreen/pull/115

  • Like 2
Link to comment
Share on other sites
nyu1985
nyu1985
Posted
Posted (edited)
5 hours ago, DrThodt said:

yes sorry bcm4364 but still 14e4:07bf

 

edit: maybe it is 4464 and I read the dump wrong

14e4:07bf is sub system info of bcm4464 I guess.

Edited by nyu1985
Link to comment
Share on other sites
Stefanalmare
Stefanalmare
Posted
Posted (edited)
7 hours ago, aben said:


This section of the documentation from WEG manual covering the use of new blacklight submodule BLT (for Coffee Lake/Whiskey Lake laptop users affected by the 3-minute backlight delay on 13.4 and Sonoma Beta 1), actually has a couple of critical typos around the usage of the relevant boot-arguments. The correct description should be:

"You can add the property `enable-backlight-registers-alternative-fix` to `IGPU` or use the boot argument `-igfxblt` to enable this new fix and remove the boot argument `-igfxblr` and/or the device property `enable-backlight-registers-fix`. If you wish to use the Backlight Smoother on macOS 13.4 or later, you need to add both `-igfxblt` and `-igfxbls` to the boot arguments."

A PR correcting this info has been submitted (by myself and approved by the developer), which should be merged to WEG master branch shortly.  More details here: https://github.com/acidanthera/WhateverGreen/pull/115

 

I have a feeling that this is was during the test period. Vit said that it rest not so much space for args and at the final -igfxblt have duble function. At least this is was what I understood. I may be wrong.

 

1.png

Edited by Stefanalmare
  • Like 1
Link to comment
Share on other sites
DrThodt
DrThodt
Posted
Posted
40 minutes ago, Stefanalmare said:

MacBookPro15,1, BCM4364.

 

 

  Reveal hidden contents

1.png

 

 

  Reveal hidden contents

2.png

 

 

  Reveal hidden contents

3.png

 

 

i wonder if it needs to be done similar to thunderbolt. map and name the pci device and load the apple firmware. im assuming it cant be much different from say the fenvi model

Link to comment
Share on other sites
aben
aben
Posted
Posted
24 minutes ago, Stefanalmare said:

I have a feeling that this is was during the test period. Vit said that it rest not so much space for args and at the final -igfxblt have duble function. At least this is was what I understood. I may be wrong.


Slightly OT here, but the initially proposed submodule BRS (-igfxbrs) ended up getting deprecated (following Vit’s automation idea) but these boot-argument typos looks more like a simple oversight while composing the docs, as the CN docs didn’t have the same errors (and this was further acknowledged by the developer)

 

(In any case, ‘-igfxbls’ has nothing to do with ‘enable-backlight-registers-fix’ property AND “-igfxbrs” has nothing to do with ‘-igfxblt’)

Link to comment
Share on other sites
Henties
Henties
Posted
Posted (edited)

Initially I did not intent to start as early as this with "beta testing" Sonoma. I could nevertheless not resist the challenge. Consequently I rolled up my sleeves and installed Sonoma 14.0  (23A5257q) on both of my GA-7490-Vision G mobos, with each installation being placed into a shared APFS container with adequate free storage space available.

 

I first duplicated my fully functioning Ventura 13.4 volume into the selected container and subsequently upgraded that duplicated Ventura volume to the latest available 13.03 gig. Sonoma dev. beta iteration via the appropriate System Setting section.

 

Following the completed download it surprisingly appeared as a "visible app", in the Application folder as "Install macOS 14 beta", which I then copied to free space so as to preempt the need for another download of this size, which was required for my other GA-7490-Vision G hack .

 

In the interim I also created a properly working Sonoma install USB via the usual macOS terminal command, adapted to the string reflected below:

 

sudo /Applications/Install\ macOS\ 14\ beta.app/Contents/Resources/createinstallmedia --volume /Volumes/USB /Applications/Install\ macOS\ 14\ beta.app --nointeraction

 

The actual installation was performed under control of OC 0.9.2 using the image in the Application folder, and concluded without any hitches whatsoever.

 

Before starting the installation I added the boot arg -lilubetaall to the respective NVRAM section as well as limiting the loading of the NVMeFix.kext with the MaxKernel parameter of 22.6.0

 

Subsequently I conducted some tests and discovered the following software still requiring attention by the respective vendors in order to work properly under Sodoma:

Airfoil

Airfoil Satellite

Audacity

Audio Hijack

Carbon Copy Cloner

Little Snitch

SoundSource

Xcode

Using Fenvi T919 Wifi/BT pcie cards throughout with WiFI now broken, as with every other user using this card, but its BT functionality is still working very well. 

 

Both of my GA-Z490-G hacks now run the following operating systems seamlessly and without any issues under control of only one EFI incarnation:

 

Big Sur 11.7.7  Release (20G1345)

Monterey 12.6.6  Release  (21G646)

Ventura 13.4 Release  (22F66)  APFS

Sonoma 14.0 Beta 2  (23G52357q)  APFS

Windows 10 Enterprise

Windows 10 Professional

Linux -Ubuntu 20.04 LTE

 

Hoping that this information may be useful to other board members using Z490 based mobos.

 

Greetings Henties 

Edited by Henties
  • Like 4
Link to comment
Share on other sites
aben
aben
Posted
Posted
2 hours ago, DrThodt said:

 

i wonder if it needs to be done similar to thunderbolt. map and name the pci device and load the apple firmware. im assuming it cant be much different from say the fenvi model


Hi - things don't always work this way in macOS; these are entirely different generations of Broadcom chipsets built around newer technologies/capabilities specifically designed to work with newer proprietary Broadcom drivers built in-house by Apple. There's good reason why hardware gets classified as "legacy", one cannot simply expect say an Intel HD 4000 iGPU to auto-magically work with Skylake drivers just by simply spoofing the device-id and such. Restoring support for legacy hardware in macOS is no easy task; its much more complex than you can imagine, and that's precisely why aspiring projects like OCLP come into play.

  • Like 1
Link to comment
Share on other sites
miliuco
miliuco
Posted
Posted
47 minutes ago, deeveedee said:

The OCLP Devs progress on Wi-Fi patching looks very promising.

Yes, it's amazing how they work finding fixes for issues.

You and others are used to using OCLP in your Hacks so you already have this advantage.

Those of us who have more modern hardware and have never needed OCLP are going to have to learn this other way of doing things. It is true that OCLP has reached an enviable ease of use and I think they will learn quickly.

I only use it on Mac and follow its development with great interest. Anyway, I hope to have wifi and Continuity + Airdrop in the next few weeks.

  • Like 3
Link to comment
Share on other sites
DrThodt
DrThodt
Posted
Posted
40 minutes ago, aben said:


Hi - things don't always work this way in macOS; these are entirely different generations of Broadcom chipsets built around newer technologies/capabilities specifically designed to work with newer proprietary Broadcom drivers built in-house by Apple. There's good reason why hardware gets classified as "legacy", one cannot simply expect say an Intel HD 4000 iGPU to auto-magically work with Skylake drivers just by simply spoofing the device-id and such. Restoring support for legacy hardware in macOS is no easy task; its much more complex than you can imagine, and that's precisely why aspiring projects like OCLP come into play.

 

sure but without stable continuity theres no point in desktop wifi imo. so I’m debating on staying Ventura or just pulling out the card

  • Like 1
Link to comment
Share on other sites
PoMpIs
PoMpIs
Posted
Posted
15 minutes ago, DrThodt said:

 

sure but without stable continuity theres no point in desktop wifi imo. so I’m debating on staying Ventura or just pulling out the card

 

In the i3 6100 I have already taken out the Fenvi-clone... I have passed a network cable and that's it...

 

In the 13600k I have always had it connected by network cable, I replaced the intel wifi that I had on the board with the broadcom 4360 just for Airdrop... without airdrop I will remove it and put back the one that came with the motherboard...

 

In the laptops, which would not need OCLP except for Wi-Fi, I would probably remove the 4360 and put the Intel Wi-Fi... I prefer not to have to deactivate SIP... I already did that in the Lenovo T430 Ivy-bridge because I don't there was another way to make the HD4000 work ..... and in the end I stopped using it with MacOS

  • Like 2
Link to comment
Share on other sites
miliuco
miliuco
Posted
Posted

@SavageAUS

Don't worry if you never used OCLP. It's easy to learn how to do in the Hack. 

If the solution to the wifi comes this way, it will not be too complicated to use OCLP for it, there will be instructions of course but in short it boils down to continuing with your OpenCore EFI adding patches to config.plist (taken from OCLP config.plist).

Or maybe some kext that they modify or develop from scratch or some patch that will have to be applied to our system directly from the OCLP app.
A possible drawback is that the patches that OCLP applies usually require doing it as root modifying parts of the system which might lead us to work with SIP partially disabled or even SecureBootModel disable but we'll see, I won't get ahead of myself.

Without forgetting that the solution to Wi-Fi can also come via OpenCore or from a developer who publishes another fix in the form of a kext or patch.

  • Like 3
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
On 6/9/2023 at 11:45 AM, PMheart said:

Hopefully this works for you: https://github.com/zxystd/BrcmPatchRAM/commit/300581de4a2474370f7dd44c93ade59960e7e2a1

I thought I would be able to inspect the BrcmPatchRAM commits to determine for myself, but my github skills are lacking.  Is this branch/fork now part of the Acidanthera BrcmPatchRAM build?  Thank you.

Edited by deeveedee
Link to comment
Share on other sites
MorenoAv
MorenoAv
Posted
Posted (edited)

Hi guys,

i was out for a few days and I can't install macOS Sonoma, with -lilubetaall because at some point I have black screen, with the hack in my signature.

What boot arguments are needed to prevent black screen?

Thanks

 

Edited by MorenoAv
Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted
4 minutes ago, MorenoAv said:

Hi guys,

i was out for a few days and I can't install macOS Sonoma, with -lilubetaall because at some point I have black screen, with the hack in my signature.

What boot arguments are needed to prevent black screen?

Thanks

If you update the kexts to the latest development version you won't need any boot arguments.

Use OCAT to update OC and kexts (select Dev checkbox for kexts) 

  • Like 3
  • Thanks 2
Link to comment
Share on other sites
meg2014
meg2014
Posted
Posted
1 hour ago, Cyberdevs said:

If you update the kexts to the latest development version you won't need any boot arguments.

Use OCAT to update OC and kexts (select Dev checkbox for kexts) 

 

Does that include the latest BrcmPatchRAM patch for Wifi in Sonoma?  Seems a bit early for that to be included....

Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted
Just now, meg2014 said:

 

Does that include the latest BrcmPatchRAM patch for Wifi in Sonoma?  Seems a bit early for that to be included....

No, it won't work. Wireless adapters (with native apple support) are not working right now.

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
2 hours ago, MorenoAv said:

Hi guys,

i was out for a few days and I can't install macOS Sonoma, with -lilubetaall because at some point I have black screen, with the hack in my signature.

What boot arguments are needed to prevent black screen?

Thanks

 

Black screen with RX570??? It works OOB in Sonoma. Just let it to work. Delete WhateverGreen and all bootargs for it.

Choose SMBIOS model with Polaris card, for example iMac19,1.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...