Re: [RFC PATCH 0/2] eeprom: at25: support Cypress FRAMs without device ID

[Christian Eggers <ceggers@arri.de>]

Hi Markus,

<disclaimer>I'm not maintaining the AT25 driver</disclaimer>

On Wednesday, 2 April 2025, 09:48:52 CEST, Markus Heidelberg wrote:
> Hi Christian,
> 
> On Tue, Apr 01, 2025 at 03:45:14PM +0200, Christian Eggers wrote:
> > 
> > I use the following FRAM device: Fujitsu mb85rs1mt. 
> > 
> > This FRAM is also not able to report its size (at least I didn't
> > try).
> 
> According to the datasheet there is a device ID, but with a different
> response compared to Cypress FRAMs. It wouldn't work without modifying
> the current implementation.
> 
> > I can use this FRAM with the following (Eeeprom) settings:
> > 
> > 		compatible = "fujitsu,mb85rs1mt", "atmel,at25";
> > 		reg = <0>;
> > 		spi-max-frequency = <30000000>;
> > 		/* mode0, uncomment for mode3 */
> > 		/*spi-cpha;
> > 		spi-cpol;*/
> > 
> > 		/* from the datasheet it seems that there is no page size for FRAM */
> > 		pagesize = <131072>;
> > 		size = <131072>;
> > 		address-width = <24>;
> > 
> > Is this what you are looking for? Of course, the "type" attribute 
> > reports "EEPROM" with this configuration, but my application don't care
> > about this.
> 
> This is what I started with, but I thought there has to be a reason that
> EEPROM and FRAM are distinguished in the driver (at25 and nvmem core)
> and I wanted to do it right. If not relevant now, maybe in the future.

maybe the "EEPROM" protocol used by at24 (I2C) and at25 (SPI) EEPROMs is
not smart enough to provide really useful detection of device capabilities.
At least I remember that I2C eeproms of different sizes require a different
number of bytes for addressing. AFAIK, using a wrong number of addressing bytes
may accidentally overwrite data on the device. If this is the same for SPI
eeproms / FRAMs, reliable auto-detection may be impossible or require
at least knowing the vendor in advance.

Flash (MTD) devices provide much more powerful methods for enumerating the
device's geometry/capabilities than eeprom/fram. But even for ONFI there are
extra tables for vendor/device specific workarounds. I am not sure whether
adding such stuff for at24/at25 devices is really worth the trouble...

> 
> Markus
> 

regards,
Christian