tree 36f00f66ea770071c30759525b0688d607ce53f6
parent 3f1d7b3fae5bb0ed6388bea703fc065b6fa291fb
author Vu Pham <vuhuong@nvidia.com> 1730830842 -0600
committer Vu Pham <vuhuong@nvidia.com> 1736460097 +0000

Detect how many address bytes needed for a given EEPROM memory

Introduce different modes to detect how many address byte(s) needed
for a given EEPROM device.

MODE_1:
-------
The existing upstream function isDevice16Bit() bases on sending
1-byte write operation (with a STOP condition) and 8 subsequent
1-byte read operations with SINGLE byte address.

1. This MODE_1 expects the following logic:
- if the device requires 1 address byte, it EXPECTS that the data
  will be read from a single location so 8 bytes read will be the
  same.
- if the device requires 2 address bytes, it EXPECTS that the data
  will be read from 8 DIFFERENT LOCATIONS and at least one byte
  read is different than 7 other reads.

2. Issue and potential issue with this MODE_1
- If any "2 address bytes" EEPROM from any vendor has the same data
  in all memory locations (0-7) the existing upstream function read,
  this device will be identified as "1 address byte" device.
- ONSEMI EEPROM (a 2 address bytes device) return the same data from
  the same single byte address read --> therefore, existing function
  wrongly identifies it as 1 byte address device.

MODE_2:
-------
The proposal MODE_2 changes to isDevice16Bit() sends 8 instructions
of 2-bytes write operation (WITHOUT a STOP condition ie. prohibited
STOP) followed by a 1-byte read operation. The proposed solution
fully complies with

IIC standard and should be applicable to any IIC EEPROM manufacturer.

| Start | SlaveAddr + W | 0x00 | 0x00 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
|-------|---------------|------|------|----------------------|-------|
--------------|-----------|------|
| Start | SlaveAddr + W | 0x00 | 0x01 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x02 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x03 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x04 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x05 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x06 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x07 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |

1. If the  device requires a single data byte, then it will always
load address 0x00, so the subsequent read byte will be the same for
all 8 instructions. The second byte on the write would be interpreted
as data byte, thus not modifying the address pointer.

2. If two address bytes are required, then the device will interpret
both bytes as addresses, thus reading from different addresses every
time, similar with what the existing function is using now.

Notes & reasons:
-----------------
There is no STOP condition after the second (potential) address byte.
A START condition must be sent after the second byte.
If STOP condition is sent, then the 1-byte address devices will start
internal write cycle, altering the EEPROM content which is not good.

This proposal MODE_2 suffers the same 1st issue (#2a) as before (what
if the EEPROM has the same data at all those addresses).
However, this proposal MODE_2 addresses the 2nd issue (#2b)
where existing MODE_1 upstream function EXPECTS that the data will
be read from 8 DIFFERENT LOCATIONS if the device requires 2 address
bytes. This expectation is the ambiguity (not standard defined) in
the IIC spec
(https://www.nxp.com/docs/en/user-guide/UM10204.pdf)

1. Section 3.1.10, Note 2 -> "All decisions on auto-increment or
decrement of previously accessed memory locations, etc., are taken by
the designer of the device."
Based on this note, the designer of every EEPROM has the "freedom"
to use whatever architecture considers appropriate and suitable to
process everyone of the two address bytes. There are no restrictions
on this.

Based on this, the others EEPROM (not ONSEMI EEPROM) auto-increment -
observed with one address byte sent instead of two - is a
manufacturer-specific behavior, and not standard defined.

2. Section 3.1.10, Note 1 -> "Combined formats can be used, for
example, to control a serial memory. The internal memory location
must be written during the first data byte. After the START
condition and slave address is repeated, data can be transferred."

This proposal MODE_2 implements this note. The memory location
referred herein is the address pointer, as being the first data
byte in I2C communication. Based on this note, EEPROM must update
this pointer immediately following this first address byte.

Tested:
--------
1. With ONSEMI I2C eeprom memory on Nvidia Bluefield-3 HCA
a. Without this patch or with this patch MODE_1

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Device not present (Requested sensor, data, or record not found)

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date        : Thu May 11 13:00:00 2023 UTC
Board Mfg             : Nvidia
Board Product         : Nvidia-BMCMezz
Board Serial          : MT2319XZ04K6
Board Part Number     : 900-9D3B6-00CV-AA0

b. With this patch MODE_2

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type          : Main Server Chassis
Chassis Part Number   : 900-9D3B6-00CV-AA0
Chassis Serial        : MT2319XZ04K6
Chassis Extra         : N/A
Chassis Extra         : N/A
Chassis Extra         : N/A
Chassis Area Checksum : OK
Board Mfg Date        : Thu May 11 13:00:00 2023 UTC
Board Mfg             : N/A
Board Product         : N/A
Board Serial          : MT2319XZ04K6
Board Part Number     : 900-9D3B6-00CV-AA0
Board Extra           : N/A
Board Area Checksum   : OK
Product Manufacturer  : N/A
Product Name          : N/A
Product Part Number   : 900-9D3B6-00CV-AA0
Product Serial        : MT2319XZ04K6
Product Asset Tag     : N/A
Product Extra         : N/A
Product Area Checksum : OK

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date        : Thu May 11 13:00:00 2023 UTC
Board Mfg             : Nvidia
Board Product         : Nvidia-BMCMezz
Board Serial          : MT2319XZ04K6
Board Part Number     : 900-9D3B6-00CV-AA0
Board Area Checksum   : OK

2. With other I2C eeprom memory on Nvidia Bluefield-3 HCA, and
   without this patch or with this patch on both MODE_1/MODE_2

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
 Chassis Type          : Main Server Chassis
 Chassis Part Number   : 900-9D3B4-00EN-EAA
 Chassis Serial        : MT2315XZ0599
 Chassis Extra         : N/A
 Chassis Extra         : N/A
 Chassis Extra         : N/A
 Chassis Area Checksum : OK
 Board Mfg Date        : Tue Apr 18 10:25:00 2023 UTC
 Board Mfg             : N/A
 Board Product         : N/A
 Board Serial          : MT2315XZ0599
 Board Part Number     : 900-9D3B4-00EN-EAA
 Board Extra           : N/A
 Board Area Checksum   : OK
 Product Manufacturer  : N/A
 Product Name          : N/A
 Product Part Number   : 900-9D3B4-00EN-EAA
 Product Version       : N/A
 Product Serial        : MT2315XZ0599
 Product Asset Tag     : N/A
 Product Extra         : N/A
 Product Area Checksum : OK

FRU Device Description : Nvidia-BMCMezz (ID 169)
 Board Mfg Date        : Tue Apr 18 10:25:00 2023 UTC
 Board Mfg             : Nvidia
 Board Product         : Nvidia-BMCMezz
 Board Serial          : MT2315XZ0599
 Board Part Number     : 900-9D3B4-00EN-EAA
 Board Area Checksum   : OK

Change-Id: I296c22334c919f4248fb3a7f19e384ce802cba17
Signed-off-by: Vu Pham <vuhuong@nvidia.com>