compiling BCM5700 driver

[Drone1]

We (at work, and supervisor is not available) have a Tyan Thunder K8SRE S2891 motherboard in a 1U which is getting set up with gentoo. It has the broadcom bcm5704 chipset on board and it currently boots up 'fine' w/ kernel 2.6.16.20, however not having any network access is a real pain!

I dl'ed, and copied via USB the latest broadcomm netExtreme 57xx drivers from Tyan, vs.8.2.18. I'll untar, proceed to 'make' the drivers, but I get the following:

- warning: INCLUDE 5703_A0_FIX undefined
- warning: T3_JUMBO_RCB_ENTRY_COUNT undefined
- warning: TIGON3_DEBUG undefined

- implicit declaration of function 'register_ioctl32_conversion'
- - - -

..and when it finishes compiling,

- "unregister_ioctl32_conversion" bcm5700.ko undefined
- "register_ioctl32_conversion" bcm5700.ko undefined
- - - - -

If I try and 'insmod bcm5700.ko' , I get the following error:
- error inserting 'bcm5700.ko': -1 unknown symbol in module

- - - - - -

I was unable to find multiple '5703_A0_FIX' references other than in 1 reference in 1 file:

#if INCLUDE_5703_A0_FIX
LM_STATUS LM_Load5703DmaWFirmware(PLM_DEVICE_BLOCK pDevice);
#endif


The README states I may need to alter the 'Makefile' to include architecture specific compile switches, and possibly minor changes in the source files.

I kinda have an idea what needs to be done, but have found little information online regarding arch-type x86_64 compile switches for a case such as this.

Any pointers, hints or basic help would be greatly appreciated.

[Drone1]

Well I think the drivers compile, but I don't think they are compatible with the kernel.

When I 'insmod bcm5700.ko' as previously stated, it gives me that error and dmesg gives me,

Code: Select all

bcm5700: Unknown symbol register_ioctl32_conversion
bcm5700: Unknown symbol unregister_ioctl32_conversion

I tracked down a few links online which stated ioctl32 was 'deprecated' or any equivalent term and to be dropped from future kernel versions .....

I don't know if this was strictly for x86-64 bit arch-types or overall, but I'm fearing that what I have here is a driver that was designed at a certain kernel level, and upon moving forward, certain 'calls | registers' that were once used have since been dropped from the kernel source tree.

I may be completely off here and talking about a subject I have no business about, but this is where my investigation has led me.

If there are any developers out there, ANYONE, who can shed a hint of light on this, it would be much appreciated!!!!!!

[Drone1]

Last week I put off getting the driver to compile manually, and updated the kernel to vs. 2.6.17, and set the 'tg3' driver to moduled

For some reason, it was able to probe the hardware with the 'tg3' from the 2.6.17 kernel and work properly. The 2.6.16.20 'tg3' driver wouldn't probe properly with the bcm5704 chipset, but things are looking good so far on 2.6.17.

I'd still like to know if I was on the right track regarding ioctl32 and compile problems, and the fixes done in 2.6.17 regarding ioctl32.

Will put this solved for now.