Contribute
Register

Fenvi T919 wifi back in Sonoma with OCLP

I'm stuck with this card, its format fits on my motherboard
If needed you can always use a PCIe adapter, not a M.2 slot on your motherboard...
 
Running the AMFIPass.kext solution with the -amfipassbeta boot arg and get around 700-750 megabit (same as Ventura)

The trick for me was replacing the antennas on the Fenvi with 2 of these a few years ago (see attached pic). Bluetooth and wifi have been working amazing with these mounted behind my desk. No performance loss on Sonoma with OCLP and no app issues using the kext/ boot argument.

IMG_2181.png
 
Hello,
I tried severals methods (ie, with amfi-0x80 or amphi-0x80) or without but AMFIpasskext & boot args, then OCLP 0,6,9 -- I could reach wifi but after wake from sleep I got glitches on screen . And after reboot , unable to boot again. So I played with all kexts , deleting, but each time crash and reboot ==I got help from esafeddie and Miliuco, tried to compare config plist and add through BBedit the missing line. Here is the result:

Best regards
 

Attachments

  • config.plist
    42 KB · Views: 29
@frontgear

My thread is regarding Fenvi cards, these don’t need any other kexts but IOSkywalk.kext, IO80211FamilyLegacy.kext, and AirPortBrcmNIC.kext.
Other chipsets may need also AirportBrcmFixup.kext. But not the Fenvi.

I haven’t noticed degraded speed in the wifi when using AMFIPass and -amfipassbeta.
Mine is an Apple-made BCM94360CD (same as Fenvi t919, I believe) and I am also not using the other AirportBrcmFixup.kext + plugin. Great speed but Bluetooth seems to be lagging a bit when using Photoshop (or maybe just my imagination lol).
 
If I can say, I just opened OCLP (latest Nightly build) and the app recommended to update to 1.0.0 which I did do.
I left all the boot-args in place and SIP disabled as before, rebooted, cleaned NvRAM and all seems to function as before in relation to enabling my Fenvi-T919 Card.

I haven't done any test by removing the boot-args or enabling SIP to see the effect. I think I will wait any instructions from the developers on that score before I screw things up.
I got the recommended update notice, too, and after I accepted it I now see a new folder "Dortania" in the Application Support folder of my (main, root-level) Library. It contains the new OCLP 1.0 app.

As an aside, though: all this NvRAM cleaning that's advised for this procedure... can repeatedly cleaning NvRAM eventually affect BIOS settings? Specifically, my ROG Maximus XIII Hero has those RGB LED lights and I used to be able to have them turn off at shutdown using a "Stealth Mode" option in BIOS. After tinkering to get my Fenvi working again, and resetting NvRAM after each attempt until it finally succeeded, those lights are back on after every shutdown, requiring me to turn off the power switch in back. (It's a minor inconvenience but just thought I'd ask, LOL).
 
As an aside, though: all this NvRAM cleaning that's advised for this procedure... can repeatedly cleaning NvRAM eventually affect BIOS settings?
I don't see why cleaning NvRAM would alter your RGB lights setup. There has to be another reason, I know some Motherboards has a setting in the BIOS to alter how the RGB operates.

For example on my old Gigabyte Z390 you could have the lights go off in Sleep Mode and come back on in Wake.
On my current MSI Z490 this setting is also there.

I would advise to have a look again in the BIOS for the problem, in my Board the operation is under an obscure name and Menu, the only clue was the mention of RGB blah, blah, blah.
 
I got the recommended update notice, too, and after I accepted it I now see a new folder "Dortania" in the Application Support folder of my (main, root-level) Library. It contains the new OCLP 1.0 app.
This /Library/Application Support/Dortania folder was already here in the past OCLP versions. Main difference in 1.0.0 is that OCLP app is in that folder and there is an alias in /Applications (before there was 2 OCLP apps, one on each side).
 
I don't see why cleaning NvRAM would alter your RGB lights setup. There has to be another reason, I know some Motherboards has a setting in the BIOS to alter how the RGB operates.

For example on my old Gigabyte Z390 you could have the lights go off in Sleep Mode and come back on in Wake.
On my current MSI Z490 this setting is also there.

I would advise to have a look again in the BIOS for the problem, in my Board the operation is under an obscure name and Menu, the only clue was the mention of RGB blah, blah, blah.
Thx for the suggestion.. back in May before I updated my BIOS I took pictures of all important screens in it. RGB lights in my Hack were behaving themselves then. After updating to Sonoma last week I reviewed those pictures against my current BIOS and didn't see any setting that had changed, but I can check again later today.
 
Back
Top