AT24/Linux driver caps page writes at 128 B (M24M02DR needs 256 B)

[kishoresmart]

Hardware / DT:

I’m using ST M24M02DR (2 Mbit I²C EEPROM, page size 256 bytes, write cycle ~10 ms per byte/page) at 400 kHz. Device tree:

eeprom@50 {
    compatible = "st,m24m02-dr", "atmel,24c2048";
       reg = <0x50>;
    pagesize = <256>;
    num-addresses = <4>;
}

Per ST’s datasheet, page size is 256 bytes and both byte write and page write complete within ~10 ms. But always kernel is detecting as 128 bytes/write

"[ 2.233319] at24 1-0050: 262144 byte 24c2048 EEPROM, writable, 128 bytes/write"

Observation in Linux driver (at24):

In drivers/misc/eeprom/at24.c, the driver uses an I/O transfer limit (at24_io_limit) to avoid holding the I²C bus for too long. That limit is 128 bytes, enforced as a power-of-two so writes align with pages:

/*

* ... With a 100 kHz I2C clock, one 256 byte read takes about 1/43 second ...

* This value is forced to be a power of two so that writes align on pages.

*/

As a result, even if pagesize = <256>, the driver will chunk writes at min(pagesize, at24_io_limit) = 128, never issuing 256‑byte page writes.

Problem:

On M24M02DR, if the kernel keeps sending 128‑byte chunks, I end up with two write cycles per page instead of one, and EEPROM might consider it as byte write effectively halving write throughput. The device itself supports 256‑byte page writes at 400 kHz and 1 MHz.

Questions:

1. Is there a recommended way (from ST’s side) to ensure the Linux at24 driver performs 256‑byte page writes on M24M02DR?
2. Are there any caveats with longer transfers (e.g., ACK polling behavior, bus stretch) specific to M24M02DR when using a full 256‑byte page write?

[Peter BENSCH]

Welcome @kishoresmart, to the community!

The question is more of a general question for the Linux kernel and its maintainers than one that STMicroelectronics can answer. I'll give it a try anyway:

The 128-byte limit was introduced to prevent bus overload of the system. At that time, EEPROMs with smaller page sizes were very common.

If you still want to work with a page size of 256 bytes for reasons of higher throughput, you must first check whether your kernel supports at24_io_limit as a module parameter.

• If this is not the case, the #define in at24.c must be modified and the kernel module recompiled.
• However, if your kernel supports the parameter, you could set the driver via Bash with
  modprobe at24 at24_io_limit=256
  or via the corresponding kernel parameter during boot.

Your second question mainly relates to the first reason mentioned: bus problems can certainly occur if you work with larger page sizes than the original 128 bytes, which can potentially hinder the system considerably more than sticking to two transfers per page. Ultimately, in your specific case, you will have to determine for yourself what the best approach is for you.

Hope that helps?

Regards
/Peter

[kishoresmart]

Thank you, Peter, for the response. I think changing the driver code could work, but that's not recommended. However, I have a question about the M24M02DR—I hope this is the right place to ask.

My question is: When I write 128 bytes instead of the full page size of 256 bytes, does the EEPROM consider it as a byte write? 

Also, is there a difference between page read and byte read operations? I believe reads should work at the same speed regardless of size, but I'm asking because I noticed in the kernel code that it performs page reads when I try to read more than the page size.

[Peter BENSCH]

A page write can comprise 1...256 bytes in the M24M02DR, as described in section 5.1.2 of the data sheet, whereby this byte block is written from the specified address. If the kernel writes 128-byte chunks and writes them per page from the beginning and middle of the page, two page writes are required.

There are indeed differences between page reads and byte reads, as the M24 I2C EEPROMs require a lot of overhead in the form of address data for each data transfer. If bytes are addressed as pages, this overhead only needs to be sent for the first byte of the page; the remaining bytes are automatically incremented internally. This is probably why the kernel uses page reads when more than one page needs to be read.

However, I would like to point out that the M24M02DR is already set to NRND (Not Recommended for New Design), so you should take a look at the possible alternative M24M02E-F.

Regards
/Peter