> I don't think so, I'm thinking more specific entries in the
> EEPROM. We would need a debug version that dumps the EEPROM before
> we load the firmware. We will have to find data at some offset,
> which reliably would tell us, whether we deal with a ZD1211B
> instead of a ZD1211. Just classical reverse engineering. ...
>
Hopefully this will help. I don't really know the zd1211rw code so I'm not
sure if / how the following might fit.
I seem to be able to make my ZD1211 appear as a ZD1211B.
I used some code I worked on more then 1.5 year ago but it all boils down to
changing the WS11Ub firmware data and using the firmware/EEPROM writing code
that was originally in the vendor driver. (I don't recall which version of
the vendor driver I used as a basis but it's some code that I don't expect to
have changed)
I accomplished the following:
1) Use my code to write WS11Ub data with a ZD1211B product ID (1215) and a
bogus version (4331) to my ZD1211 device.
Logging excerpts from loading the zd1211rw driver after this "firmware update"
show it's detected as a ZD1211B:
usb 1-2: print_id() 0ace:1215 v4331 high
usb 1-2: request_fw_file() fw name zd1211/zd1211b_ub
usb 1-2: firmware version 0x4810 and device bootcode version 0x4331 differ
usb 1-2: request_fw_file() fw name zd1211/zd1211b_ur
usb 1-2: upload_code() transfer size 3584
usb 1-2: upload_code() firmware confirm return value 0x01
usb 1-2: upload_code() transfer size 3720
usb 1-2: upload_code() firmware confirm return value 0x01
usb 1-2: request_fw_file() fw name zd1211/zd1211b_uphr
usb 1-2: upload_code() transfer size 4096
usb 1-2: upload_code() transfer size 1024
usb 1-2: upload_code() firmware confirm return value 0x01
zd1211rw 1-2:1.0: RF2959 is currently not supported for ZD1211B devices
I didn't actually try to use it for WLAN at this point.
2) Use my code to write the original WS11Ub data to my ZD1211 device.
Logging excerpts from loading the zd1211rw driver after this "firmware update"
show it's detected as a ZD1211:
print_id() 0ace:1211 v4330 high
usb 1-2: request_fw_file() fw name zd1211/zd1211_ub
usb 1-2: upload_firmware() firmware device id 0x4330 is equal to the actual
device id
usb 1-2: request_fw_file() fw name zd1211/zd1211_uphr
usb 1-2: upload_code() transfer size 4096
usb 1-2: upload_code() transfer size 1024
usb 1-2: upload_code() firmware confirm return value 0x01
I could still use it for WLAN at this point.
After an update the MAC address appears as 00:00:55:66:66:66.
Unplug/replug of the device will show the original MAC.
The code I used is known as function "int zd1211_Download_IncludeFile(struct
zd1205_private *macp)" in file "zd1211.c" of the vendor driver.
The part executed in "if (macp->release != EEPVer){ ... } " is responsible
for updating the data in the device.
I determined the following by scanning the WS11Ub data of the vendor driver
for things like vendor ID, product ID, HW version.
I annotated the interesting spots in the WS11Ub data:
T) trigger that determines whether a firmware update will run or not
M) default MAC address ???
U) USB vendor/product ID/HW version (Note: the ZD1211B data uses a ZD1211
product ID 0x1211, this should probably be 0x1215)
Annotated WS11Ub data: (only the first 128 bytes)
for ZD1211:
0x00, 0xF0, 0x66, 0xFE, 0x67, 0xFE, 0x68, 0xFE,
0x69, 0xFE, 0x6A, 0xFE, 0x6B, 0xFE, 0x6C, 0xFE,
0x6D, 0xFE, 0x09, 0x63, 0xD6, 0x79, 0x57, 0x94,
0xD1, 0xD4, 0x0A, 0x95, 0x17, 0xF8, 0xD1, 0xD4,
0x0A, 0x95, 0xD2, 0x07, 0x00, 0xEE, 0xC1, 0xD4,
0x00, 0xEE, 0x0F, 0x9F, 0x95, 0xF8, ==> 0x30, 0x43, <== T)
0x10, 0x00, 0x0D, 0x00, 0x00, 0x00, ==> 0x00, 0x00, M)
0x55, 0x66, 0x66, 0x66, <== 0x00, 0x00, 0x6A, 0x6A, M)
0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A,
0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0xB2, 0xB2,
0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2,
0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xFF, 0x07,
0x00, 0x00, 0x12, 0x01, 0x00, 0x02, 0xFF, 0xFF,
0xFF, 0x40, ==> 0xCE, 0x0A, 0x11, 0x12, 0x30, 0x43, <== U)
0x10, 0x20, 0x00, 0x01, 0x04, 0x03, 0x09, 0x04,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0x52,
for ZD1211B:
0x00, 0xF0, 0x66, 0xFE, 0x67, 0xFE, 0x68, 0xFE,
0x69, 0xFE, 0x6A, 0xFE, 0x6B, 0xFE, 0x6C, 0xFE,
0x6D, 0xFE, 0x09, 0x63, 0xD6, 0x79, 0x57, 0x94,
0xD1, 0xD4, 0x0A, 0x95, 0x17, 0xF8, 0xD1, 0xD4,
0x0A, 0x95, 0xD2, 0x07, 0x00, 0xEE, 0xC1, 0xD4,
0x00, 0xEE, 0x0F, 0x9F, 0x95, 0xF8, ==> 0x10, 0x48, <== T)
0x10, 0x00, 0x0D, 0x00, 0x00, 0x00, ==> 0x00, 0x00, M)
0x55, 0x66, 0x66, 0x66, <== 0x00, 0x00, 0x6A, 0x6A, M)
0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A,
0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0xB2, 0xB2,
0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2,
0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xFF, 0x07,
0x00, 0x00, 0x12, 0x01, 0x00, 0x02, 0xFF, 0xFF,
0xFF, 0x40, ==> 0xCE, 0x0A, 0x11, 0x12, 0x10, 0x48, <== U)
0x10, 0x20, 0x00, 0x01, 0x04, 0x03, 0x09, 0x04,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0x52,
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
