Hi, Alan Stern wrote: > There is a field which _should_ indicate the firmware version: > bcdDevice. But the value is 0.01, which isn't helpful since the > last-sector bug was originally reported for devices with that same > value. > > In fact, the problem had already been fixed at the time it was > originally reported (in 2005!). But not everybody can upgrade their > firmware. See > > http://marc.info/?l=linux-usb-devel&m=111753034313487&w=2 Thanks for that, didn't read that posting before. >> It is definitely possible to >> determine the version though; the Prolific flashing program does that. I >> haven't looked at its code to see exactly how it talks to the enclosure. > > Maybe we could copy the algorithm. I don't know if it would be > worthwhile, though. I took a brief look at the flashing program code. It looks like it issues SCSI commands, which should make determining the firmware version relatively straightforward. Can you recommend any (free) Windows program for capturing/snooping SCSI commands and data sent/received to a device? That would help with figuring out how to determine the firmware version. (And should also allow users to backup the flash under Linux, maybe even erase and reflash too.) Based on a quick look at some of the code of ROMWriter2.3RS64.exe... Remember the USB vendor ID is 0x067B. The flashing program issues commands with CDB like this: F6 00 ?? ?? ?? ?? 06 7B 00 00 00 Valid combinations for CDB bytes 2-5 seem to be: 'UNLO' (ASCII) To "unlock" the chip's ROM. 00 00 00 00 To lock the chip's ROM After unlocking, it looks like the flash can be erased with a 6-byte command: E1 00 00 00 06 7B (Obviously, DON'T TRY THAT since it may "brick" the enclosure.) It's also worth noting that the Prolific site mentions that earlier firmware versions don't implement the flash locking feature. To update from an early firmware, you need to first update to an intermediate version (which uses an older flashing program), before you can use the later flashing program to update to the most recent code. So it might be that different command sequences would need to be sent to determine the firmware version, depending on the firmware version... :-/ Update: it looks like command 0xE0 is used to determine the firmware version. That command does not need to be preceded with a 0xF6 command. For my enclosure which has the latest firmware version "2006.04.20.149": # sg_raw --verbose --verbose --request=12 /dev/sg2 E0 00 00 00 06 7B open /dev/sg2 with flags=0x802 cdb to send: e0 00 00 00 06 7b SCSI Status: Good Sense Information: sense buffer empty Received 12 bytes of data: 00 06 7b 35 07 01 ff ff 00 06 04 14 95 .{5......... So, in the data returned: bytes 0-1: USB vendor ID bytes 2-3: USB product ID bytes 4-7: ??? bytes 8-11 are the firmware version: 06 -> 2006, 0x04 = 04, 0x14 = 20, 0x95 = 149. > It is possible for you to override the last-sector flag by providing a > module parameter for usb-storage: > > modprobe usb-storage quirks=0x067b:0x3507: > > should do it. Aha, thanks that would help a lot. -- Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
