Re: [zd1211-devs] Shuttle PN18G; re-used USB device ID

2007-08-16 Thread Remco
 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 

Re: [zd1211-devs] Shuttle PN18G; re-used USB device ID

2007-08-15 Thread Ulrich Kunitz
 Vendor: Shuttle
 Model:  PN18G (although it doesn't seem to be marked as such)
 USB Device ID:  07b8:6001
 Chip:   ZD1211B
 RF: AL2230S
 
 The chip description from dmesg:
 
 [ 1378.268000] zd1211rw 5-6:1.0: zd1211b chip 07b8:6001 v4810 high 00-12-0e 
 AL2230S_RF pa0 -
 
 It is a USB device designed to be connected directly to a pin header or other
 internal connector.  It has the large coax antenna mount, and also provides an
 alternative U.FL connector that a pigtail may be attached to.

I know it, I have the older product in my Shuttle. (Actually this
was the device that started me to go into this.)

 Anyway, it looks like this is a re-use of a previously existing device ID.  I
 had to modify the driver to get it working (patch attached).

We have seen this now several times. Zydas/Atheros told us that
this shouldn't happen, because this was the only method, we have
been aware to distinguish between both products.


 I hope this is enough info to get this working in mainline.

Not really, we need to find another way to identify the chip.

 BTW, it would be nice if the driver printed an error message if a ZD1211 is
 assumed but the chip is actually a ZD1211B, or vice-versa.  It currently fails
 silently.  I'm not sure if there is a good way to determine at runtime what 
 kind
 of chip you are actually talking to ... ?

That's exactly the problem. The problem is also that resetting the
device doesn't work reliably. We need to work on it.

  static struct usb_device_id usb_ids[] = {
   /* ZD1211 */
   { USB_DEVICE(0x0ace, 0x1211), .driver_info = DEVICE_ZD1211 },
 - { USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211 },
 +/* Work-around for Shuttle PN18G, which re-uses this device ID: */
 + { USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211B },
   { USB_DEVICE(0x126f, 0xa006), .driver_info = DEVICE_ZD1211 },
   { USB_DEVICE(0x6891, 0xa727), .driver_info = DEVICE_ZD1211 },
   { USB_DEVICE(0x0df6, 0x9071), .driver_info = DEVICE_ZD1211 },

-- 
Uli Kunitz

-
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


Re: [zd1211-devs] Shuttle PN18G; re-used USB device ID

2007-08-15 Thread Forest Bond
On Wed, Aug 15, 2007 at 11:00:47PM +0200, Ulrich Kunitz wrote:
 Forest Bond wrote:
   I hope this is enough info to get this working in mainline.
  
   Not really, we need to find another way to identify the chip.
  
  It wouldn't be something you could find in /proc/bus/usb/devices, would it?
 
 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. If I have
 such code ready I would send it to you and I would need your dump. I
 happened to own the old PN18 and so we could compare the EEPROM
 contents and do something with this. But don't expect any working
 code before the weekend.

Ok.  I'm not in a huge rush, although it would be nice to see this work out
positively.  I'm available to help out however I can.

  Ah, so you can't use a EAFP/trial-and-error approach (and LBYL is not an
  option due to the chip not making any mechanism available by which it can be
  identified)?
 
 I don't want to try it, we had several problems with reloading
 issues.

Got it.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net


signature.asc
Description: Digital signature
-
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