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.