I can not believe Intel would tool up different production lines for each of the different OEMs, to make what is essentially the same card (except for how each OEM has decided to implement the LEDs on each of their laptops). That kind of thing is much better done in software - Generic hardware is cheap.
The LEDs on the various Intel 2200BG cards are controlled by the driver, W22N51.SYS (at least under XP). This is a common driver which works for all the OEM cards, and detects which card is present dependent on a byte on the wireless cards EPROM (offset 0x4A). This byte has the following values:
00 = OEM STANDARD (INTEL)
01 = OEM DELL
02 = OEM FUJITSU
03 = OEM IBM
04 = OEM HP
When the driver starts it first calls a routine ldControlInit, which assumes a default standard Intel card. In particular this sets up a structure LdCtrl (LED Control) which is used to determine how the various LEDs are controlled(!). This structure is then passed into the various LED control routines (the driver writer appears to have a problem spelling, or perhaps just typing, the word Control sometimes. Perhaps his N key wasn't working
):
ldCotrolStart
ldCotrolStop
ldControlShutdown
ldCotrolSetOemType
ldCotrolSetLinkUp
ldCotrolSetLinkLedOn
ldCotrolSetLinkLedOff
ldCotrolSetActivityLedOff
ldControlSetAllLedsOff
All of these routines are fairly easy to locate in the source, as they all have very verbose debug output which can be enabled (anyone know how and where it gets put?) and hence litteral strings are dotted around all over the place (helpfully just before each routine they are used in).
Of particular interest is ldCotrolSetOemType. This reads byte 0x4A from the EPROM and changes values in the LdCtrl structure as required. The structure has then following format (driver version 80012-9000):
Offset Contents
000000C0 - On bit values for the ACTIVITY LED
000000C4 - Off bit mask for the ACTIVITY LED
000000C8 - On bit values for the LINK LED
000000CC - Off bit mask for the LINK LED
000000D0 - Unknown?
000000D4 - LED on blink time (ms)
000000D8 - LED off blink time (ms)
The values set for the various OEMs (by ldCotrolSetOemType) are:
000000C0 000000C4 000000C8 000000CC 000000D0 000000D4 000000D8
INTEL 00000010 FFFFFFEF 00000020 FFFFFFDF 00300004 00000BB8 0000012C
DELL 00000020 FFFFFFDF 00000010 FFFFFFEF -------- -------- --------
FUJITSU -------- -------- -------- -------- -------- -------- --------
IBM 01010000 FFFEFFFF 01010000 FFFEFFFF 00301100 00001450 00001388
HP -------- -------- -------- -------- -------- -------- --------
Note that dashes just mean that the OEM uses the standard (Intel) defaults setup previously in ldControlInit. Also note that driver software explicitly does not blink the Dell or HP LEDs.
There is also a registry setting, "LedEnable", which has to be 1 to enable the Led controller. Hover it would appear that the default value (if the registry setting is not present), is 1 anyway. So this registry setting serves only to disable the LED if required (by adding the key and setting it to zero). I *think* this gets read from one of the subkeys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}
Note HP and FUJITSU use the standard INTEL LED assignments (very sensible). I assume therefore that INTEL cards are a direct like-for-like replacement in either HP or FUJITSU hardware. DELL on the other hand appear to have got their LEDs round the opposite way to INTEL (silly, but would still work). However the bit positions for IBM cards are completely different from the other vendors?????
It appeared to be a simple matter of hacking the ldControlInit routine so it sets the bit values and masks up for an IBM card, or alternatively change the ldCotrolSetOemType routine JMP table to assume IBM (or whatever) when it sees an INTEL card flag in the EPROM.
Unfortunately neither of these two stratergies (despite trying many different variations) seem to work. The driver and card still come up, and the RF works. Just no LEDs. Please note that I have also patched and flashed the BIOS on my T40, just in case there is some interaction between the BIOS 1802 message disable and the Embedded controller which is disabling the LEDs - Still nada.
There is also a whole lot of firmware (in Intel HEX format) embedded in the driver (for uploading to the card). I haven't had a go at extracting this yet, but that is going to be my next point of attack. To me it seems the only thing remaining is that there is some dependancy between the driver and the firmware which controls the LED, and the firmware is making its own, independent, check on the card hardware version.
Anyway, HTHaL.
Where do we go from here....?
Facebook
Twitter