Jump to content

BCM5722, BCM5754/M, BCM5755/M, BCM5787/M and BCM5906/M NIC driver (32/64-bit)

adlan

By adlan,
in LAN and Wireless

 Share
251 posts in this topic

Recommended Posts

LatinMcG
LatinMcG
Posted
Posted

ill give it a shot and post it here for snow when i do.

its for my boss.. he bought an old M1710 and i got it working sweet. sleep wake and all working.. but display sleep wakes with gray lines screen but system sleep fixes it (close lid.. open it).

 

havent tested 2.3.4 i386 snow yet after sleep, using wifi mostly

 

after playing with it a little i finally compiled my first. ill see if it works and post it.

thanks

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

Hi Alex,

 

Per our discussion in the BMC57781 thread, here is the info you requested.

 

a. I '-' then '+' the Ethernet and unplugged/replugged back in the cable.  No luck.

b. The Ethernet is recognized, but it self assigns an IP.. if I force an IP, and set the dns, router, etc.. it won't connect.

 

Console Log:
8/18/13 12:29:23.000 PM kernel[0]: BCM5722D (Build date/time: Jun 24 2013 12:20:29)
8/18/13 12:29:23.000 PM kernel[0]: my_name_adlan_BCM5722D: Model: BCM57781 NetLink (TM) Gigabit Ethernet
8/18/13 12:29:23.000 PM kernel[0]: my_name_adlan_BCM5722D: Loaded successfully
8/18/13 12:29:29.000 PM kernel[0]: my_name_adlan_BCM5722D: Link up: 1000 MBps, full duplex. Flow control: symmetric
System Info:
ethernet:

  Type:	Ethernet Controller
  Bus:	PCI
  Vendor ID:	0x14e4
  Device ID:	0x16b1
  Subsystem Vendor ID:	0x1849
  Subsystem ID:	0x96b1
  Revision ID:	0x0010
  Link Width:	x1
  BSD name:	en0
  Kext name:	BCM5722D.kext
  Location:	/System/Library/Extensions/BCM5722D.kext
  Version:	2.3.5

 

DarwinDumper_2.7.9_Chameleon_2.1_Mav_Jim.zip

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

 

Hi Alex,

 

Per our discussion in the BMC57781 thread, here is the info you requested.

 

a. I '-' then '+' the Ethernet and unplugged/replugged back in the cable.  No luck.

b. The Ethernet is recognized, but it self assigns an IP.. if I force an IP, and set the dns, router, etc.. it won't connect.

 

Console Log:
8/18/13 12:29:23.000 PM kernel[0]: BCM5722D (Build date/time: Jun 24 2013 12:20:29)
8/18/13 12:29:23.000 PM kernel[0]: my_name_adlan_BCM5722D: Model: BCM57781 NetLink (TM) Gigabit Ethernet
8/18/13 12:29:23.000 PM kernel[0]: my_name_adlan_BCM5722D: Loaded successfully
8/18/13 12:29:29.000 PM kernel[0]: my_name_adlan_BCM5722D: Link up: 1000 MBps, full duplex. Flow control: symmetric
System Info:
ethernet:

  Type:	Ethernet Controller
  Bus:	PCI
  Vendor ID:	0x14e4
  Device ID:	0x16b1
  Subsystem Vendor ID:	0x1849
  Subsystem ID:	0x96b1
  Revision ID:	0x0010
  Link Width:	x1
  BSD name:	en0
  Kext name:	BCM5722D.kext
  Location:	/System/Library/Extensions/BCM5722D.kext
  Version:	2.3.5

 

 

Configure the interface manually using a static address. Try to ping another machine in your LAN. On the remote machine (the one you are trying to send echo requests to) run Wireshark in order to check if the ICMP packets are actually transmitted by the local machine. On the local machine use Network Utility or netstat -I en0 to monitor the number of received packets. Using this method it should be possible to find out what exactly isn't working. Reception or transmission of packets?

 

Good luck!

 

Mieze

  • Like 1
Link to comment
Share on other sites
Buckeyes1995
Buckeyes1995
Posted
Posted

Here's the debug log.

8/18/13 2:47:00.242 PM com.apple.kextcache[397]: kext my.name.adlan.BCM5722D  203059000 is in exception list, allowing to load
8/18/13 2:47:46.000 PM kernel[0]: BCM5722D (Build date/time: Aug 18 2013 22:01:36)
8/18/13 2:47:46.000 PM kernel[0]: BCM5722D (resetAdapter:145): 4B657654 to B49A89AB in 928 iterations
8/18/13 2:47:46.000 PM kernel[0]: my_name_adlan_BCM5722D: Model: BCM57781 NetLink (TM) Gigabit Ethernet
8/18/13 2:47:46.000 PM kernel[0]: my_name_adlan_BCM5722D: Loaded successfully
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (resetAdapter:145): 4B657654 to B49A89AB in 12711 iterations
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (setMedium:356): Change medium: kIOMediumEthernetAuto
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (setMedium:381): Change medium: kLinkDuplexNegotiate
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (configureLinkAdvertisement:557): advertiseFe: 5E1
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (configureLinkAdvertisement:558): advertiseGe: 300
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (startAutoNegotiation:580): Adv reg: 5E1
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (setMedium:372): Change medium: kIOMediumEthernet1000BaseT
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (setMedium:381): Change medium: kLinkDuplexFull
8/18/13 2:47:48.000 PM kernel[0]: my_name_adlan_BCM5722D: Advertising with limited capability, speed: 1000 MBps, full duplex
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (configureLinkAdvertisement:557): advertiseFe: 401
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (configureLinkAdvertisement:558): advertiseGe: 200
8/18/13 2:47:48.000 PM kernel[0]: BCM5722D (startAutoNegotiation:580): Adv reg: 401
8/18/13 2:47:50.000 PM kernel[0]: BCM5722D (setupPHY:96): Auxillary status: FF3F
8/18/13 2:47:50.000 PM kernel[0]: BCM5722D (setupFlowControl:457): flowControl: 3
8/18/13 2:47:50.000 PM kernel[0]: my_name_adlan_BCM5722D: Link up: 1000 MBps, full duplex. Flow control: symmetric

I'll try what Mieze suggested (thanks for the help!).. I'll put wireshark on my Macbook Air and see if I can ping it.

 

When I tried to manually configure the on board ethernet it said it had an address but couldn't get to the internet.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

A few weeks ago I had an idea how to make Apple's Broadcom driver fit for use with the BCM57781 without binary patching the kext. Although I haven't tried myself I'm quite confident that this method will work. Here is a short outline of my idea:

 

The BCM57765 used in recent Macs and the BCM57781 are fully compatible with the exception that the BCM57765 also includes a card reader and has different device, subsystem and subsystem vendor IDs. While creating a binary patch for Apple's driver I discovered that the only thing that prevents the driver from working with the BCM57781 is the fact that the driver uses

 

 

configRead16

Reads a 16-bit value from the PCI device's configuration space.

virtual UInt16 configRead16( UInt8 offset );
Parameters offset

An 8-bit offset into configuration space, of which bit 0 is ignored.

Return Value

An 16-bit value in host byte order (big endian on PPC).

Discussion

This method reads a 16-bit configuration space register on the device and returns its value.

 

 

to check these PCI config registers and verifies the return value before accepting the device. Therefore I patched the driver to intercept these calls to configRead16() and injected the the matching return value. As binary patching will become more difficult with Mavericks I thought about alternate ways to achieve the same result. Here is what I found:

 

configRead16() is a system call that is provided by IOPCIFamily.kext which is open source so that it should be possible to make a modified version of that kext which detects the call, checks the return value the hardware provided and injects the required return value making the driver believe it is acting on a supported BCM57765 device.

 

As I already mentioned, I didn't try it myself, but might be worth to give it a shot.

 

Mieze

  • Like 1
Link to comment
Share on other sites
Buckeyes1995
Buckeyes1995
Posted
Posted

Hi mieze,

 

On the remote machine (running wireshark) there are no incoming ICMP packets.. there are some broadcast packets from the local machine.  When I switch back to wireless I see the ICMP packets just fine.

 

On the local machine (netstat) I saw 0 incoming packets only outgoing packets.

Link to comment
Share on other sites
Alex009988
Alex009988
Posted
Posted

A few weeks ago I had an idea how to make Apple's Broadcom driver fit for use with the BCM57781 without binary patching the kext. Although I haven't tried myself I'm quite confident that this method will work. Here is a short outline of my idea:

 

The BCM57765 used in recent Macs and the BCM57781 are fully compatible with the exception that the BCM57765 also includes a card reader and has different device, subsystem and subsystem vendor IDs. While creating a binary patch for Apple's driver I discovered that the only thing that prevents the driver from working with the BCM57781 is the fact that the driver uses

 

 

configRead16

Reads a 16-bit value from the PCI device's configuration space.

virtual UInt16 configRead16( UInt8 offset );

Parameters offset

An 8-bit offset into configuration space, of which bit 0 is ignored.

 

Return Value

An 16-bit value in host byte order (big endian on PPC).

 

Discussion

This method reads a 16-bit configuration space register on the device and returns its value.

 

 

 

to check these PCI config registers and verifies the return value before accepting the device. Therefore I patched the driver to intercept these calls to configRead16() and injected the the matching return value. As binary patching will become more difficult with Mavericks I thought about alternate ways to achieve the same result. Here is what I found:

 

configRead16() is a system call that is provided by IOPCIFamily.kext which is open source so that it should be possible to make a modified version of that kext which detects the call, checks the return value the hardware provided and injects the required return value making the driver believe it is acting on a supported BCM57765 device.

 

As I already mentioned, I didn't try it myself, but might be worth to give it a shot.

 

Mieze

Very promising idea I'm ready to be a tester. If they added a support it means the stopping-problems shouldn't exists at all as it were in the case of AppleBCM5701.

This driver even worse than the old version of BCM5722d. As it stopped working completely after sleep.

http://www.osx86.net/view/3089-broadcom_netlink_bcm57781.html

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Hi mieze,

 

On the remote machine (running wireshark) there are no incoming ICMP packets.. there are some broadcast packets from the local machine.  When I switch back to wireless I see the ICMP packets just fine.

 

On the local machine (netstat) I saw 0 incoming packets only outgoing packets.

 

Sounds strange. The fact that that there are at least some broadcast packets from the local machine indicates that transmission seems to work to some degree. I guess the broadcasts you received are ARP requests from the local machine asking for the mac address of the remote station? You might try to create a static ARP entry for the remote machine on the local machine using

arp -s ip-address mac-address 

in order to make the pings go out on the wire.

 

According to your results reception isn't working at all which prevents the interface from acquiring an IP address. I suggest to add some debug code to the receive handler routines so that we can see if they get called at all. If they get called, we would know that the receiver is configured correctly and could narrow down the point where reception fails. In case they don't get called we should check the receiver's configuration for that chip.

 

Mieze

Link to comment
Share on other sites
Buckeyes1995
Buckeyes1995
Posted
Posted

It appears as of the serviceRxInterrupt function is never getting called. 

 if (producerIdx != rxReturnConsumerIdx) {
        serviceRxInterrupt(producerIdx);
        DebugLog("JRR Interrupt Occured:  ServiceRxInterrupt!");
        BUMP_RXSTAT(interrupts);
    }

I also verified the kext is processing Tx requests.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

It appears as of the serviceRxInterrupt function is never getting called. 

 if (producerIdx != rxReturnConsumerIdx) {
        serviceRxInterrupt(producerIdx);
        DebugLog("JRR Interrupt Occured:  ServiceRxInterrupt!");
        BUMP_RXSTAT(interrupts);
    }

I also verified the kext is processing Tx requests.

 

Ok, this means that we have to check the receiver configuration for the BCM57781.

 

Mieze

Link to comment
Share on other sites
Buckeyes1995
Buckeyes1995
Posted
Posted

Ok, this means that we have to check the receiver configuration for the BCM57781.

 

Mieze

 

We're quickly approaching the bounds of my limited knowledge :)

 

I also grabbed the IOPCIFamily kext source, but am having a difficult time compiling it.  I'm not very famliar with XCode.. but was able to find several instances of the System call you referrred to.  It should be an easy change to make but I wasn't exactly sure what I was looking at (ie.. which call I wanted to muck with).

 

Thanks for the support!

Link to comment
Share on other sites
Alex009988
Alex009988
Posted
Posted

Mieze,

 

Do you have the source for the Apple driver? Need to know what its looking for back from the ConfigRead16 call.. then I should be able to override the return value in IOPCIFamily.kext (if I can ever get the damn thing to compile).

Try this driver just for the interest if it can work for you. It is better than nothing but have many bugs.

http://www.osx86.net/view/3089-broadcom_netlink_bcm57781.html

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Mieze,

 

Do you have the source for the Apple driver?  Need to know what its looking for back from the ConfigRead16 call.. then I should be able to override the return value in IOPCIFamily.kext (if I can ever get the damn thing to compile).

 

Hello Buckeyes1995,

 

first of all here is the modified implementation of the method UInt16 IOPCIDevice::configRead16( IOPCIAddressSpace _space, UInt8 offset ) from IOPCIDevice.cpp. All other implementations of configRead16() refer to it. I already filled in the return values that identify the BCM57765 in recent Macs. All you'll have to do is take a look at IORegistry and look up the corresponding values of your BCM57781 and replace XXXX, YYYY, ZZZZ with the values you found. The subsystem vendor ID is probably the ID of the board manufacturer. I don't know if it is necessary to modify the subsystem vendor ID as it might be already correct.

 

Please keep in mind that this is a quick and dirty implementation because it might affect other devices with the same IDs but different vendors. Well, I don't think there will be any problems but I can't rule it out.

UInt16 IOPCIDevice::configRead16( IOPCIAddressSpace _space,
                                  UInt8 offset )
{
    UInt16 value = parent->configRead16(_space, offset);
    
    switch (offset) {
        case kIOPCIConfigDeviceID:
            if (value == XXXX)
                value = 0x16b4; /* dev id of the BCM57765 */
            break;
            
        case kIOPCIConfigSubSystemVendorID:
            if (value == YYYY)
                value = 0x14e4; /* Broadcom's vendor id */
            break;
            
        case kIOPCIConfigSubSystemID:
            if (value == ZZZZ)
                value = 0x16b4; /* subsys id of the BCM57765 */
            break;
    }
    return (value);
}

In order to build the kext you'll need to remove the target "IOPCIFamily Headers" and switch the remaining targets to 64bit architecture. Only IOPCIFamily.kext is needed. The sample driver is superfluous. There still might be more build problems to resolve.

 

Good luck!

 

Mieze

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Thanks, not having much luck getting it to compile.   A lot of missing headers, etc.  Doesn't appear Apple has compiled this in a long time... 10.6.x from what I gather.

 

I will try it tomorrow too. At first glance it looks like there are some header files missing which we will have to import from the kernel source.

 

Mieze

Link to comment
Share on other sites
Buckeyes1995
Buckeyes1995
Posted
Posted

I will try it tomorrow too. At first glance it looks like there are some header files missing which we will have to import from the kernel source.

 

Mieze

Great. I'm going to be out of town all this week and will not have a chance to work on this until Saturday.  Let me know what you find if you have the time!  Appreciate the support.

Try this driver just for the interest if it can work for you. It is better than nothing but have many bugs.

http://www.osx86.net/view/3089-broadcom_netlink_bcm57781.html

Hey Alex.. That driver does not work on 10.9.  I had been using it on my 10.8.x. build, but it'

s broken for 10.9

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Hi Mieze, any luck this week?

 

Are the header files available from opensource.apple.com?

Unfortunately I failed to build the kext too and gave up after 4h due to lack of of time. I found the missing header files in the 10.8.4 kernel source but with importing those files I also imported new errors. 

 

A few month ago I created a binary patch for Apple's 10.8.3 Broadcom driver and as far as I know they haven't changed the network drivers in 10.8.4 so that it should still work. In case you need a binary patch for 10.9 please contact me via PM. Provided there haven't been too much changes in the driver it shouldn't take me more than half an hour to patch the Mavericks binary.

 

Mieze 

Link to comment
Share on other sites
  • 2 weeks later...
HazMatt
HazMatt
Posted
Posted

Try debug version and show kernel log. Maybe it gives a key what is the problem

… continued discussion from here …

 

Briefly, I'm having trouble with my Ethernet interface disappearing after reboot (System Prefs > Network says "Cable Unplugged" with red icon).  'Ethernet' is not in the add list.  I installed BCM5722D 2.3.5 (ML_BCM5722D.kext.zip) and now Ethernet is showing up again.  BUT, the DHCP pulls a bogus IP address (169.254.XXX.XXX) and manual assignment doesn't work either.

 

Alex has suggested I install the debug version, which I have just done, but now the Ethernet interface is gone again.  Maybe the debug version is an older version that doesn't include the 2.3.5 fix?

 

I'm very motivated to fix this problem, so I'll pretty much do whatever anyone suggests!  :)

Link to comment
Share on other sites
Alex009988
Alex009988
Posted
Posted

I checked the version for ML(Debug version) and it works though I have Mavericks. In additional, it's the last version 2.3.5.

Debug version is the same that main is. The only distinguish is that it gives more info to understand in which part of code we have a mistake.

What version of Mac do you use?

Didn't you forgot to fix permissions by Kext Utility or other program?

Link to comment
Share on other sites
Dan_Marshall
Dan_Marshall
Posted
Posted

Hi all,

 

Just wanted to say I have been using the this kext in my Dell Optiplex 745 (Desktop) since I hackintosh'd it and it works quite well. Been updating as new versions become available and currently on 2.3.5.

 

I'm no where near as versed as you guys here with code but if I can be of assistance I am more than happy to help out.

 

Regards,

Dan

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...