Hi,
I finally found some time to dig into the ftdi eeprom handling.
On Tue, Jun 26, 2018 at 02:54:48PM +0200, Loic Poulain wrote:
> Most of FTDI's devices have an EEPROM which records FTDI devices
> configuration setting (e.g. the VID, PID, I/O config...) and user
> data. For example, FT232R and FTX chips have 128-byte and 2048-byte
> internal EEPROM respectively.
The "internal" qualifier here is crucial; only FT232R and FTX have
internal EEPROMs of a known size. Other device types use external
EEPROMs of varying sizes, and which need not even be populated.
And judging from the heuristics used by libftdi, there's no good (known)
way to determine the size of the external EEPROMs, which means that this
cannot be generalised. Note that handling external EEPROMS also implies
dealing with explicit EEPROM erase commands, which does not seem to fit
the proposed interface.
> This patch adds support for FTDI EEPROM read/write via USB control
> transfers and register a new nvm device to the nvmem core.
>
> This permits to expose the EEPROM as a sysfs file, allowing userspace
> to read/modify FTDI configuration and its user data without having to
> rely on a specific userspace USB driver.
So I have doubts about the usefulness of all of this.
- You cannot just write the EEPROM from user space without knowing the
device-specific layout.
- You also need to make sure to recalculate and update the checksum
stored in the final word.
- And for that you obviously need to know the EEPROM size (known for R
and FTX).
So in the end you still need something like libftdi to be able to do
anything useful with this. Also note that the layout and protocol for
handling the EEPROM is only available under NDA or is based on
reverse-engineering guess work. For example, it seems like for FT232R
you need to set a specific latency timer to be able to write the EEPROM
(reliably). And so on.
And as the consequences of getting this wrong may result in a bricked
device, I'm even more sceptical about this.
> Moreover, any upcoming new tentative to add CBUS GPIO support could
> integrate CBUS EEPROM configuration reading in order to determine
> which of the CBUS pins are available as GPIO.
The CBUS configuration is stored in just a couple of words at a known
offset and could easily be retrieved without depending on the nvmem
subsystem when needed.
As I assume fiddling with the EEPROM should be rare (e.g. done during
development or by hobbyists) and would still depend user-space tools
(e.g. for layouts, checksums and external EEPROMs), I think we should
just leave it all to user space to deal with.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
