--- a/doc/FTDI-EEPROM-format	Tue Sep 26 04:29:54 2023 +0000
+++ b/doc/FTDI-EEPROM-format	Tue Sep 26 21:56:26 2023 +0000
@@ -292,25 +292,25 @@
 characters times 2 plus 2; this number is written into the first byte of the
 descriptor itself, in the least-significant half of the first 16-bit word.  The
 whole descriptor, consisting of this header word followed by UCS-2 character
-words, can be placed at any EEPROM location that isn't taken or reserved for
-something else, and there is a pointer to each of the 3 possible string
-descriptors from the fixed header structure at the beginning of the EEPROM.
+words, can be placed at any EEPROM location within the "acceptable" area (see
+below), and there is a pointer to each of the 3 possible string descriptors
+from the fixed header structure at the beginning of the EEPROM.
 
 Each of the 3 string pointers is one 16-bit word, structured as follows:
 
 lower byte:	EEPROM byte address where the descriptor starts
+		(see below regarding the most significant bit of this byte)
 upper byte:	total number of bytes in the descriptor, same as written
 		in the descriptor itself
 
 String placement quirk
 ----------------------
 
-It should be apparent from the above description that each string descriptor
-can be placed anywhere in the EEPROM, as long as that location doesn't clash
-with something else.  The most natural way is to put the manufacturer ID string
-right after the fixed config structure, then the product ID string and then the
-serial number string, if included - but FTDI's official tools *almost* follow
-this principle, with two quirks:
+Common sense says that the most natural way to pack the needed strings into the
+EEPROM is to put the manufacturer ID string right after the fixed config
+structure, then the product ID string and then the serial number string, if
+included.  However, the EEPROM structure generated by FTDI's official tools is
+slightly different:
 
 * In the case of 93C56 or 93C66 EEPROMs, FTDI's official tools skip 64 words
   (128 bytes) after the end of the chip-defined config structure and then place
@@ -321,11 +321,21 @@
   but the byte-address pointers to strings are written with the high bit set,
   as if the EEPROM were of 93C56 type.
 
-Our current ftee-gen* tools replicate these quirks, as they are essentially
-harmless.  The only downside of this design is that one cannot use a 93C56
-EEPROM to include longer strings - but designing a product with unnaturally
-long ID strings, so long that FTDI's official tools won't support them, seems
-like a bad idea.
+My (Mother Mychaela's) first guess was that these quirks were just a matter of
+FTDI's official tools being silly, and that those of us who write our own FOSS
+tools can put our strings anywhere in the EEPROM, as long as the location we
+pick doesn't conflict with something else.  However, experiments with real
+boards featuring an FT2232x chip and an EEPROM reveal that the chip is NOT happy
+when the most significant bit of the byte-address pointer to a string descriptor
+is cleared: it appears that the chip is returning some kind of garbage to the
+USB host when asked for the string descriptor in this case.  (I am using the
+vague language of "appears that" because I am not currently able to allocate
+the time to study the problem properly.)  Thus it appears that all strings MUST
+be located in the upper half of 93C56, and the quirk of setting the msb of byte
+address for 93C46 is also required.
+
+Our ftee-gen* tools replicate both of these quirks, thus the resulting EEPROM
+structure is the same as what the chip vendor's official tools produce.
 
 ftee-gen* tools: config file language
 =====================================