| dac2dfc3 | 05-Nov-2024 |
Vu Pham <vuhuong@nvidia.com> |
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 f
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>
show more ...
|
| a9804f46 | 08-Jul-2020 |
Andrew Jeffery <andrew@aj.id.au> |
docs: Avoid legality confusion over syntax error in JSON example
The illegality is the nesting, not the syntax error, so lets fix the
syntax.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-
docs: Avoid legality confusion over syntax error in JSON example
The illegality is the nesting, not the syntax error, so lets fix the
syntax.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Icf2d7f27e7b7cce7595a175c14dea2263841ddc8
show more ...
|