[U-Boot] [PATCH] powerpc/eeprom: update MAX_NUM_PORTS to adapt non-256-bytes EEPROM
Some boards use System EEPROM with 128-bytes instead of 256-bytes. Since we regard 256-bytes EEPROM as standard EEPROM with default value for MAX_NUM_PORTS. For those non-256-bytes EEPROM, we can redefine MAX_NUM_PORTS in board-specific file to override the default MAX_NUM_PORTS.
This patch doesn't impact on previous existing boards.
Signed-off-by: Shengzhou Liu Shengzhou.Liu@freescale.com --- board/freescale/common/sys_eeprom.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/board/freescale/common/sys_eeprom.c b/board/freescale/common/sys_eeprom.c index d2ed036..1b69315 100644 --- a/board/freescale/common/sys_eeprom.c +++ b/board/freescale/common/sys_eeprom.c @@ -34,7 +34,11 @@ #endif
#ifdef CONFIG_SYS_I2C_EEPROM_NXID +/* some boards with non-256-bytes EEPROM have special define */ +/* for MAX_NUM_PORTS in board-specific file */ +#ifndef MAX_NUM_PORTS #define MAX_NUM_PORTS 23 +#endif #define NXID_VERSION 1 #endif
On Fri, Aug 30, 2013 at 5:07 AM, Shengzhou Liu Shengzhou.Liu@freescale.com wrote:
#ifdef CONFIG_SYS_I2C_EEPROM_NXID +/* some boards with non-256-bytes EEPROM have special define */ +/* for MAX_NUM_PORTS in board-specific file */ +#ifndef MAX_NUM_PORTS #define MAX_NUM_PORTS 23 +#endif #define NXID_VERSION 1 #endif
I'll have to think about this. On one hand, this works. As long as the board-specific value of MAX_NUM_PORTS is valid, then it will work.
On the other hand, it's fragile and violates the specification. An NXID v1 EEPROM has the CRC at offset 0xFC. I'm just not sure it really matters.
York, I'm okay with this patch if you are. You're the one maintaining this code now. Is there anyone left at Freescale who cares about the integrity of the EEPROM specification?
On 08/30/2013 06:56 AM, Timur Tabi wrote:
On Fri, Aug 30, 2013 at 5:07 AM, Shengzhou Liu Shengzhou.Liu@freescale.com wrote:
#ifdef CONFIG_SYS_I2C_EEPROM_NXID +/* some boards with non-256-bytes EEPROM have special define */ +/* for MAX_NUM_PORTS in board-specific file */ +#ifndef MAX_NUM_PORTS #define MAX_NUM_PORTS 23 +#endif #define NXID_VERSION 1 #endif
I'll have to think about this. On one hand, this works. As long as the board-specific value of MAX_NUM_PORTS is valid, then it will work.
On the other hand, it's fragile and violates the specification. An NXID v1 EEPROM has the CRC at offset 0xFC. I'm just not sure it really matters.
We need to verify the CRC is still valid.
York, I'm okay with this patch if you are. You're the one maintaining this code now. Is there anyone left at Freescale who cares about the integrity of the EEPROM specification?
Some many boards pop up from different design groups. Unfortunately not all came to us to review. It is often too late when we find the design is different.
York
-----Original Message----- From: sun york-R58495 Sent: Wednesday, September 04, 2013 1:29 AM To: Timur Tabi Cc: Liu Shengzhou-B36685; U-Boot Mailing List Subject: Re: [U-Boot] [PATCH] powerpc/eeprom: update MAX_NUM_PORTS to adapt non- 256-bytes EEPROM
On 08/30/2013 06:56 AM, Timur Tabi wrote:
On Fri, Aug 30, 2013 at 5:07 AM, Shengzhou Liu Shengzhou.Liu@freescale.com wrote:
#ifdef CONFIG_SYS_I2C_EEPROM_NXID +/* some boards with non-256-bytes EEPROM have special define */ +/* for MAX_NUM_PORTS in board-specific file */ #ifndef MAX_NUM_PORTS #define MAX_NUM_PORTS 23 +#endif #define NXID_VERSION 1 #endif
I'll have to think about this. On one hand, this works. As long as the board-specific value of MAX_NUM_PORTS is valid, then it will work.
On the other hand, it's fragile and violates the specification. An NXID v1 EEPROM has the CRC at offset 0xFC. I'm just not sure it really matters.
We need to verify the CRC is still valid.
It had been verified on P1010RDB-PB with 128 Bytes, The CRC is still at the end of EEPROM and is still valid.
-Shengzhou
York, I'm okay with this patch if you are. You're the one maintaining this code now. Is there anyone left at Freescale who cares about the integrity of the EEPROM specification?
Some many boards pop up from different design groups. Unfortunately not all came to us to review. It is often too late when we find the design is different.
York
participants (4)
-
Liu Shengzhou-B36685 -
Shengzhou Liu -
Timur Tabi -
York Sun