[ML-General] If your device just broke in the last few days it might be FTDI sabotage
Arthur
Arthur at cd-net.net
Fri Oct 24 12:59:27 CDT 2014
https://www.techdirt.com/articles/20141023/15502828928/microsoft-windows-update-completely-kill-devices-that-might-possibly-be-used-piracy.shtml
It looks like FTDI is deliberately bricking chips!
You can fix it, but you need an FTDI flash program, and need to know the
original chip PID.
Quote from an AC that seems to know what's going on:
There's no doubt they did it on purpose. Someone reverse-engineered the
bricking routine from the driver. It*unconditionally* writes 0 to the PID
and a matching value to the checksum, but does so in a specific way that
fails to write on genuine parts*.
There's no legitimate purpose for the bricking routine. It's a no-operation
on genuine parts. It's not "something useful the driver does which happens
to do the wrong thing on non-genuine parts". The only possible explanation
for the existence of that routine is to zero the PID on counterfeit or
compatible parts**.
* From what I could understand, the genuine parts can only write to the
EEPROM in 32-bit units, sent as a pair of 16-bit units. The bricking code
sent only one of the 16-bit units, so the write never happened. The
compatible parts write each 16-bit unit as it's received, so the write
happened.
** My guess as to why they only erased the PID, and not the VID: due to
word alignment, if they erased the VID it would happen even on genuine
parts. Luckly, this makes it easier to recover: if the VID is FTDI and the
PID is zero, it's a part which used to have a PID of 6001 but was bricked.
The Linux driver has been patched to recognize a bricked part as a valid
FTDI part.
Sincerely,
Arthur Moore
(256) 277-1001
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.makerslocal.org/pipermail/general/attachments/20141024/762e5bf9/attachment.html>
More information about the General
mailing list