FreeCalypso > hg > fc-usbser-tools
comparison doc/FTDI-EEPROM-tools @ 48:9cfe3223fbf8
doc/FTDI-EEPROM-tools: document -d options
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 11 Sep 2023 03:58:41 +0000 |
parents | f548ae912622 |
children | 930bd5316d56 |
comparison
equal
deleted
inserted
replaced
47:b6a5ee85c6a3 | 48:9cfe3223fbf8 |
---|---|
292 | 292 |
293 ftee-mkblank | fteeprom-prog <device-selector> -- blank a 93C46 EEPROM | 293 ftee-mkblank | fteeprom-prog <device-selector> -- blank a 93C46 EEPROM |
294 ftee-mkblank -b | fteeprom-prog <device-selector> -- blank a 93C56 EEPROM | 294 ftee-mkblank -b | fteeprom-prog <device-selector> -- blank a 93C56 EEPROM |
295 ftee-mkblank -B | fteeprom-prog <device-selector> -- blank a 93C66 EEPROM | 295 ftee-mkblank -B | fteeprom-prog <device-selector> -- blank a 93C66 EEPROM |
296 | 296 |
297 USB replug after EEPROM programming or erasure | 297 Unbinding of ftdi_sio ttyUSBx devices |
298 ============================================== | 298 ===================================== |
299 | 299 |
300 Unlike fteeprom-read, our fteeprom-prog and fteeprom-erase utilities do command | 300 When invoked without any options, current versions of fteeprom-prog and |
301 the kernel's ftdi_sio driver to unbind. On single-channel devices the effect | 301 fteeprom-erase do NOT unbind the kernel's ftdi_sio driver from any of the chip's |
302 is that the sole ttyUSB character device associated with the given USB device | 302 interfaces, thus none of the associated ttyUSB devices disappear. This behavior |
303 disappears; on multichannel devices the effect is that ttyUSB corresponding to | 303 can be modified as follows: |
304 Channel A disappears, while Channel B ttyUSB device remains. In order to bring | 304 |
305 back the bumped-off ttyUSB device, and in order to make the FTDI chip itself | 305 * Both fteeprom-prog and fteeprom-erase support -d1, -d2 and -d4 options. These |
306 reread and apply the new EEPROM config, you have to physically unplug and replug | 306 options instruct the tool to command the kernel to unbind from one, two or |
307 the USB device. | 307 four interfaces on the target chip - they should be used with FT232x, FT2232x |
308 | 308 and FT4232x, respectively. |
309 Why is physical plug/unplug manipulation needed, why can't we command the needed | 309 |
310 effect via software? As it turns out, there are no *valid* reasons why it can't | 310 * fteeprom-prog running with -r option (FT232R special mode) and no -d options |
311 be done - but we are not currently able to do so because Linux kernel USB | 311 defaults to -d1. This default was made because -r option is intended only for |
312 maintainers are being pricks and won't support functionality that doesn't fit | 312 FT232R, which is known to be a single-channel chip, and the special magic |
313 into their worldview. Given that Harald Welte discovered this problem back in | 313 sequence is invasive/disruptive to normal UART operation, hence it isn't |
314 2017: | 314 really compatible with ttyUSB sticking around. If you are a hacker and you |
315 | 315 really know what you are doing, you can defeat this logic with -r -d0. |
316 https://laforge.gnumonks.org/blog/20170524-usb-port-powercycle/ | 316 |
317 https://marc.info/?l=linux-usb&m=149557709602259&w=2 | 317 Please refer to Replug-after-EEPROM-write article for additional notes. |
318 | |
319 (the thread shows Harald's good-faith attempt to reason with those pricks and | |
320 their dismissive responses) and given my own (Mother Mychaela's) sour experience | |
321 with trying to get a simple patch into ftdi_sio (adding support for a quirk- | |
322 requiring FT2232x-based hardware device), the situation with Linux currently | |
323 looks hopeless. |