Unlike FT2232x devices with external EEPROMs, an FT232R device is not expected
to ever have a blank EEPROM in normal usage: these chips have their EEPROM
built in, and FTDI ships them with this internal EEPROM already programmed.
It may be possible to create a "blank" EEPROM by explicitly programming 0xFFFF
into every word, but it would be an unnatural scenario, and I (Mother Mychaela)
do not currently have an FT232R device on which I can experiment: I don't have
an FT232R device which is not valuable and which is not already bricked.

I have read out the EEPROM content from the two specimen I did have available:
FT232R-specimen1 came from a no-name ebay-sourced FT232RL breakout board;
FT232R-specimen2 came from George UberWaves' "FTDI Professional" USB-serial
cable with OsmocomBB branding.  Specimen 2 is probably a genuine FT232RL chip
(I remember George telling me that he went out of his way to procure genuine
FTDI chips after having been burned by FTDI's Winblows drivers screwing around
with close-but-not-perfect clones), but specimen 1 is suspected to be one of
those less-than-perfect clones: the serial number string was programmed to
"00000000", whereas FTDI supposedly program true per-unit serial numbers.

The only diffs between FT232R-specimen1 and FT232R-specimen2 are the just-
mentioned serial number string (specimen 2 has it set to "A9031HG6", which looks
like a real per-unit serial number), two non-understood "garbage" words after
the last string, and of course the checksum.

The unit that was specimen 1 (the suspected fake) is now bricked: when I tried
to program my own EEPROM config generated with ftee-gen232r, the resulting
EEPROM content became a bitwise AND between the previous image and the new one,
as if the "EEPROM" is not really an erasable memory, but one of OTP kind where
ones can be turned into zeros, but not the other way around.  I am not willing
to experiment on the specimen 2 chip because it is part of a valuable cable
assembly which I don't want to risk bricking, so I will need to order more
sacrificial hardware and wait for it to arrive before I can experiment further.