Full Version: Broadcom 570x and 575x
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.
QUOTE(KennyW @ Jul 31 2008, 06:34 AM) 
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.
QUOTE(heyster @ Aug 10 2008, 02:58 AM)
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.
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
^^
> 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).
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).
QUOTE(Loepere @ Aug 20 2008, 09:49 PM)
> 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.
..
......
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 ..
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).
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).
is this driver working for BCM 5906M too???
Anyone know how i can get it working on a 5705 plz pm me
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.
Thanks.
acer 4710 internet not working
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.
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.
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
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
Could somebody patch this to work with the broadcom BCM5787? This would be great!
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
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
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
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
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...
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...
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
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
Hi all
anybody try this solution to BCM5750 (DEV_16fd) ?
anybody try this solution to BCM5750 (DEV_16fd) ?
QUOTE(noahbody99 @ Sep 23 2008, 04:08 PM)
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"
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....
QUOTE(noahbody99 @ Sep 23 2008, 11:27 PM)
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
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
QUOTE(robydream @ Sep 24 2008, 01:05 AM)
....So please...download modified kext and post your comment if is freezing or not...
Many thanks people for patching informations...
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
QUOTE(noahbody99 @ Sep 23 2008, 10:27 PM)
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
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.
QUOTE
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
__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
QUOTE(noahbody99 @ Sep 23 2008, 04:08 PM)
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.
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 .
QUOTE(EternalEmpty @ Sep 24 2008, 12:23 PM)
pretty good work ..^^
now 1693 is the headache part, I don't have the hardware ..almost can't do anything about it .
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
how about 14e4:16fd ???
or let me know - where located section BCM5751Enet::getAdapterInfo ??
or let me know - where located section BCM5751Enet::getAdapterInfo ??
QUOTE(noahbody99 @ Sep 23 2008, 09:27 PM)
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
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
cool!!!
it works!
I love you so much!
COOOOOl YES ole oleoleole Russia VPERED
Broadcom NetXtreme Lan (VEN_14E4&DEV_16FD) worked with kext modified by this solution))
im go to testing
Many thanks to all
Broadcom NetXtreme Lan (VEN_14E4&DEV_16FD) worked with kext modified by this solution
))im go to testing
Many thanks to all
Thanks Noahbody, robydream et al. for the perfect work.
On my Lenovo ThinkPad r61i the modified Broadcom Netlink Gigabit BCM5787 patched kext works absolutely fine. Previous patches only allowed network traffic for a few minutes. Now, the LAN connection holds stable across all speeds (10/100/1000 mbps).
Thanks again for the hard work and the numerous hours of testing. But, I guess, in the end it was worth it.
========
Lenovo ThinkPad r61i
2 Gb RAM
Iatkos 4i
OSX 10.5.4
On my Lenovo ThinkPad r61i the modified Broadcom Netlink Gigabit BCM5787 patched kext works absolutely fine. Previous patches only allowed network traffic for a few minutes. Now, the LAN connection holds stable across all speeds (10/100/1000 mbps).
Thanks again for the hard work and the numerous hours of testing. But, I guess, in the end it was worth it.
========
Lenovo ThinkPad r61i
2 Gb RAM
Iatkos 4i
OSX 10.5.4
QUOTE(haimon @ Sep 24 2008, 09:58 AM)
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
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
Hi All
I install kalyway 10.5.2, network card don`t work.
i install broadcom and IONetworking(kext) from JaS 10.5.4 (patch`s folder in DVD/system/.......
String include in AppleBCM5751Ethernet.kext.
System profile show 5755 (en0), and show thw real MAC address. I set DHCP first and i set manual IP secund, but both don`t work.
any good idea?
My gx620 started to get internet automatically with the 10.5.5 update, no more need to set up the MAC ADDRESS script.
=)
=)
Anyone with 14e4:1600?
Will try noahbody99's solution soon...
Anyway - thanks to all of you for the effort!
Will try noahbody99's solution soon...
Anyway - thanks to all of you for the effort!
OMG THANK YOU SO MUCH , NOW I HAVE MY NET AND MAC ADDRESS YAY !!!
14E4 1600 WORKS PERFCTLY LOL XD LOVE YOU noahbody99's
but it seems to be abit slow ...
14E4 1600 WORKS PERFCTLY LOL XD LOVE YOU noahbody99's
but it seems to be abit slow ...
QUOTE(jaysonz @ Sep 26 2008, 03:41 PM)
OMG THANK YOU SO MUCH , NOW I HAVE MY NET AND MAC ADDRESS YAY !!!
14E4 1600 WORKS PERFCTLY LOL XD LOVE YOU noahbody99's
but it seems to be abit slow ...
14E4 1600 WORKS PERFCTLY LOL XD LOVE YOU noahbody99's
but it seems to be abit slow ...
Umm... Can U tell me how to make D620's sound working?
Please!All i have achieved - is int. mic working and int. speakers working even with headphones attached...
Or, maybe post Your AppleHDA.kext (and BCM57xx.kext)?
Thanks!
QUOTE(noahbody99 @ Sep 23 2008, 08:08 PM)
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.
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.
You're THE MAN!!!
An hour ago got my BCM5752 (pci14e4,1600) working like a charm: MAC's - OK, DHCP's - OK, 100M/1000M - OK!!!
For those, desperate Dell Latitude D620 owners, or who esle, by the chance, owns this card - attached 100% working kext.
NB! Place this kext
Do not forget to DELETE existing kext, and "chown/chmod/repare perms" of course!
I'm so happy, 'coz at workplace we don't have WiFi, and at last i can use MY OWN laptop instead this terrible monster, i have here...
(sorry for my english)
Can anyone help? for Broadcom BCM5906m pci14e4 0x1713
i've edited info.plist of AppleBCM5701Ethernet.kext, added that id above <string>pci14e4 , 1713</string> and did all other commands posted here to get it work.. but still it doesnt work.. anyone can help me ?
Laptop is Lenovo N200 0769 EMG
i've edited info.plist of AppleBCM5701Ethernet.kext, added that id above <string>pci14e4 , 1713</string> and did all other commands posted here to get it work.. but still it doesnt work.. anyone can help me ?
Laptop is Lenovo N200 0769 EMG
have anyone had any luck with Broadcom 5754 - Dell Optiplex 745
Vendor: 14E4
Device ID: 167A
I'm running on Leo4All ver3 - havent been sucesfull with the hexing but could be that i'm doing it incorrectly.......
Vendor: 14E4
Device ID: 167A
I'm running on Leo4All ver3 - havent been sucesfull with the hexing but could be that i'm doing it incorrectly.......
I second that. I've also got an Optiplex 745 with a 167A and cannot get this card to work on an otherwise flawless install.
QUOTE(robydream @ Sep 23 2008, 11:05 PM)
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...
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...
This works on my ACER Aspire 4310 BCM5787M NIC... Can the MAC address be hardcoded on this kext? Just like nobb1x did on his kext which is also running fine on my laptop but.... it must be on promiscuous mode which makes me a little paranoid
Great work!
Thanks!
QUOTE(collit99 @ Sep 30 2008, 09:20 AM)
This works on my ACER Aspire 4310 BCM5787M NIC... Can the MAC address be hardcoded on this kext? Just like nobb1x did on his kext which is also running fine on my laptop but.... it must be on promiscuous mode which makes me a little paranoid
Great work!
Thanks!
Great work!
Thanks!
What makes you paranoid about promiscuous mode? Do you even know what that is....?
QUOTE(walterg74 @ Sep 30 2008, 04:22 PM)
What makes you paranoid about promiscuous mode? Do you even know what that is....?
AFAIK it can compromise the security of the network, please correct me if I'm wrong.
QUOTE(collit99 @ Sep 30 2008, 05:50 PM)
AFAIK it can compromise the security of the network, please correct me if I'm wrong.
a network card basically looks at a packet and checks if the destination MAC address matches it's own. If it does, it passes the packet up in the stack, if it doesn't, it just discards it. In promosicuous mode, it basically doesn't care what the destintation MAC is, and takes all packets it sees. This mode is the one that programs such as packet capture software put your card into. No problem with that at all.... (except maybe a bit more work work for the stack, but if you're behind a swtich or router it won't matter cause all you'll get is basically packets destined to you anyway...)
Later!
Works for Broadcom NetXtreme Gigabit Ethernet BCM5754 on my XPS 1730. Hardware Id: pci14e4,1672
Heres what I did:
1. move AppleBCM5751Ethernet.kext to /System/Library/Extensions/
2. su
3. vi /System/Library/Extensions/AppleBCM5751Ethernet.kext/Content/Info.plist
...<string>pci14e4,167d</string>
becomes...
...<string>pci14e4,1672</string>
4. Install a hex editor. Edit /System/Library/Extensions/AppleBCM5751Ethernet.kext/Content/MacOs/AppleBCM5751Ethernet
Replace all occurences of 66 81 FA 7D 16 with 66 81 FA 72 16
Replace "F8 08 75 59" with "F8 08 74 59" <---This prevented system freeze after a minute
5. chown -R root:wheel /System/Library/Extensions/
6. chmod -R 755 /System/Library/Extensions/AppleBCM5751Ethernet.kext
7. reboot
9. You will have a MAC address of 00:00:00:00:00:00 But it doesnt matter.
Heres what I did:
1. move AppleBCM5751Ethernet.kext to /System/Library/Extensions/
2. su
3. vi /System/Library/Extensions/AppleBCM5751Ethernet.kext/Content/Info.plist
...<string>pci14e4,167d</string>
becomes...
...<string>pci14e4,1672</string>
4. Install a hex editor. Edit /System/Library/Extensions/AppleBCM5751Ethernet.kext/Content/MacOs/AppleBCM5751Ethernet
Replace all occurences of 66 81 FA 7D 16 with 66 81 FA 72 16
Replace "F8 08 75 59" with "F8 08 74 59" <---This prevented system freeze after a minute
5. chown -R root:wheel /System/Library/Extensions/
6. chmod -R 755 /System/Library/Extensions/AppleBCM5751Ethernet.kext
7. reboot
9. You will have a MAC address of 00:00:00:00:00:00 But it doesnt matter.
With BCM5787M NIC working on this kext, does your sleep still works?
QUOTE(collit99 @ Sep 30 2008, 12:20 PM)
This works on my ACER Aspire 4310 BCM5787M NIC... Can the MAC address be hardcoded on this kext? Just like nobb1x did on his kext which is also running fine on my laptop but.... it must be on promiscuous mode which makes me a little paranoid
Great work!
Thanks!
Great work!
Thanks!
In my case i have exactly same problem that you, and too my laptop no sleep when i use this or the other version (the promics mode), i think that you can try this:
QUOTE
Set MAC address is done by reading your MAC address in windows (ipconfig /all) and the use hex editor and at position 9c00 and 9c20 9c30... changing values of 00 to your real MAC adress...
That's force of kext to use your MAC address, but does not reading your MAC adress however it works fine for me....
Hardcode the driver is mystery becuse you need to rewrote whole function InitVram...and becuse I/O registers and memory allocations are not same for these two devices BCM5787 and BCM5751 it needs to rewrite a whole driver...
If you want you can grab linux driver for BCM5787 and write for your device kext using tools in MAC OS X...but knowledge of C/C++ is more that important to know...
So...i have set manual mac address by hex edition the kext and have discontinuited to research in other way of getting MAC automaticly...for me works manual method...
That's force of kext to use your MAC address, but does not reading your MAC adress however it works fine for me....
Hardcode the driver is mystery becuse you need to rewrote whole function InitVram...and becuse I/O registers and memory allocations are not same for these two devices BCM5787 and BCM5751 it needs to rewrite a whole driver...
If you want you can grab linux driver for BCM5787 and write for your device kext using tools in MAC OS X...but knowledge of C/C++ is more that important to know...
So...i have set manual mac address by hex edition the kext and have discontinuited to research in other way of getting MAC automaticly...for me works manual method...
it is not clear for me (this was take from a PM)
Regards.
QUOTE
Set MAC address is done by reading your MAC address in windows (ipconfig /all) and the use hex editor and at position 9c00 and 9c20 9c30... changing values of 00 to your real MAC adress...
That's force of kext to use your MAC address, but does not reading your MAC adress however it works fine for me....
Hardcode the driver is mystery becuse you need to rewrote whole function InitVram...and becuse I/O registers and memory allocations are not same for these two devices BCM5787 and BCM5751 it needs to rewrite a whole driver...
If you want you can grab linux driver for BCM5787 and write for your device kext using tools in MAC OS X...but knowledge of C/C++ is more that important to know...
So...i have set manual mac address by hex edition the kext and have discontinuited to research in other way of getting MAC automaticly...for me works manual method...
That's force of kext to use your MAC address, but does not reading your MAC adress however it works fine for me....
Hardcode the driver is mystery becuse you need to rewrote whole function InitVram...and becuse I/O registers and memory allocations are not same for these two devices BCM5787 and BCM5751 it needs to rewrite a whole driver...
If you want you can grab linux driver for BCM5787 and write for your device kext using tools in MAC OS X...but knowledge of C/C++ is more that important to know...
So...i have set manual mac address by hex edition the kext and have discontinuited to research in other way of getting MAC automaticly...for me works manual method...
There's a lot of 00 occurrences on those positions I think more than 10, MAC address only has 6.
Thanks!
QUOTE(А.Д. @ Sep 27 2008, 06:50 AM)
You're THE MAN!!!
An hour ago got my BCM5752 (pci14e4,1600) working like a charm: MAC's - OK, DHCP's - OK, 100M/1000M - OK!!!
For those, desperate Dell Latitude D620 owners, or who esle, by the chance, owns this card - attached 100% working kext.
NB! Place this kextto /System/Library/Extensions AND to the "/System/Library/Extensions/IONetworkingFamily.kext/Contents/Plugins" folder
Do not forget to DELETE existing kext, and "chown/chmod/repare perms" of course!
I'm so happy, 'coz at workplace we don't have WiFi, and at last i can use MY OWN laptop instead this terrible monster, i have here...
(sorry for my english)
An hour ago got my BCM5752 (pci14e4,1600) working like a charm: MAC's - OK, DHCP's - OK, 100M/1000M - OK!!!
For those, desperate Dell Latitude D620 owners, or who esle, by the chance, owns this card - attached 100% working kext.
NB! Place this kext
Do not forget to DELETE existing kext, and "chown/chmod/repare perms" of course!
I'm so happy, 'coz at workplace we don't have WiFi, and at last i can use MY OWN laptop instead this terrible monster, i have here...
(sorry for my english)
Thanks a lot. Wired Ethernet was the last annoyance on D620, and with your kext it works flawlessly. Appreciate your effort.
Now if I can get mute working.....
QUOTE(Gujal @ Oct 2 2008, 10:29 AM)
Thanks a lot. Wired Ethernet was the last annoyance on D620, and with your kext it works flawlessly. Appreciate your effort.
Now if I can get mute working.....
Now if I can get mute working.....
You're welcome!
No mute for me either.
But today i did codec dump with Fedora 10 Live CD (it's different from that, given me by Knoppix), and patched with Taruga's 1.20 patch again.
Result - i got speakers, headphones, internal mic and SPDIF out.
Here is what I do to make my BCM5751 work. I think it should be nearly the same for cards that has a slightly different dev id.
http://forum.insanelymac.com/index.php?showtopic=127146
http://forum.insanelymac.com/index.php?showtopic=127146
Hi all, i did the change of dev id, it works to the extend that my card shows connected but if i pull the network cable it still shows it is connected. when i ifconfig it show network down. I have a dell latitude d830 with broadcom netxtreme 57xx network card.
Thank you
Thank you
QUOTE(А.Д. @ Oct 2 2008, 11:58 PM)
You're welcome!
No mute for me either.
But today i did codec dump with Fedora 10 Live CD (it's different from that, given me by Knoppix), and patched with Taruga's 1.20 patch again.
Result - i got speakers, headphones, internal mic and SPDIF out.
No mute for me either.
But today i did codec dump with Fedora 10 Live CD (it's different from that, given me by Knoppix), and patched with Taruga's 1.20 patch again.
Result - i got speakers, headphones, internal mic and SPDIF out.
So with the new codec dump, is the mute working? If so can you please share the codec dump.
THanks a lot.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.