Jump to content

Atheros AR5006EGS in 10.5.2


4 posts in this topic

Recommended Posts

Hello all,


I've replaced my laptop's internal Mini PCI Express wireless card (a crappy Intel 3945) with a Gigabyte GN-WI01GT based on the Atheros AR5006EGS chipset. Vendor id: 168c, device id: 1c. (great card btw)


It seems that some people here got it working in OSX, and I would be curious to know how (wich Mac OS X version, which kernel and which replaced kexts, and maybe also the full ioreg output for your card?).


My laptop is a Dell XPS m1330. When I boot Mac OS X 10.5.2 (iatkos v2), it recognizes the card and tries to load the driver. However, an error occurs:


Error: offset_0x100 = 0xffffffff
 start [/SourceCache/AirPortDriverAtheros5424/AirPortDriverAtheros5424-312.34/src/driver/AtherosController.cpp:481] loaded unsuccessfully


The interesting part is the "Error: offset_0x100 = 0xffffffff". This message comes from the Atheros driver (I can see the text inside the driver's binary file). Does anyone have already seen this message or know what it means?


I tried to replace the IO80211Family.kext containing the Atheros driver with various versions found on this forum, with no success. I've also installed chu-nan's patched IOPCIFamily.kext, beta1 and beta3 versions, but the result is always the same: the driver can't be loaded "successfully".


I've also tried moving the card from one mini PCI Express port to another but to no avail.


If that helps, here's the ioreg of my card:


		 | |   |   +-o PXS2@0  <class IOPCIDevice, registered, matched, active, busy 0, retain 6>
	 | |   |	   {
	 | |   |		 "IOPCIResourced" = Yes
	 | |   |		 "IOInterruptControllers" = ("io-apic-0","IOPCIMessagedInterruptController")
	 | |   |		 "IOName" = "ethernet"
	 | |   |		 "subsystem-id" = <13e90000>
	 | |   |		 "IOPCIExpressLinkCapabilities" = 211985
	 | |   |		 "IODeviceMemory" = (({"address"=18446744073608822784,"length"=65536}))
	 | |   |		 "class-code" = <00000200>
	 | |   |		 "IOPowerManagement" = {"CurrentPowerState"=0}
	 | |   |		 "revision-id" = <01000000>
	 | |   |		 "IOInterruptSpecifiers" = (<1100000007000000>,<0600000000000100>)
	 | |   |		 "assigned-addresses" = <10000c82000000000000fff90000000000000100>
	 | |   |		 "IOChildIndex" = 1
	 | |   |		 "acpi-device" = "IOACPIPlatformDevice is not serializable"
	 | |   |		 "device-id" = <1c000000>
	 | |   |		 "vendor-id" = <8c160000>
	 | |   |		 "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/RP02@1c0001/PXS2@0"
	 | |   |		 "subsystem-vendor-id" = <58140000>
	 | |   |		 "name" = "ethernet"
	 | |   |		 "IOPCIExpressLinkStatus" = 4113
	 | |   |		 "reg" = <00000c000000000000000000000000000000000010000c020000000000000000000000000000
	 | |   |		 "compatible" = <"pci1458,e913","pci168c,1c","pciclass,020000">
	 | |   |	   }



I think the problem is related to my BIOS and its IO ranges or memory ranges for mini PCI Express ports that differ from the MacBook Pro. Is there a way to fix that? (use an additional kext, patch the driver, add a special EFI string, or even edit the BIOS?)


Any help is appreciated. Thank you!

Link to comment
Share on other sites

  • 1 month later...

Were you able to get the card working ?


I have a similar card from Gigabyte, WI07HT on a Dell Inspiron 1525.

The error I get is absolutely the same as yours.

I suspect that the EEPROM of the card is causing trouble.

The chip seems to be supported by the original kext and the card works flawlessly under Windows and Linux,

so the problem should be somewhere in the middle...


EEPROM dump from a card with the same chip (AR5424),

but from different manufacturer would be very usefull.

Link to comment
Share on other sites

Guest BuildSmart

You have two possible solutions.

I believe the issue you are having is that the initializer believes the card to be an apple card so it tries to set the card up this way, the core routines see this is not an apple card and use the generic core routines and these don't work with the data set up for the apple card or the firmware in these cards needs to be changed (upgraded/downgraded).


Let's assume rebranding is the solution, these are the steps


Make a note of the original subsystem ID's so you can restore them.


Find a Linux Live CD like Ubuntu 8.04.


Boot it up and build the madwifi tools.


Using the application ath_info from the tools you just built change the subsystem ID's for this device to (Vendor / Product) 0x106b / 0x004e.


Boot into OSX and see if the card behaves properly, if it does then you're all set, if it doesn't restore the original subsystem ID's and look for a solution to change the firmware of the device for either a newer or older version in an attempt to locate firmware that works.

Link to comment
Share on other sites

  • 2 years later...

  • Create New...