Jump to content

Airport - PCIe Half Mini

toleda

By toleda,
in LAN and Wireless

 Share
826 posts in this topic

Recommended Posts

RehabMan
RehabMan
Posted
Posted

This is all very interesting.  I got the DSDT patch from OldNapalm which I originally used for an Atheros wifi card.  Here is the link:

 

http://www.insanelymac.com/forum/topic/289824-atheros-9285/

 

When I got my Azurewave AW-CE123H, I just changed the PID/VID.

 

My DSDT doesn't actually say that the device id is 0x2A, 0x00, 0x00, 0x00, even if that's what it translates to.  Mine says this:

              "device-id",
              Unicode ("*"),

 

It is because you're using a different version of iasl than I am.

Unicode "*" is 0x2a.

I use one (see my github) that doesn't do these stupid conversions to Unicode for short Buffer objects.

 

Now, just for my own education, is there a reason that it is better to use the two additional kexts (FakePCIID.kext and the Broadcom kext) rather than the 3 additional (PCI Error) kext patches?

The PCI error patches are patching for your mistake in spoofing the wrong PCI device-id.

For this hardware, no spoof is needed.

Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted

It is because you're using a different version of iasl than I am.

Unicode "*" is 0x2a.

I use one (see my github) that doesn't do these stupid conversions to Unicode for short Buffer objects.

 

 

The PCI error patches are patching for your mistake in spoofing the wrong PCI device-id.

For this hardware, no spoof is needed.

 

Thanks.  Always a pleasure to learn more from you about my hack.  I'm using your method and it works very well.

Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted

The PCI error patches are patching for your mistake in spoofing the wrong PCI device-id.

For this hardware, no spoof is needed.

 

I have been giving your answer regarding the PCI Error patches some additional thought and I think we (or I) may be missing something.  The reason I tried using the FakePCIID.kext is that, when running 10.12.1 and above, Clover kext patches were unable to make WiFi work and, for most of us, the wireless device could not be recognized.  The problem, I believed, was that the Clover patches could not inject the wireless device's PCI device ID in order to have the device recognized.  These patches appear to spoof the device ID in order to allow it to be injected into the Brcm4360 kext in order for the WiFi device to be recognized and to function.  

 

It does not detract from the kexts you have made to have another method to make WiFi work in Sierra.  Once I deleted the incorrect device-id from my DSDT, my wireless card should not have needed a patch to spoof the correct device ID.  Yet, these kext patches appear to inject whatever information is necessary to make the Brcm4360 kext work.  

 

If, instead of deleting the incorrect device-id from my DSDT and instead added the correct device-id, would the WiFi patches from 10.12.0 or earlier work without either your kexts or the PCI Error patches?  What am I missing?  What's wrong with these patches, if anything?

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I have been giving your answer regarding the PCI Error patches some additional thought and I think we (or I) may be missing something.

I'm definitely not missing anything.

 

The reason I tried using the FakePCIID.kext is that, when running 10.12.1 and above, Clover kext patches were unable to make WiFi work and,

I don't use Clover for WiFi. It does the wrong thing.

 

fThe problem, I believed, was that the Clover patches could not inject the wireless device's PCI device ID in order to have the device recognized.

No. Problem is Clover injects the wrong properties.

 

These patches appear to spoof the device ID in order to allow it to be injected into the Brcm4360 kext in order for the WiFi device to be recognized and to function.

Injecting the device-id is a mistake.

As toleda already said, you only need to inject "compatible".

Injecting a non-native device-id + using FakePCIID kexts really messes things up (because FakePCIID also spoofs at the IOPCIDevice level).

 

 

It does not detract from the kexts you have made to have another method to make WiFi work in Sierra.  Once I deleted the incorrect device-id from my DSDT, my wireless card should not have needed a patch to spoof the correct device ID.

Spoofing the device-id is not necessary.

FakePCIID spoofs only the subvendor and subdevice IDs, which are required for Airport Extreme branding without Clover patch for the same.

 

Yet, these kext patches appear to inject whatever information is necessary to make the Brcm4360 kext work.

FakePCIID_Broadcom_WiFi.kext/Contents/Info.plist has an IOKitPersonality to wire the native BCM94352 device-id to AirPortBrcm4360, such that even "compatible" injection (of non-native ID) is not needed.

 

If, instead of deleting the incorrect device-id from my DSDT and instead added the correct device-id, would the WiFi patches from 10.12.0 or earlier work without either your kexts or the PCI Error patches?  What am I missing?  What's wrong with these patches, if anything?

I don't know what you mean by "WiFi patches from 10.12.0 or earlier".

There is no need to inject a device-id property at all (fake or native). Injecting the native device-id is a no-op, therefore nonsense.

No idea what you mean by "these patches". If you're referring to the unnecessary "PCI Error" patches, they are only needed due to prior mistakes and are likely to need revising with each version/update. So: unneeded+fragile... I guess that's what's wrong with them.

Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted

I'm definitely not missing anything.

 

I don't use Clover for WiFi. It does the wrong thing.

 

No. Problem is Clover injects the wrong properties.

 

Injecting the device-id is a mistake.

As toleda already said, you only need to inject "compatible".

Injecting a non-native device-id + using FakePCIID kexts really messes things up (because FakePCIID also spoofs at the IOPCIDevice level).

 

Spoofing the device-id is not necessary.

FakePCIID spoofs only the subvendor and subdevice IDs, which are required for Airport Extreme branding without Clover patch for the same.

 

FakePCIID_Broadcom_WiFi.kext/Contents/Info.plist has an IOKitPersonality to wire the native BCM94352 device-id to AirPortBrcm4360, such that even "compatible" injection (of non-native ID) is not needed.

 

I don't know what you mean by "WiFi patches from 10.12.0 or earlier".

There is no need to inject a device-id property at all (fake or native). Injecting the native device-id is a no-op, therefore nonsense.

No idea what you mean by "these patches". If you're referring to the unnecessary "PCI Error" patches, they are only needed due to prior mistakes and are likely to need revising with each version/update. So: unneeded+fragile... I guess that's what's wrong with them.

 

I appreciate the time you put into responding to me and I understand that you don't or haven't used Clover kext patching for WiFi prior to 10.12.1.  Many of us, however, used the patches that were provided by Toleda (with the help of others) and they have worked well (perhaps not in your opinion) until 10.12.1.  Those were the patches I was referring to (other than the PCI Error patches.). I understand that only the compatible id's need to be injected.  That's why I didn't understand why it mattered that I had an incorrect (nonsense) device-id in my DSDT.  You told me above that this mistaken device-id prevented your kexts from working and caused the PCI Error patches to spoof the correct device ID for the erroneous one I had.  In my DSDT, I did have correct compatible ID's but they weren't being injected via Clover anymore.  However, the PCI Error patches did manage to inject the compatible ID's and I'm trying to figure out what's in those patches that make them inject the compatible ID's when the patches that Toleda has in his Github cannot do so in 10.12.1 and newer.  Maybe, because you don't like the Clover kext injection method, you're not the person to ask, and by all means your kexts do work for me and since they are only plists contained within kexts, they take up virtually no disk space in EFI and are therefore a good method.  Still, maybe someone knows or can figure out why Clover injection works with the PCI Error kext patches when used in addition to the prior kext patches.  There must be some type of hardware checking process that is new in 10.12.1 that is being bypassed or spoofed by these PCI Error patches.  I sure wish I knew who came up with them.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Many of us, however, used the patches that were provided by Toleda (with the help of others)

Still no idea which toleda patches you're referring to. You should probably be more specific.

 

and they have worked well (perhaps not in your opinion) until 10.12.1.

There were changes in the native WiFi kexts that exposed errors both in FakePCIID and in typical patches people would use.

 

You told me above that this mistaken device-id prevented your kexts from working

The FakePCIID kexts were working perfectly... doing exactly what they are designed to do... (spoofing returns from IOPCIDevice based on ioreg input).

 

and caused the PCI Error patches to spoof the correct device ID for the erroneous one I had.

No. The PCI error patches patch the native WiFi kexts such that they ignore the PCI inconsistencies.

 

 In my DSDT, I did have correct compatible ID's but they weren't being injected via Clover anymore.

Clover is not involved in the code you place in your DSDT. Your DSDT was working just fine... injecting the IDs you provided. Problem is the IDs were wrong. And not needed anyway.

 

However, the PCI Error patches did manage to inject the compatible ID's

The PCI Error patches did not inject anything. They simply nullified the new checks being made for inconsistent/wrong data.

 

Still, maybe someone knows or can figure out why Clover injection works with the PCI Error kext patches when used in addition to the prior kext patches.

Clover WiFi injection could be corrected simply by removing the injection of device-id.

It would be a trivial change to Clover source.

Link to comment
Share on other sites
toleda
toleda
Posted
  • Author
Posted

the PCI Error patches did manage to inject the compatible ID's and I'm trying to figure out what's in those patches that make them inject the compatible ID's when the patches that Toleda has in his Github cannot do so in 10.12.1 and newer. 

Not to pile on, rather to clarify.  My 4352s (posted ssdt and patches) has worked after every release since 10.10.2; no 10.12.1 problems.

1. The "author" of the "PCI error" patches did not have a genuine BCM94352 device; disabled enough validation code in the kext and got his copy cat "4352" to work. Simply, an illegitimate experiment, a bad idea and an invalid solution.

2. Post #1 shows five techniques to enable macOS WIFi and specifically the 94352. Only those 10.12.1 update users; a. enabling Clover/ACPI/DSDT/Fixes/FixAirport got a KP on boot or b. with an older version of FakePCIID/FakePCIID_Broadcom_WiFi booted to the "no hardware detected" error.  

 

The posted fix at the time was to use one of the other 3 techniques to enable 4352 WiFi.  FixAirport renames PXSX device to ARPT causing compiler errors producing a KP and cannot be enabled in 10.12.1 or newer. With the current FakePCIID/FakePCIID_Broadcom_WiFi kexts, 4 techniques enable 4352 WiFi. Note, no change was made to any dsdt/ssdt or patch before or after the release of 10.12.1 (a Clover Info.plist patch was added).

 

Clover/FixAirport was the only 10.12.1 casualty 

All Post #1 BCM94352 techniques (except Clover/FixAirport) and patches have been and remain valid for 10.10, 10.11 and 10.12.

Link to comment
Share on other sites
Scimiazzurro
Scimiazzurro
Posted
Posted

Hi,

 

I have a Gigabyte GC-WB867D-I card in my PC which simply is a Half Mini PCI-e to PCIe adapter (that adapts a combined Wifi+BT Intel card, the typical card we could find in notebooks).

 

Anyway, I'm now thinking to replace the Intel WiFi+BT card in the Gigabyte adapter with one compatible with OSX (possibly Sierra), can you advice me on which WiFi+BT card is better, and possibly works Out of the box? (and if it could support Handoff)

Link to comment
Share on other sites
toleda
toleda
Posted
  • Author
Posted

What could happen if I insert an Airport in that PCIe adapter?

 

Another thing, this Airport from a MacBook Air could work natively with an adapter?

Wifi would work if supported and enabled. BT would not show.

Adapter must support USB.  Mini PCIe connectors support USB, PCIe connectors do not.

Link to comment
Share on other sites
llamafilm
llamafilm
Posted
Posted

On github, RehabMan says that BrcmFirmwareRepo is preferred over BrcmFirmwareData. Is that still true, and how much of a difference does it make? I just like having a clean /S/L/E. So far, I haven't noticed any problems with BrcmFirmwareData in my EFI folder.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

On github, RehabMan says that BrcmFirmwareRepo is preferred over BrcmFirmwareData. Is that still true, and how much of a difference does it make? I just like having a clean /S/L/E. So far, I haven't noticed any problems with BrcmFirmwareData in my EFI folder.

As per github README, BrcmFirmwareRepo is preferred as it is much more memory efficient.

 

With BrcmFirmwareData.kext, all firmwares for all devices are loaded into memory.

With BrcmFirmwareRepo.kext, only the firmware required for the devices present in the computer (usually only one) are loaded into memory.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Ah I see.  So all the firmwares together are how big, maybe 5MB?  If you have many GB of RAM, then I guess it doesn't matter much.  Does it have any effect on boot time?

Single firmware: 6 KB to 43 KB, avg ~30 KB.

All firmwares: 2.6 MB.

 

BrcmFirmwareData.kext uses more memory than BrcmFirmwareRepo.kext by a factor of ~88.

 

Whether that is important to you, is personal choice, and probably depends on your perspective.

Link to comment
Share on other sites
toleda
toleda
Posted
  • Author
Posted

is there any driver working for Windows 10? I found only working driver for Bluetooth, but not for the Wifi part.

This thread supports maxOS only

 

Did I need any kext? My card is BCM94331C

Depends on the device-id, see Post #1

  • Like 1
Link to comment
Share on other sites
  • 1 month later...
filequit
filequit
Posted
Posted

Hi - 

 

I have a DW1830 (which is a broadcom 4360) m.2 wifi card in my Dell xps 9350 and it appears when I try to connect to 80mhz-wide 5ghz networks in 10.12, i only get 30-40mbit downstream, with normal upstream speeds. If I set my router to 40mhz wide channels, i get around 250mbit download throughput. Other users are also experiencing the same symptoms, on syscl's 9350 github issues page (https://github.com/syscl/XPS9350-macOS)  . Ive included a zip of all the files requested for problem reporting. Appreciate any assistance you may be able to provide. 

wifi troubleshooting.zip

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