FreeCalypso > hg > fc-usbser-tools

comparison doc/FTDI-EEPROM-format @ 81:8b0a01b19fb9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/FTDI-EEPROM-format: update for the discovery of FTDI chips enforcing the requirement of using upper addresses for strings
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 26 Sep 2023 21:56:26 +0000
parents f14d04e4d85d
children
comparison
equal deleted inserted replaced
80:930bd5316d56 81:8b0a01b19fb9
290 290
291 The total number of bytes in a string descriptor is the number of UCS-2 291 The total number of bytes in a string descriptor is the number of UCS-2
292 characters times 2 plus 2; this number is written into the first byte of the 292 characters times 2 plus 2; this number is written into the first byte of the
293 descriptor itself, in the least-significant half of the first 16-bit word. The 293 descriptor itself, in the least-significant half of the first 16-bit word. The
294 whole descriptor, consisting of this header word followed by UCS-2 character 294 whole descriptor, consisting of this header word followed by UCS-2 character
295 words, can be placed at any EEPROM location that isn't taken or reserved for 295 words, can be placed at any EEPROM location within the "acceptable" area (see
296 something else, and there is a pointer to each of the 3 possible string 296 below), and there is a pointer to each of the 3 possible string descriptors
297 descriptors from the fixed header structure at the beginning of the EEPROM. 297 from the fixed header structure at the beginning of the EEPROM.
298 298
299 Each of the 3 string pointers is one 16-bit word, structured as follows: 299 Each of the 3 string pointers is one 16-bit word, structured as follows:
300 300
301 lower byte: EEPROM byte address where the descriptor starts 301 lower byte: EEPROM byte address where the descriptor starts
302 (see below regarding the most significant bit of this byte)
302 upper byte: total number of bytes in the descriptor, same as written 303 upper byte: total number of bytes in the descriptor, same as written
303 in the descriptor itself 304 in the descriptor itself
304 305
305 String placement quirk 306 String placement quirk
306 ---------------------- 307 ----------------------
307 308
308 It should be apparent from the above description that each string descriptor 309 Common sense says that the most natural way to pack the needed strings into the
309 can be placed anywhere in the EEPROM, as long as that location doesn't clash 310 EEPROM is to put the manufacturer ID string right after the fixed config
310 with something else. The most natural way is to put the manufacturer ID string 311 structure, then the product ID string and then the serial number string, if
311 right after the fixed config structure, then the product ID string and then the 312 included. However, the EEPROM structure generated by FTDI's official tools is
312 serial number string, if included - but FTDI's official tools *almost* follow 313 slightly different:
313 this principle, with two quirks:
314 314
315 * In the case of 93C56 or 93C66 EEPROMs, FTDI's official tools skip 64 words 315 * In the case of 93C56 or 93C66 EEPROMs, FTDI's official tools skip 64 words
316 (128 bytes) after the end of the chip-defined config structure and then place 316 (128 bytes) after the end of the chip-defined config structure and then place
317 the manufacturer ID string after this gap. The byte-address pointer to each 317 the manufacturer ID string after this gap. The byte-address pointer to each
318 string descriptor always has its high bit set as a result of this quirk. 318 string descriptor always has its high bit set as a result of this quirk.
319 319
320 * In the case of 1024-bit EEPROMs (93C46 or FT232R internal) nothing is skipped, 320 * In the case of 1024-bit EEPROMs (93C46 or FT232R internal) nothing is skipped,
321 but the byte-address pointers to strings are written with the high bit set, 321 but the byte-address pointers to strings are written with the high bit set,
322 as if the EEPROM were of 93C56 type. 322 as if the EEPROM were of 93C56 type.
323 323
324 Our current ftee-gen* tools replicate these quirks, as they are essentially 324 My (Mother Mychaela's) first guess was that these quirks were just a matter of
325 harmless. The only downside of this design is that one cannot use a 93C56 325 FTDI's official tools being silly, and that those of us who write our own FOSS
326 EEPROM to include longer strings - but designing a product with unnaturally 326 tools can put our strings anywhere in the EEPROM, as long as the location we
327 long ID strings, so long that FTDI's official tools won't support them, seems 327 pick doesn't conflict with something else. However, experiments with real
328 like a bad idea. 328 boards featuring an FT2232x chip and an EEPROM reveal that the chip is NOT happy
329 when the most significant bit of the byte-address pointer to a string descriptor
330 is cleared: it appears that the chip is returning some kind of garbage to the
331 USB host when asked for the string descriptor in this case. (I am using the
332 vague language of "appears that" because I am not currently able to allocate
333 the time to study the problem properly.) Thus it appears that all strings MUST
334 be located in the upper half of 93C56, and the quirk of setting the msb of byte
335 address for 93C46 is also required.
336
337 Our ftee-gen* tools replicate both of these quirks, thus the resulting EEPROM
338 structure is the same as what the chip vendor's official tools produce.
329 339
330 ftee-gen* tools: config file language 340 ftee-gen* tools: config file language
331 ===================================== 341 =====================================
332 342
333 The format of EEPROM config files read by our ftee-gen* tools is line-based. 343 The format of EEPROM config files read by our ftee-gen* tools is line-based.