Broadcom 570x and 575x

[KennyW]

For all those seeking for Broadcom BCM 5752 driver for Leopard, I would say just forget it. Having looking for months and trying the various posted kexts and patches, it's enough. I just bought the Apple USB to Ethernet adapter at about US$30 and everything works beautifully with native support from the OS for my HP Compaq dx7200. In fact, there are cheaper such adapters selling at half the price that would work, just that driving to downtown counting all the gas and the parking fee and the time I need to spend, an order from the Apple Store with free shipping and delivery to the door is more cost effective to me ;-) Besides, there is no need to constantly look for driver patches as the adapter is natively supported. I would assure you that the dollars are well spent and you can enjoy your Hackintosh in no time.

[heyster]

For all those seeking for Broadcom BCM 5752 driver for Leopard, I would say just forget it. Having looking for months and trying the various posted kexts and patches, it's enough. I just bought the Apple USB to Ethernet adapter at about US$30 and everything works beautifully with native support from the OS for my HP Compaq dx7200. In fact, there are cheaper such adapters selling at half the price that would work, just that driving to downtown counting all the gas and the parking fee and the time I need to spend, an order from the Apple Store with free shipping and delivery to the door is more cost effective to me ;-) Besides, there is no need to constantly look for driver patches as the adapter is natively supported. I would assure you that the dollars are well spent and you can enjoy your Hackintosh in no time.

 

I total agree with you. Spending ever 2nd week 2 hours with reinstalling Vista to get the Broadcom wifi awake, and restore a backup is no fun at all.

Those 30 bucks are worth it.

[EternalEmpty]

I total agree with you. Spending ever 2nd week 2 hours with reinstalling Vista to get the Broadcom wifi awake, and restore a backup is no fun at all.

Those 30 bucks are worth it.

 

 

 

I think it is not about the money for most of people here, is the FUN of making something NOT "suppose to be" to be "I have made it work" ....

 

have fun ....everyone

 

 

^^

[Loepere]

> 9) change address 37554, 37555 of "75 71" to "EB 71"

 

This change causes the call to InitNVRam to be bypassed, which is why the MAC address does not get picked up. But, instead of bypassing the call to InitNVRam, one can patch the offending check in InitNVRam.

 

Near the beginning of BCM5701::InitNVRam (__ZN11BCM5701Enet9InitNVRamEv), there are the following calls:

 

write570XRegister(grc eepro addr...)

read570XRegister(grc local ctrl...)

write570XRegister(grc local ctrl...)

read570XRegister(nvram cfg...)

 

which is followed by the offending sequence:

testb $0x01,%al // look for serial eeprom

je Label1

testb $0x03,%al // look for unbuffered flash

je Label1

Label3: movl $0x00000003,0x000003b4(%ebx) // mark nvram as flash

jmp Label2

Label1: ... // log error

return

Label2: ... // continue to read flash

 

Unfortunately, many of the cards do not indicate that they have flash memory in this way.

 

Assuming that the card you're supporting has flash nvram, replacing the "je Label1" instructions with "je Label3" will properly scan the nvram and set (among other things) the MAC address (at least it does on my 5754).

[EternalEmpty]

> 9) change address 37554, 37555 of "75 71" to "EB 71"

......

 

Unfortunately, many of the cards do not indicate that they have flash memory in this way.

 

..

 

That is why I gave up to to make one for all ... ~_~

 

 

Beside, the ram size is not the same, and ask for buffer size is different too ..

[Loepere]

The problem with the driver dying after limited use (at least for my 5754) is that the wrong receive ring size is being selected.

 

The driver has several ways of identifying the hardware in question and making decisions about it.

 

The previous posts talked about editing the check against the PCI device ID. These have the form:

"movw PCI device ID, %..." (the PCI device ID being at object offset 0x03ba)

"cmpw $specific ID,%..."

 

Many of the checks, though, are against the ASIC version of the chip. These have the form:

"movw chip rev,%..." (the chip rev being at object offset 0x03c0)

"shrw $0x0c,%..."

"cmpw $specific ASIC rev,%..."

 

In BCM5701Enet::getAdapterInfo (__ZN11BCM5701Enet14getAdapterInfoEv), in particular, there is this sequence:

cmpw $0x08,%ax

jne L1

L2: movl $0x00010000,mbuf pool addr

movl $0x0000e000,mbuf pool size

movl $0x00000200,rx ring size

 

I was able to get my 5754 working by changing the "jne L1" into a "jmp L2", which selects the right sizes for a 5705 plus class device (which is pretty much all except the 5700-5704 models).

[christian_gamas]

is this driver working for BCM 5906M too???

[nickhe]

Anyone know how i can get it working on a 5705 plz pm me

[omegax]

Hi Loepere, does that mean your modified driver makes your 5754 work flawlessly without an KP or need to frequently reboot? Does DHCP work OK too? If yes, can you possibly modify the driver to work for the 5787 card? If not, can you please post your modified driver as-is? At least we could try and see if it works with the 5787.

Thanks.

[thaison]

acer 4710 internet not working

[noahbody99]

Thanks to Loepere's previous post, I was able to get the Broadcom BCM 5755M (device id 1673) working flawlessly on my Dell Latitude D830 running Leopard 10.5.4 (no more GSOD or "freezing" after limited use).

 

I used EternalEmpty's AppleBCM5751Ethernet.kext (downloaded BCM57XX.zip from http://forum.insanelymac.com/index.php?sho...114605&st=0). I followed the directions in the tutuorial.

 

I then changed the entry in /System/Library/Extensions/AppleBCM5751Ethernet.kext/Contents/Info.plist:

 

pci14e4,167d to pci14e4,1673 (my device id)

 

Then I copied /System/Library/Extensions/AppleBCM5751Ethernet.kext/Contents/MacOS/AppleBCM5751Ethernet to my home folder so I could edit it with Hexedit, and replaced all occurrences:

"66 81 FA 7D 16" with "66 81 FA 73 16"

to match my device id.

Note: I did not change address 37554, 37555 of "75 71" to "EB 71" to bypass the call to InitNVRam - I left it as it should be ("75 71").

 

And now here is the elusive solution...

 

I located the section BCM5751Enet::getAdapterInfo and found the identical code which Loepere refers to. I changed "jne L1" into a "je L1" which using Hexedit simply translates to:

address 376C0: replace "F8 08 75 59" with "F8 08 74 59"

 

 

Copied the modified AppleBCM5751Ethernet back to the original location in /System/Library/Extensions/AppleBCM5751Ethernet.kext/Contents/MacOS.

 

MAC address gets assigned correctly to en0, and DHCP works perfectly.

[thestevo]

Hello Noahbody99,

 

I will try your instructions shortly, just to double check the process. However, could you please post your kext? Newer users won't understand this process or wish to follow the instructions. Since you were the first to get it running, you should get the credit for the kext instead of somebody else posting the kext for an average user.

 

theStevo

[thefly]

Could somebody patch this to work with the broadcom BCM5787? This would be great!

[noahbody99]

OK,

 

I've attached my modified kext file. It may work for BCM5787 (device id 1693), because I made additional modifications to try to make it work as well, but I can't promise anything since I only have a BCM5755M (device id 1673) and I know it is already working perfectly with that.

 

Noah

AppleBCM5751Ethernet.zip

[thestevo]

Noahbody99,

 

I officially love you! Not only did you provide a method for getting the NIC working, but you saved me a reinstall. I tried your procedure as per your directions and it didn't work. It recognized the adapter, loaded correct MAC, knew cable connection status, but wouldn't do DHCP right or transfer IP even with manual settings. I was going to reinstall because I was sure that the VMware or Parallels network kexts were somehow messing with it, but now I don't need to. I must have missed something, so it may be helpful if you could carefully check your procedure above. However, your kext seems to work fine!

 

Now, a quick question. How did you know where "jne L1" was and what to change it to? Hex Edit and HexFiend didn't show jne L1 in ASCI, so I'm wondering how you knew where it was. Plus, I understand the concept of what changing jne L1 did, but how did you know to change it to "je L1" instead of "jmp L2" like Loepere mentioned?

 

Thanks again!

theStevo

[robydream]

Hy....i have a BCM5787 (device id1693) ant tryed your kext but it does not work...in console is writing....

 

InitNVRam..magic constant not found..and LAN card is not found...

 

Then i found in order the BCM5787 to be recognized is to be set address 37554, 37555 of "75 71" to "EB 71" (This change causes the call to InitNVRam to be bypassed, which is why the MAC address does not get picked up)...

 

When i have changed it to "75 71" The Card could not be recognized end error,when set to "EB 71" card is recignized, but without MAC and Device and Manufacturer name is Unknown.... (Your kext has set it to "EB 70" so is not recognized)

 

I have the replaced address 376C0: replace "F8 08 75 59" with "F8 08 74 59" and is the same...no MAC but DHCP work great!

 

I have modify kext with "75 71" to bypass InitNVRam and recognize BCM5787, and replace "F8 08 75 59" with "F8 08 74 59"... this last step is for not freezing card..i have tested it and no problem at all...

 

So please...download modified kext and post your comment if is freezing or not...

 

Many thanks people for patching informations...

AppleBCM5751Ethernet.kext.zip

[thefly]

Hi noahbody99,

Thnx for the patch I will give it a try this evenyning!

I will report back here if you are a lifesaver or a dreamkiller .

 

Anyway thnx for the fast replay Crossing my fingers and hope to see a magic IP appear

 

Greatz

 

The Fly

[sandr]

Hi all

anybody try this solution to BCM5750 (DEV_16fd) ?

[sandr]

I located the section BCM5751Enet::getAdapterInfo and found the identical code which Loepere refers to. I changed "jne L1" into a "je L1" which using Hexedit simply translates to:

address 376C0: replace "F8 08 75 59" with "F8 08 74 59"

 

Please answer, where located section BCM5751Enet::getAdapterInfo ?????

its in file (what file), in log, in osx, in win etc....

[haimon]

OK,

 

I've attached my modified kext file. It may work for BCM5787 (device id 1693), because I made additional modifications to try to make it work as well, but I can't promise anything since I only have a BCM5755M (device id 1673) and I know it is already working perfectly with that.

 

Noah

 

Hi Noah and everbody

 

Do you help for my?

My card is Broadcom 5755, but i can`t made correct kext. Card ID: 167b

You can make and upload a kext?

 

Thanks

[proosje]

....So please...download modified kext and post your comment if is freezing or not...

 

Many thanks people for patching informations...

 

I tried your kext RobyDream and i can report that it works for me.

MAC address is still all zeros but networking works, and does not seem to freeze.

 

It does freeze if i try to do a ifconfig en0 ether 00:1C:xx:xx:xx:xx

 

My card is a 5787M (id 1693)

 

Thanks

[macintrash]

OK,

 

I've attached my modified kext file. It may work for BCM5787 (device id 1693), because I made additional modifications to try to make it work as well, but I can't promise anything since I only have a BCM5755M (device id 1673) and I know it is already working perfectly with that.

 

Noah

 

The 5755 and 5787 are quite similar (almost identical, compared to say - a 5786).

 

Linux:

http://fxr.watson.org/fxr/ident?v=linux-2....i=ASIC_REV_5755

 

FreeBSD:

http://fxr.watson.org/fxr/source/dev/bge/if_bge.c#L2623

 

FreeBSD seems to handle it a little differently, to my glance over the hex of the Apple driver, it looks more like a hardcoded choice (like the Linux driver). Could just be that the FreeBSD driver isn't complete (it has some binary code).

 

I think it's enough to work out which jump does what though. I would decompile it, but I don't know how to put it back together again. (Always been better at pulling things apart).

 

Can anyone supply the complete dissasembly in a format that can be recompiled with XCode?

 

I can disassemble with IDA under Windows, but I can't "put humpty dumpty together again."

 

Looking at the Linux code, it shouldn't be too hard to figure out. I'd like to do a proper job though - identify all the check, and which cards need which jumps... or at least have the jumps documented.

 

Here's something I picked up on Google, it's in Spanish, but looks neat.

 

Pese a que teníamos un driver funcional, no podíamos parar de darle vueltas al asunto, además el driver que teníamos tenía un problema que queríamos solucionar: se colgaba si intentabas cambiar la MAC con ifconfig, solamente funcionaba al iniciarse el driver. Total que seguimos navegando por el código del driver, hasta que paramos con lo siguiente:

 

__text:00000000 BCM5751Enet::BCM5751Enet(OSMetaClass const*) proc near

__text:00000000 ; CODE XREF: BCM5751Enet::BCM5751Enet(OSMetaClass const*)+14

__text:00000000 ; __text:0000003Cp …

__text:00000000

__text:00000000 var_18 = dword ptr -18h

__text:00000000 var_14 = dword ptr -14h

__text:00000000 arg_0 = dword ptr 8

__text:00000000 arg_4 = dword ptr 0Ch

__text:00000000

__text:00000000 000 push ebp

__text:00000001 004 mov ebp, esp

__text:00000003 004 push ebx

__text:00000004 008 sub esp, 14h

__text:00000007 01C mov ebx, [ebp+arg_0]

__text:0000000A 01C mov eax, [ebp+arg_4]

__text:0000000D 01C mov [esp+18h+var_14], eax

__text:00000011 01C mov [esp+18h+var_18], ebx

__text:00000014 01C call BCM5751Enet::BCM5751Enet(OSMetaClass const*)

__text:00000019 01C mov dword ptr [ebx], 0F100h

__text:0000001F 01C mov eax, ebx

__text:00000021

__text:00000021 loc_21: ; DATA XREF: __data:_mediumTableo

__text:00000021 01C add esp, 14h

__text:00000024 008 pop ebx

__text:00000025 004 pop ebp

__text:00000026 000 retn

__text:00000026 BCM5751Enet::BCM5751Enet(OSMetaClass const*) endp

 

Dicha función se llamaba varias veces en el driver, y es EXCESIVAMENTE recursiva, tanto que debería cascar el programa, porque la pila a dia de hoy no es infinita, nuestros dialogos en ese momento eran tal que los siguientes:

 

- "como ^!###! puede ser?"

 

- "es imposible que eso se ejecute"

 

- "pero no ves las cantidad de xrefs que tiene!!?"

 

- "que no puede ser"

 

- "mete una int 3 ahí i reinicia"

 

Ni falta hace decir que salto la int 3, con un msg que nos decía que estabamos listos para atachearnos al debugger y nosotros pensando "sí, si tuvieramos debugger aquí ibamos a estar", aunque por otro lado pensamos "oie pues igual eso de tener un debugger no está tan mal", pero claro la depuracion por red del driver de red… como que no, cable serie no teníamos, instalar en una vmware no nos valía porque el hardware es diferente, y la principal razón: no teníamos ni idea de como iba lo de depurar un driver ahí, así que tuvimos que seguir con nuestras int 3´s y nuestros casques …

 

De repente se nos ocurrió una feliz idea:

 

- "oye esto no tendrá relocs?"

 

- "supongo.."

 

- "y que pasa si llenas un buffer de nops y resulta que hay una reloc para algo que hay por el medio"

 

- "oxtia, pues que a saber lo que se ejecuta! xD"

 

- "y la función recursiva esa que hemos visto antes,,, no será que por lo que sea están aplicandose relocs sobre el call …"

 

- "pero ese call es relativo, no _debería_ necesitar relocs!"

 

Y efectivamente … el IDA no interpreta las relocs en los ficheros mach-o todavía, de hecho lo avisa al cargar el ejecutable, pero se ve que no nos sirvió de advertencia … Buscando herramientas de desensamblado, solo por quitarme la curiosidad, vi que con junto con xcode, viene una utilidad llamada otool, que sí que interpreta las relocs, y con la cual obtuve el siguiente desensamblado:

 

__ZN11BCM5751EnetC2EPK11OSMetaClass:

00000000 pushl %ebp

00000001 movl %esp,%ebp

00000003 pushl %ebx

00000004 subl $0×14,%esp

00000007 movl 0×08(%ebp),%ebx

0000000a movl 0×0c(%ebp),%eax

0000000d movl %eax,0×04(%esp,1)

00000011 movl %ebx,(%esp,1)

00000014 calll __ZN20IOEthernetControllerC2EPK11OSMetaClass

00000019 movl $__ZTV11BCM5751Enet,(%ebx)

0000001f movl %ebx,%eax

00000021 addl $0×14,%esp

00000024 popl %ebx

00000025 popl %ebp

00000026 ret

 

Perfecto, nuestra teoría era válida!, ya podíamos hacer parches!, solamente teníamos que tener cuidado de no tocar cosas que pudieran contener codigo que necesitara relocs! ( recordad esto toda vuestra vida!, yo ya lo he apuntado por las paredes de casa, "ojo, relocs!" xD ), así que continuamos con la desgracia del driver…

 

El siguiente paso fue mirar la documentacion de apple del kernel, a ver como se implementaban los drivers ethernet, en el enlace anterior podeís ver que los controladores de este tipo heredan de una clase y deben implementar los metodos que ahí se listan, si bien algunos de ellos, no son obligatorios como es el caso de setHardwareAddress:

 

 

setHardwareAddress(const IOEthernetAddress *)

Sets or changes the station address used by the Ethernet controller. public

virtual <a target="_top" class="type" href="http://developer.apple.com/documentation/Darwin/Reference/KernelIOKitFramework/IOReturn/CompositePage.html#//apple_ref/c/tdef/IOReturn">IOReturn setHardwareAddress(

const IOEthernetAddress *addrP); <h5 class="tight">Parameters</h5> addrPPointer to an IOEthernetAddress containing the new station address. <h5 class="tight">Return Value</h5> The default implementation will always return kIOReturnUnsupported. If overridden, drivers must return kIOReturnSuccess on success, or an error return code otherwise.

 

<h5 class="tight">Discussion</h5> This method is called in response to a client command to change the station address used by the Ethernet controller. Implementation of this method is optional. This method is called from the workloop context.

 

La implementacion de setHardwareAddress era la siguiente:

 

__text:000012E2 BCM5751Enet::setHardwareAddress(IOEthernetAddress const*):

__text:000012E2 push ebp

__text:000012E3 mov ebp, esp

__text:000012E5 push ebx

__text:000012E6 sub esp, 14h

__text:000012E9 mov ebx, [ebp+8] ; Interfaz

__text:000012EC mov edx, [ebp+0Ch] ; IOEthernetAddress *

__text:000012EF test edx, edx ; NULL ?

__text:000012F1 jnz short SetMac ; MAC size

__text:000012F3 mov eax, 0E00002C2h ; Error code

__text:000012F8 jmp short GoOut

__text:000012FA ; —————————————————————————

__text:000012FA

__text:000012FA SetMac: ; CODE XREF: __text:000012F1j

__text:000012FA mov dword ptr [esp+8], 6 ; MAC size

__text:00001302 lea eax, [ebx+31Eh]

__text:00001308 mov [esp+4], eax ; Mac Offset in the Object

__text:0000130C mov [esp], edx ; new IOEthernetAddress *

__text:0000130F call BCM5751Enet::BCM5751Enet(OSMetaClass const*) ; Set MAC

__text:00001314 mov byte ptr [ebx+367h], 1

__text:0000131B cmp byte ptr [ebx+304h], 0

__text:00001322 jz short SetOptionFailed

__text:00001324 mov [esp], ebx

__text:00001327 call BCM5751Enet::putToSleep(void) ; Go to dream …

__text:0000132C mov [esp], ebx

__text:0000132F call BCM5751Enet::getAdapterInfo(void)

__text:00001334 mov [esp], ebx

__text:00001337 call BCM5751Enet::wakeUp(void) ; Update Object and wake up!

__text:0000133C

__text:0000133C SetOptionFailed: ; CODE XREF: __text:00001322j

__text:0000133C xor eax, eax

__text:0000133E

__text:0000133E GoOut: ; CODE XREF: __text:000012F8j

__text:0000133E add esp, 14h

__text:00001341 pop ebx

__text:00001342 pop ebp

__text:00001343 retn

 

Despues de aplicar un par de parches, nos dimos cuenta de que la tarjeta se quedaba frita al hacer el wakeup y pensamos ¿será necesario hacerlo?, eché un vistazo al driver de la tigon 3 que hay para linux y no parecía que "reseteara" el adaptador en ningun momento, supusimos que la mac se almacenaba en algún registro de la tarjeta, y encontramos que había una funcion que esta anterior llamaba internamente:

 

SetMacAddress(IOEthernetAddress *) , esta accedía a los registros de la tarjeta usando la siguiente función:

 

__text:00001896 BCM5751Enet::write570XRegister(unsigned long volatile*, unsigned long) proc near

__text:00001896 ; CODE XREF: __text:000029A6p

__text:00001896 ; __text:00002ADFp …

__text:00001896

__text:00001896 var_28 = dword ptr -28h

__text:00001896 var_24 = dword ptr -24h

__text:00001896 var_20 = dword ptr -20h

__text:00001896 var_1C = dword ptr -1Ch

__text:00001896 var_18 = dword ptr -18h

__text:00001896 arg_0 = dword ptr 8

__text:00001896 arg_4 = dword ptr 0Ch

__text:00001896 arg_8 = dword ptr 10h

__text:00001896

__text:00001896 push ebp

__text:00001897 mov ebp, esp

__text:00001899 sub esp, 28h

__text:0000189C mov edx, [ebp+arg_0]

__text:0000189F mov ecx, [ebp+arg_4]

__text:000018A2 mov eax, [ebp+arg_8]

__text:000018A5 cmp byte ptr [edx+0E1Ch], 0

__text:000018AC jnz short ChangeEndian

__text:000018AE mov [esp+28h+var_18], offset aWrite570xregis ; "write570XRegister - write without power"…

__text:000018B6 mov [esp+28h+var_1C], 0

__text:000018BE mov [esp+28h+var_20], eax

__text:000018C2 mov [esp+28h+var_24], ecx

__text:000018C6 mov [esp+28h+var_28], 1

__text:000018CD call BCM5751Enet::KIOLog(uchar,ulong,ulong,ulong,char *)

__text:000018D2 jmp short GoOut

__text:000018D4 ; —————————————————————————

__text:000018D4

__text:000018D4 ChangeEndian: ; CODE XREF: BCM5751Enet::write570XRegister(ulong volatile*,ulong)+16j

__text:000018D4 cmp byte ptr [edx+0E10h], 2

__text:000018DB jnz short DMAWrite

__text:000018DD bswap eax

__text:000018DF

__text:000018DF DMAWrite: ; CODE XREF: BCM5751Enet::write570XRegister(ulong volatile*,ulong)+45j

__text:000018DF mov [ecx], eax

__text:000018E1

__text:000018E1 GoOut: ; CODE XREF: BCM5751Enet::write570XRegister(ulong volatile*,ulong)+3Cj

__text:000018E1 leave

__text:000018E2 retn

__text:000018E2 BCM5751Enet::write570XRegister(unsigned long volatile*, unsigned long) endp

 

La escritura parecía hacerse en plan acceso directo a memoria, y el msg de "write without power" era mosqueante, al final acabamos pensando que podíamos hacer una prueba: reescribir la implementacion de setHardwareAddress, quitar el wakeup y demás y llamar directamente a SetMacAddress, aplicando también un parchecillo en la funcion de escritura del registro por si acaso no le daba la gana escribir… escribiendo asm en el notepad y parcheando de nuevo con el hiew, quedó una cosa tal que la siguiente:

 

newsetHardwareAddress:

 

mov ebx, [esp+8] ; Iface

mov esi, [esp+0c]; IOEthernet

jnz Write

mov eax, 0E00002C2h

jmp Return

 

Write:

 

push esi

push ebx

 

call SetMacAddress

 

pop ebx

pop esi

 

lea edi [ebx+31Eh]

mov ecx, 6

rep movsb

 

xor eax, eax

 

Return :

 

ret

 

Cargamos el driver, intentamos cambiar la MAC y el adaptador no se quedó frito (esto ya pasaba solo quitando el wakeup), la mac en la salida de ifconfig salia cambiada :-), pero no había red, si capturabas tráfico se veía que las peticiones ARP que enviaba la tarjeta llevaban de direccion de origen la nueva, pero se ve que en algun punto el driver no hacía caso a esa nueva configuración de la tarjeta, no llegaba trafico, suponemos que porque el driver pensaba que no era para él, o quizá la propia tarjeta … no ibamos a ponernos a depurar el hardware … así que tuvimos que mandar el driver a paseo, a fin de cuentas ya podíamos utilizarlo en la misma red … de cualquier modo, si alguien sabe la solución o en dónde nos hemos equivocado, me encantaría que me enviara un mail y me comentara o q

[EternalEmpty]

Thanks to Loepere's previous post, I was able to get the Broadcom BCM 5755M (device id 1673) working flawlessly on my Dell Latitude D830 running Leopard 10.5.4 (no more GSOD or "freezing" after limited use).

 

I used EternalEmpty's AppleBCM5751Ethernet.kext (downloaded BCM57XX.zip from http://forum.insanelymac.com/index.php?sho...114605&st=0). I followed the directions in the tutuorial.

 

I then changed the entry in /System/Library/Extensions/AppleBCM5751Ethernet.kext/Contents/Info.plist:

 

pci14e4,167d to pci14e4,1673 (my device id)

 

Then I copied /System/Library/Extensions/AppleBCM5751Ethernet.kext/Contents/MacOS/AppleBCM5751Ethernet to my home folder so I could edit it with Hexedit, and replaced all occurrences:

"66 81 FA 7D 16" with "66 81 FA 73 16"

to match my device id.

Note: I did not change address 37554, 37555 of "75 71" to "EB 71" to bypass the call to InitNVRam - I left it as it should be ("75 71").

 

And now here is the elusive solution...

 

I located the section BCM5751Enet::getAdapterInfo and found the identical code which Loepere refers to. I changed "jne L1" into a "je L1" which using Hexedit simply translates to:

address 376C0: replace "F8 08 75 59" with "F8 08 74 59"

 

 

Copied the modified AppleBCM5751Ethernet back to the original location in /System/Library/Extensions/AppleBCM5751Ethernet.kext/Contents/MacOS.

 

MAC address gets assigned correctly to en0, and DHCP works perfectly.

 

pretty good work ..^^

 

now 1693 is the headache part, I don't have the hardware ..almost can't do anything about it .

[nobb1x]

pretty good work ..^^

 

now 1693 is the headache part, I don't have the hardware ..almost can't do anything about it .

 

 

a specific kext for 14e4:1693 device is in final testing phase and will be published soon, i hope it will work for anybody with a 5787M (on mine and on other hacks it works)

thanks to Loepere, he is the man!

 

OUT NOW

http://forum.insanelymac.com/index.php?showtopic=127903

[sandr]

how about 14e4:16fd ???

or let me know - where located section BCM5751Enet::getAdapterInfo ??