New Effort on BCM57xx NIC, 11% complete i guess

[jonas_man]

compal ifl90 here too

 

with bcm5787

 

ids:

PCI\VEN_14E4&DEV_1693&SUBSYS_002514C0&REV_02

PCI\VEN_14E4&DEV_1693&SUBSYS_002514C0

PCI\VEN_14E4&DEV_1693&CC_020000

PCI\VEN_14E4&DEV_1693&CC_0200

 

14E4 and 1693

 

i can test it too, btw i know a little of linux drivers, but just a little lol.

keep the good work

[Judd]

Same card aswell. BCM 5787 ready to help out.

[jonas_man]

btw i have the linux drivers source code. if anyone interasted

[Symuc]

Has any work been done on this driver since the end of November? I have checked the source out, but if any further progress has been made, it would be nice to know.

 

In any case, my system currently has NO network access under OS X. This is a major drain on incentive to do anything in the OS, much less develop wireless drivers. Ostensibly, wired drivers are easier to write, so we'll see. I would really like to see this driver work.

[EqUaTe]

Symuc,

 

You and me both mate. I was lucky - I was able to get an external wifi card (pcmcia) working.

If you have pcmcia, you might want to check out chun-nan's modded kexts..

[cookejarr]

how far along is the development?

 

I checked out the project, managed to compile and load it (loads nicely on my hacked 10.5.2 with broadcom 5752M, also reports correct MAC address.

[jafd]

Another volunteer here, BCM5787M, Acer Extensa 4220, Leopard 10.5.2. I have thought of porting if_bge.c from OpenBSD but it's like a lot of hassle, although less than porting sources from Linux (which are "canonical", but not so human-friendly).

 

By the way, I've got Xcode; how do I compile the source and make it into a ready-to-run .kext?

[jafd]

Is this topic still alive, darn it all?

[x4hu]

I don't think so... Seems like less people got interest in hackintosh. Anyway this 5787M broadcom is too hard to make. We'll just have to save money to buy macs

[jafd]

I better save money for a vacation. :-P

[jonas_man]

news:

 

http://forum.insanelymac.com/index.php?sho...05787&st=20

 

 

look post 27

[orakanggo]

any news about this project?

[BigPimpin]

Not one line of that code has been changed since the day it was posted 5 months ago. I think it's safe to say that project is dead.

[macgirl]

We could make a reward from donations like onmac.net did for making the WinXP work on Intel Macs.

[jafd]

<br />We could make a reward from donations like onmac.net did for making the WinXP work on Intel Macs.<br />

<br /><br />If there were enough of donations, I would happily port BSD driver. I looked at it, the source is not as hopeless as it is in Linux's tg3.c, but it would require something like 3 weeks worth of work, and I have to make a living...

 

By the way — what if I make an entry on micropledge.org and let people decide how much would they donate?

[jonas_man]

Do That!

[macintrash]

btw i have the linux drivers source code. if anyone interasted

 

Have a read, should be enough to dissuade any sane person from trying to get a TG3 card working.

 

The way I figure it, the best chance you'd have of getting a working driver would be to compare in the Linux code - http://fxr.watson.org/fxr/source/drivers/n...3.c?v=linux-2.6 - the PCI Device # of your card, against the PCI Device # of the small array of supported 57xx drivers and do *intelligent* (or at least guided) hex editing (see the many other posts on this).

 

Since every reference in the binary to 81 FA 69 16 (actual numbers may not be as I remember) is a conditional jump for that card (a hypothetical 0x1669), one needs to look at what they all mean...

 

The source code is littered with these:

 

11545				 if ([url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) == [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5755"]ASIC_REV_5755[/url] ||
11546					 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) == [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5787"]ASIC_REV_5787[/url] ||
11547					 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) == [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5784"]ASIC_REV_5784[/url] ||
11548					 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) == [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5761"]ASIC_REV_5761[/url] ||
11549					 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) == [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5906"]ASIC_REV_5906[/url]) {
11550						 tp->tg3_flags2 |= [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=TG3_FLG2_HW_TSO_2"]TG3_FLG2_HW_TSO_2[/url];
11551						 tp->tg3_flags2 |= [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=TG3_FLG2_1SHOT_MSI"]TG3_FLG2_1SHOT_MSI[/url];
11552				 } else {
11553						 tp->tg3_flags2 |= [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=TG3_FLG2_HW_TSO_1"]TG3_FLG2_HW_TSO_1[/url] | [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=TG3_FLG2_TSO_BUG"]TG3_FLG2_TSO_BUG[/url];
11554						 if ([url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) ==
11555								 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5750"]ASIC_REV_5750[/url] &&
11556							 tp->pci_chip_rev_id >= [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=CHIPREV_ID_5750_C2"]CHIPREV_ID_5750_C2[/url])
11557								 tp->tg3_flags2 &= ~TG3_FLG2_TSO_BUG;
11558				 }
11559		 }
11560 
11561		 if ([url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5705"]ASIC_REV_5705[/url] &&
11562			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5750"]ASIC_REV_5750[/url] &&
11563			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5752"]ASIC_REV_5752[/url] &&
11564			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5755"]ASIC_REV_5755[/url] &&
11565			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5787"]ASIC_REV_5787[/url] &&
11566			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5784"]ASIC_REV_5784[/url] &&
11567			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5761"]ASIC_REV_5761[/url] &&
11568			 [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=GET_ASIC_REV"]GET_ASIC_REV[/url](tp->pci_chip_rev_id) != [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=ASIC_REV_5906"]ASIC_REV_5906[/url])
11569				 tp->tg3_flags2 |= [url="http://fxr.watson.org/fxr/ident?v=linux-2.6;im=excerpts;i=TG3_FLG2_JUMBO_CAPABLE"]TG3_FLG2_JUMBO_CAPABLE[/url];

http://fxr.watson.org/fxr/source/drivers/n...inux-2.6#L11570This is why there are so many instances to replace.... and since everychoice has a 1 in 2 chance of being the *wrong* choice, and some Device ID's have 20+ jumps, you chances of getting a perfect results are the same as flipping a coin 20 times and getting heads.

 

So get smarter -

 

(for instance), I have a 5786 at work, and that Device ID does *not appear once* for a conditional feature or bug within the code.... but lets say I hexedit a 5787 hack that I know works (and I tried this today), I might think I'd have a good chance for sucess.

 

But although these cards are but a single Device ID apart, there are a multitude of conditional jump specific to the 5787 that don't apply to the 5786. So my hacked driver freezes the machine in 5 minutes or so.

 

If I take the time to check the number of conditions of other Device ID's, I might find one that shares more in common. In the above piece of code we see that the 5787 has more in common with the 5784.

 

In short, the odds are long, and the reward small... but some people get their cards to work. And some people don't. Most people pick a random Device ID to hexedit,... and most people don't get a good result.

 

But those who have tried multiple times may have noticed that when replacing a different DeviceID or even trying the "other" kext, will suddenly make the MAC address appear, but the link won't detect.... yet before the MAC wasn't working, but the link worked and crashed.

 

Spend long enough flipping bits and you will get a working driver. Or at least one that doesn't crash perhaps.

 

Start with the closest match you can find, replace that Device ID with yours, and see what happens. If you get a partial result, but it crashes, try changing *half* of the Device ID's back to what they were. If that makes it better, then you're making progress.

 

If not, try it the other way.

 

Keep notes about the differences ... and move on to quarter sized sections...

 

Might take a while, but if you start with the closest match, you sould see results. Enough to encourage you.

 

Eventually, if enough people were to pro-actively search - we'd have an analog of the "human genome project"... might be enough .... if one were to dissassemble the code, or just take careful notes, perhaps conlusions could be reached such as:

 

"The Apple driver takes action X for Device A B and F, the corrosponding Linux driver makes a choice involving Device A B and F in two places... therefore this block probably involves "Jumbo Frames".

 

Then - checking your card against the Linux source, and how it's handles Jumbo frames, you could decide whether it was appropriate for it to Jump or not.

 

The other important thing would be to try and determine as much as possible about the "freeze" that we mostly get when we half-way manage to get a working driver. Is it time based, is it traffic based, is it a buffer filling up? Does it happen on a network with no traffic?

 

Find out what triggers the freeze, and you can look in the Linux or FreeBSD source and see what it might be related to - eg, there are "5 x HZ" timeout checks done... so if your rig crashed 5 seconds after you send a network packet... well, you know where to look (or at least - you know what drivers this applies to).

 

I'm making it sound easier than it is, I know.

 

But the URL to the code I pasted is cross referenced... so find your Device ID, click the hyperlink, and see where it pops up. Have a list of the valid Apple Device ID's in front of you, and see if any seem to share a lot of conditional jumps with yours.

 

That might be enough.

 

A pity the Broadcom has to be so ubiquitous, and yet so divergant in it's many models.

[nobb1x]

Respect for your research, but i don't see a reason to revive a dead post on a dead project.

[pocopico]

@macintrash

 

Very good approach i think... i did the same for my 5787m card to work but as you said... there are so many instances to change and chances to replace the right one are odd ... lets hope some gets lucky and get my Compaq 6510b Broadcom 5787 card work ... LOL !!!

 

The broadcom chips look like they get grouped in the driver and they are treated the same among the ones in the group ( I dont know if what i say makes sense) the reason your machine freezes is probably because you are telling the driver to use a wrong group for your chip (maybe ?)...

 

for instance :

 

5755 and 5787 & 5784 & 5761 should by treated the same as they look similar ....

 

5901 , 5901_2 ,5705F ,5751F, 5753F, 5787F, 5906 are different types and are treated differently

[AlexD.]

Hello, guys!

 

If anyone got BCM5752 (0x1600) - take a look at my post here

It's fully working solution for this card (personally i have Dell Latitude D620 with this chip onboard).

 

Good luck to all!

[shdwsclan]

Don't forget the 5752m.

 

The 5752 is the mobile version of the 5752 chipset.

Vendor:14e4

Device:1601