[PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data

[PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data

[Nishanth Menon]

The situation is similar to commit bf6376642fe8 ("board: ti: common:
board_detect: Fix EEPROM read quirk"). This is seen on a variant of
eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte
addressing and 2 byte addressing eeproms.

Unlike the am335x (ti_i2c_eeprom_am_get) and dra7
(ti_i2c_eeprom_dra7_get) which use constant data structure which allows
us to do a complete read of the data, the
am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic.

This removes the option of being able to read the complete eeprom data
in one single shot.

Fortunately, on the I2C bus, we do see the following behavior: In 1
byte mode, if we attempt to read the first header data yet again, the
misbehaving 2 byte addressing device acts in constant addressing mode
which results in the header not matching up and follow on attempt at 2
byte addressing scheme grabs the correct data.

This costs us an extra ~3 milliseconds, which is a minor penalty
compared to the consistent image support we need to have.

Reported-by: Jason Kridner <jkridner@beagleboard.org>
Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.")
Signed-off-by: Nishanth Menon <nm@ti.com>
---

BeagleBone-AI64 logs with this patch:
With 1 byte addressing eeproms : https://www.irccloud.com/pastebin/XRjFVW82/
With quirky 2 byte addressing eeproms: https://www.irccloud.com/pastebin/eCQugpP6/

Wave capture of the quirky 2 byte addressing with this patch:
	https://pasteboard.co/bcNQyj3MVOpG.png

 board/ti/common/board_detect.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 9fa7b7beb63f..b959041cd22f 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -444,6 +444,16 @@ int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int dev_addr,
 	if (rc)
 		return rc;
 
+	/*
+	 * Handle case of bad 2 byte eeproms that responds to 1 byte addressing
+	 * but gets stuck in const addressing when read requests are performed
+	 * on offsets. We re-read the board ID to ensure we have sane data back
+	 */
+	rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC,
+			       sizeof(board_id), (uint8_t *)&board_id);
+	if (rc)
+		return rc;
+
 	if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) {
 		pr_err("%s: Invalid board ID record!\n", __func__);
 		return -EINVAL;
-- 
2.31.1

Re: [PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

On Wed, Sep 21, 2022 at 08:38:42AM -0500, Nishanth Menon wrote:

> The situation is similar to commit bf6376642fe8 ("board: ti: common:
> board_detect: Fix EEPROM read quirk"). This is seen on a variant of
> eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte
> addressing and 2 byte addressing eeproms.
> 
> Unlike the am335x (ti_i2c_eeprom_am_get) and dra7
> (ti_i2c_eeprom_dra7_get) which use constant data structure which allows
> us to do a complete read of the data, the
> am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic.
> 
> This removes the option of being able to read the complete eeprom data
> in one single shot.
> 
> Fortunately, on the I2C bus, we do see the following behavior: In 1
> byte mode, if we attempt to read the first header data yet again, the
> misbehaving 2 byte addressing device acts in constant addressing mode
> which results in the header not matching up and follow on attempt at 2
> byte addressing scheme grabs the correct data.
> 
> This costs us an extra ~3 milliseconds, which is a minor penalty
> compared to the consistent image support we need to have.
> 
> Reported-by: Jason Kridner <jkridner@beagleboard.org>
> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.")
> Signed-off-by: Nishanth Menon <nm@ti.com>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]