Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-14 17:07:38 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/board/ti/common/board_detect.c

795 lines
19 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
// SPDX-License-Identifier: GPL-2.0+
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
/*
* Library to support early TI EVM EEPROM handling
*
* Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
* Lokesh Vutla
* Steve Kipisz
*/
#include <common.h>
common: Move old EEPROM functions into a new header These functions do not use driver model but are still used. Move them to a new eeprom.h header file. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-11-14 19:57:50 +00:00
#include <eeprom.h>
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:40:05 +00:00
#include <log.h>
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:39:56 +00:00
#include <net.h>
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
#include <asm/arch/hardware.h>
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
#include <asm/omap_common.h>
ti: common: board_detect: Introduce function to set the address length. Reading from the I2C EEPROM used typically requires using an address length of 2. However, when using DM for I2C the default address length used is 1. To fix this introduce a new function that allows the address length to be changed. The logic to do so was copied from cmd/i2c.c. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2017-04-20 15:25:44 +00:00
#include <dm/uclass.h>
env: Move env_set() to env.h Move env_set() over to the new header file. Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2019-08-01 15:46:51 +00:00
#include <env.h>
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
#include <i2c.h>
board: ti: beagleboneai: emmc read changes BeagleBoard.org BeagleBone AI rev A1 does not include a board identifier I2C EEPROM due to a design oversight. These boards have been put into production and are generally available now. The board identifier information, however, has been included in the second eMMC linear boot partition (/dev/mmcblk1boot1). This patch works by: * First, looking for a board identifier I2C EEPROM and if not found, * Then seeing if the boot mode matches BeagleBone AI with eMMC in the boot chain to make sure we don't enable eMMC pinmuxes on boards that don't support it, and * Finally, initializes the eMMC pins and reading the header. Signed-off-by: Jason Kridner <jdk@ti.com> Signed-off-by: Caleb Robey <c-robey@ti.com> Cc: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-02 14:17:25 +00:00
#include <mmc.h>
#include <errno.h>
#include <malloc.h>
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
#include "board_detect.h"
dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO Use CONFIG_IS_ENABLED() macro, which provides more convenient way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs for both SPL and U-Boot proper. CONFIG_IS_ENABLED(DM_I2C) expands to: - 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y', - 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y', - 0 otherwise. All occurences were replaced automatically using these bash cmds: $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-02-09 11:52:45 +00:00
#if !CONFIG_IS_ENABLED(DM_I2C)
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
/**
* ti_i2c_eeprom_init - Initialize an i2c bus and probe for a device
* @i2c_bus: i2c bus number to initialize
* @dev_addr: Device address to probe for
*
* Return: 0 on success or corresponding error on failure.
*/
static int __maybe_unused ti_i2c_eeprom_init(int i2c_bus, int dev_addr)
{
int rc;
if (i2c_bus >= 0) {
rc = i2c_set_bus_num(i2c_bus);
if (rc)
return rc;
}
return i2c_probe(dev_addr);
}
/**
* ti_i2c_eeprom_read - Read data from an EEPROM
* @dev_addr: The device address of the EEPROM
* @offset: Offset to start reading in the EEPROM
* @ep: Pointer to a buffer to read into
* @epsize: Size of buffer
*
* Return: 0 on success or corresponding result of i2c_read
*/
static int __maybe_unused ti_i2c_eeprom_read(int dev_addr, int offset,
uchar *ep, int epsize)
{
ti: remove usage of DM_I2C_COMPAT and don't disable DM_I2C in SPL DM_I2C_COMPAT is a compatibility layer that allows using the non-DM I2C API when DM_I2C is used. The goal is to eventually remove DM_I2C_COMPAT when all I2C "clients" have been migrated to use the DM API. This a step in that direction for the TI based platforms. Build tested with buildman: buildman -dle am33xx ti omap3 omap4 omap5 davinci keystone boot tested with: am335x_evm, am335x_boneblack, am335x_boneblack_vboot (DM version), am57xx_evm, dra7xx_evm, k2g_evm, am437x_evm Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:49 +00:00
return i2c_read(dev_addr, offset, 2, ep, epsize);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
}
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
#endif
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
/**
* ti_eeprom_string_cleanup() - Handle eeprom programming errors
* @s: eeprom string (should be NULL terminated)
*
* Some Board manufacturers do not add a NULL termination at the
* end of string, instead some binary information is kludged in, hence
* convert the string to just printable characters of ASCII chart.
*/
static void __maybe_unused ti_eeprom_string_cleanup(char *s)
{
int i, l;
l = strlen(s);
for (i = 0; i < l; i++, s++)
if (*s < ' ' || *s > '~') {
*s = 0;
break;
}
}
__weak void gpi2c_init(void)
{
}
static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr,
u32 header, u32 size, uint8_t *ep)
{
int rc;
dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO Use CONFIG_IS_ENABLED() macro, which provides more convenient way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs for both SPL and U-Boot proper. CONFIG_IS_ENABLED(DM_I2C) expands to: - 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y', - 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y', - 0 otherwise. All occurences were replaced automatically using these bash cmds: $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-02-09 11:52:45 +00:00
#if CONFIG_IS_ENABLED(DM_I2C)
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
struct udevice *dev;
struct udevice *bus;
rc = uclass_get_device_by_seq(UCLASS_I2C, bus_addr, &bus);
if (rc)
return rc;
ti: common: board_detect: Handle EEPROM probe more gracefully Use dm_i2c_probe() rather than i2c_get_chip() when trying to access board-detection EEPROM devices. This has the advantage of more gracefully handling the case when the EEPROM is not present by allowing to exit the function early rather than failing and outputting an error message on the I2C transactions that follow. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-07 07:45:53 +00:00
rc = dm_i2c_probe(bus, dev_addr, 0, &dev);
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
if (rc)
return rc;
/*
* Read the header first then only read the other contents.
*/
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
rc = i2c_set_chip_offset_len(dev, 1);
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
if (rc)
return rc;
board: ti: common: Handle the legacy eeprom address width properly Due to supply chain issues, we are starting to see a mixture of eeprom usage including the smaller 7-bit addressing eeproms such as 24c04 used for eeproms. These eeproms don't respond well to 2 byte addressing and fail the read operation. We do have a check to ensure that we are reading the alternate addressing size, however the valid failure prevents us from checking at 1 byte anymore. Rectify the same by falling through and depend on header data comparison to ensure that we have valid data. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:11 +00:00
/*
* Skip checking result here since this could be a valid i2c read fail
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
* on some boards that use 2 byte addressing.
* We must allow for fall through to check the data if 2 byte
board: ti: common: Handle the legacy eeprom address width properly Due to supply chain issues, we are starting to see a mixture of eeprom usage including the smaller 7-bit addressing eeproms such as 24c04 used for eeproms. These eeproms don't respond well to 2 byte addressing and fail the read operation. We do have a check to ensure that we are reading the alternate addressing size, however the valid failure prevents us from checking at 1 byte anymore. Rectify the same by falling through and depend on header data comparison to ensure that we have valid data. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:11 +00:00
* addressing works
*/
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
(void)dm_i2c_read(dev, 0, ep, size);
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
/* Corrupted data??? */
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
if (*((u32 *)ep) != header) {
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
/*
* read the eeprom header using i2c again, but use only a
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
* 2 byte address (some newer boards need this..)
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
*/
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
rc = i2c_set_chip_offset_len(dev, 2);
ti: common: Remove additional i2c read for board detection There shouldn't be a need to call additional i2c read if above failed already. Based on comment it should be enough to try to detect legacy boards which are mentioned in the comment. Fixes: 2463f6728e82 ("ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT") Fixes: 0bea813d0018 ("ARM: omap-common: Add standard access for board description EEPROM") Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-08-27 13:43:48 +00:00
if (rc)
return rc;
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
rc = dm_i2c_read(dev, 0, ep, size);
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
if (rc)
return rc;
}
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
if (*((u32 *)ep) != header)
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
return -1;
#else
u32 byte;
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
gpi2c_init();
rc = ti_i2c_eeprom_init(bus_addr, dev_addr);
if (rc)
return rc;
/*
* Read the header first then only read the other contents.
*/
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
byte = 1;
ti: common: board_detect: Set alen to expected value before i2c read In non DM I2C read operations the address length passed in during a read operation will be used automatically. However, in DM I2C the address length is set to a default value of one which causes problems when trying to perform a read with a differing alen. Therefore, before the first read in a series of read operations set the alen to the correct value. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2017-04-20 15:25:45 +00:00
board: ti: common: Handle the legacy eeprom address width properly Due to supply chain issues, we are starting to see a mixture of eeprom usage including the smaller 7-bit addressing eeproms such as 24c04 used for eeproms. These eeproms don't respond well to 2 byte addressing and fail the read operation. We do have a check to ensure that we are reading the alternate addressing size, however the valid failure prevents us from checking at 1 byte anymore. Rectify the same by falling through and depend on header data comparison to ensure that we have valid data. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:11 +00:00
/*
* Skip checking result here since this could be a valid i2c read fail
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
* on some boards that use 2 byte addressing.
* We must allow for fall through to check the data if 2 byte
board: ti: common: Handle the legacy eeprom address width properly Due to supply chain issues, we are starting to see a mixture of eeprom usage including the smaller 7-bit addressing eeproms such as 24c04 used for eeproms. These eeproms don't respond well to 2 byte addressing and fail the read operation. We do have a check to ensure that we are reading the alternate addressing size, however the valid failure prevents us from checking at 1 byte anymore. Rectify the same by falling through and depend on header data comparison to ensure that we have valid data. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:11 +00:00
* addressing works
*/
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
(void)i2c_read(dev_addr, 0x0, byte, ep, size);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
/* Corrupted data??? */
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
if (*((u32 *)ep) != header) {
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
/*
* read the eeprom header using i2c again, but use only a
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
* 2 byte address (some newer boards need this..)
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
*/
board: ti: common: board_detect: Do 1byte address checks first. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:12 +00:00
byte = 2;
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
rc = i2c_read(dev_addr, 0x0, byte, ep, size);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
if (rc)
return rc;
}
board: ti: common: board_detect: Fix EEPROM read quirk There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2022-08-23 16:05:34 +00:00
if (*((u32 *)ep) != header)
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
return -1;
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT The EEPROM reading in the board detection code is done through legacy I2C functions which on platforms using DM_I2C this functionality is provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms to use the board detection code without relying on CONFIG_DM_I2C_COMPAT go ahead and add an I2C handling implementation that directly uses the I2C DM functionality. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:47 +00:00
#endif
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
return 0;
}
board: ti: beagleboneai: emmc read changes BeagleBoard.org BeagleBone AI rev A1 does not include a board identifier I2C EEPROM due to a design oversight. These boards have been put into production and are generally available now. The board identifier information, however, has been included in the second eMMC linear boot partition (/dev/mmcblk1boot1). This patch works by: * First, looking for a board identifier I2C EEPROM and if not found, * Then seeing if the boot mode matches BeagleBone AI with eMMC in the boot chain to make sure we don't enable eMMC pinmuxes on boards that don't support it, and * Finally, initializes the eMMC pins and reading the header. Signed-off-by: Jason Kridner <jdk@ti.com> Signed-off-by: Caleb Robey <c-robey@ti.com> Cc: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-02 14:17:25 +00:00
int __maybe_unused ti_emmc_boardid_get(void)
{
int rc;
struct udevice *dev;
struct mmc *mmc;
struct ti_common_eeprom *ep;
struct ti_am_eeprom brdid;
struct blk_desc *bdesc;
uchar *buffer;
ep = TI_EEPROM_DATA;
if (ep->header == TI_EEPROM_HEADER_MAGIC)
return 0; /* EEPROM has already been read */
/* Initialize with a known bad marker for emmc fails.. */
ep->header = TI_DEAD_EEPROM_MAGIC;
ep->name[0] = 0x0;
ep->version[0] = 0x0;
ep->serial[0] = 0x0;
ep->config[0] = 0x0;
/* uclass object initialization */
rc = mmc_initialize(NULL);
if (rc)
return rc;
/* Set device to /dev/mmcblk1 */
rc = uclass_get_device(UCLASS_MMC, 1, &dev);
if (rc)
return rc;
/* Grab the mmc device */
mmc = mmc_get_mmc_dev(dev);
if (!mmc)
return -ENODEV;
/* mmc hardware initialization routine */
mmc_init(mmc);
/* Set partition to /dev/mmcblk1boot1 */
rc = mmc_switch_part(mmc, 2);
if (rc)
return rc;
buffer = malloc(mmc->read_bl_len);
if (!buffer)
return -ENOMEM;
bdesc = mmc_get_blk_desc(mmc);
/* blk_dread returns the number of blocks read*/
if (blk_dread(bdesc, 0L, 1, buffer) != 1) {
rc = -EIO;
goto cleanup;
}
memcpy(&brdid, buffer, sizeof(brdid));
/* Write out the ep struct values */
ep->header = brdid.header;
strlcpy(ep->name, brdid.name, TI_EEPROM_HDR_NAME_LEN + 1);
ti_eeprom_string_cleanup(ep->name);
strlcpy(ep->version, brdid.version, TI_EEPROM_HDR_REV_LEN + 1);
ti_eeprom_string_cleanup(ep->version);
strlcpy(ep->serial, brdid.serial, TI_EEPROM_HDR_SERIAL_LEN + 1);
ti_eeprom_string_cleanup(ep->serial);
cleanup:
free(buffer);
return rc;
}
ti: common: board_detect: Allow settings board detection variables manually In some situations the EEPROM used for board detection may not be programmed or simply programmed incorrectly. Therefore, it may be necessary to "simulate" reading the contents of the EEPROM to set appropriate variables used in the board detection code. This may also be helpful in certain boot modes where doing i2c reads may be costly and the config supports running only a specific board. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Franklin S Cooper Jr. <fcooper@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-06-16 22:25:04 +00:00
int __maybe_unused ti_i2c_eeprom_am_set(const char *name, const char *rev)
{
struct ti_common_eeprom *ep;
if (!name || !rev)
return -1;
ep = TI_EEPROM_DATA;
if (ep->header == TI_EEPROM_HEADER_MAGIC)
goto already_set;
/* Set to 0 all fields */
memset(ep, 0, sizeof(*ep));
strncpy(ep->name, name, TI_EEPROM_HDR_NAME_LEN);
strncpy(ep->version, rev, TI_EEPROM_HDR_REV_LEN);
/* Some dummy serial number to identify the platform */
strncpy(ep->serial, "0000", TI_EEPROM_HDR_SERIAL_LEN);
/* Mark it with a valid header */
ep->header = TI_EEPROM_HEADER_MAGIC;
already_set:
return 0;
}
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
int __maybe_unused ti_i2c_eeprom_am_get(int bus_addr, int dev_addr)
{
int rc;
struct ti_am_eeprom am_ep;
struct ti_common_eeprom *ep;
ep = TI_EEPROM_DATA;
ARM: DRA7: AMxx: Make sure that the SPL always reads the configuration EEPROM The bootrom may corrupt the area of SRAM used to store the ti_common_eeprom structure. This patch makes sure that it's always read after a reset, even if a valid MAGIC number is found in the SRAM. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-01 09:37:03 +00:00
#ifndef CONFIG_SPL_BUILD
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
if (ep->header == TI_EEPROM_HEADER_MAGIC)
ARM: DRA7: AMxx: Make sure that the SPL always reads the configuration EEPROM The bootrom may corrupt the area of SRAM used to store the ti_common_eeprom structure. This patch makes sure that it's always read after a reset, even if a valid MAGIC number is found in the SRAM. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-01 09:37:03 +00:00
return 0; /* EEPROM has already been read */
#endif
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
/* Initialize with a known bad marker for i2c fails.. */
ep->header = TI_DEAD_EEPROM_MAGIC;
ep->name[0] = 0x0;
ep->version[0] = 0x0;
ep->serial[0] = 0x0;
ti: common: board_detect: Setup initial default value for config as well config should have been initialized along with others as defaults. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-11 17:39:04 +00:00
ep->config[0] = 0x0;
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC,
sizeof(am_ep), (uint8_t *)&am_ep);
if (rc)
return rc;
ep->header = am_ep.header;
strlcpy(ep->name, am_ep.name, TI_EEPROM_HDR_NAME_LEN + 1);
ti_eeprom_string_cleanup(ep->name);
/* BeagleBone Green '1' eeprom, board_rev: 0x1a 0x00 0x00 0x00 */
if (am_ep.version[0] == 0x1a && am_ep.version[1] == 0x00 &&
am_ep.version[2] == 0x00 && am_ep.version[3] == 0x00)
strlcpy(ep->version, "BBG1", TI_EEPROM_HDR_REV_LEN + 1);
else
strlcpy(ep->version, am_ep.version, TI_EEPROM_HDR_REV_LEN + 1);
ti_eeprom_string_cleanup(ep->version);
strlcpy(ep->serial, am_ep.serial, TI_EEPROM_HDR_SERIAL_LEN + 1);
ti_eeprom_string_cleanup(ep->serial);
strlcpy(ep->config, am_ep.config, TI_EEPROM_HDR_CONFIG_LEN + 1);
ti_eeprom_string_cleanup(ep->config);
memcpy(ep->mac_addr, am_ep.mac_addr,
TI_EEPROM_HDR_NO_OF_MAC_ADDR * TI_EEPROM_HDR_ETH_ALEN);
return 0;
}
ti: common: dra7: Add standard access for board description EEPROM DRA7 EVM revH and later EVMs have EEPROM populated that can contain board description information such as name, revision, DDR definition, etc. Adding support for this EEPROM format. Acked-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-03-08 03:48:04 +00:00
int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr, int dev_addr)
{
int rc, offset = 0;
struct dra7_eeprom dra7_ep;
struct ti_common_eeprom *ep;
ep = TI_EEPROM_DATA;
ARM: DRA7: AMxx: Make sure that the SPL always reads the configuration EEPROM The bootrom may corrupt the area of SRAM used to store the ti_common_eeprom structure. This patch makes sure that it's always read after a reset, even if a valid MAGIC number is found in the SRAM. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-01 09:37:03 +00:00
#ifndef CONFIG_SPL_BUILD
ti: common: dra7: Add standard access for board description EEPROM DRA7 EVM revH and later EVMs have EEPROM populated that can contain board description information such as name, revision, DDR definition, etc. Adding support for this EEPROM format. Acked-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-03-08 03:48:04 +00:00
if (ep->header == DRA7_EEPROM_HEADER_MAGIC)
ARM: DRA7: AMxx: Make sure that the SPL always reads the configuration EEPROM The bootrom may corrupt the area of SRAM used to store the ti_common_eeprom structure. This patch makes sure that it's always read after a reset, even if a valid MAGIC number is found in the SRAM. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-01 09:37:03 +00:00
return 0; /* EEPROM has already been read */
#endif
ti: common: dra7: Add standard access for board description EEPROM DRA7 EVM revH and later EVMs have EEPROM populated that can contain board description information such as name, revision, DDR definition, etc. Adding support for this EEPROM format. Acked-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-03-08 03:48:04 +00:00
/* Initialize with a known bad marker for i2c fails.. */
ti: common: board_detect: Replace hardcoded value with macro We should have used TI_DEAD_EEPROM_MAGIC in the first place. Fixes: d3b98a9eb941 ("ti: common: dra7: Add standard access for board description EEPROM") Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-11 17:39:03 +00:00
ep->header = TI_DEAD_EEPROM_MAGIC;
ti: common: dra7: Add standard access for board description EEPROM DRA7 EVM revH and later EVMs have EEPROM populated that can contain board description information such as name, revision, DDR definition, etc. Adding support for this EEPROM format. Acked-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-03-08 03:48:04 +00:00
ep->name[0] = 0x0;
ep->version[0] = 0x0;
ep->serial[0] = 0x0;
ti: common: board_detect: Setup initial default value for config as well config should have been initialized along with others as defaults. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-11 17:39:04 +00:00
ep->config[0] = 0x0;
ti: common: dra7: Add standard access for board description EEPROM DRA7 EVM revH and later EVMs have EEPROM populated that can contain board description information such as name, revision, DDR definition, etc. Adding support for this EEPROM format. Acked-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-03-08 03:48:04 +00:00
ep->emif1_size = 0;
ep->emif2_size = 0;
rc = ti_i2c_eeprom_get(bus_addr, dev_addr, DRA7_EEPROM_HEADER_MAGIC,
sizeof(dra7_ep), (uint8_t *)&dra7_ep);
if (rc)
return rc;
ep->header = dra7_ep.header;
strlcpy(ep->name, dra7_ep.name, TI_EEPROM_HDR_NAME_LEN + 1);
ti_eeprom_string_cleanup(ep->name);
offset = dra7_ep.version_major - 1;
/* Rev F is skipped */
if (offset >= 5)
offset = offset + 1;
snprintf(ep->version, TI_EEPROM_HDR_REV_LEN + 1, "%c.%d",
'A' + offset, dra7_ep.version_minor);
ti_eeprom_string_cleanup(ep->version);
ep->emif1_size = (u64)dra7_ep.emif1_size;
ep->emif2_size = (u64)dra7_ep.emif2_size;
strlcpy(ep->config, dra7_ep.config, TI_EEPROM_HDR_CONFIG_LEN + 1);
ti_eeprom_string_cleanup(ep->config);
return 0;
}
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
static int ti_i2c_eeprom_am6_parse_record(struct ti_am6_eeprom_record *record,
struct ti_am6_eeprom *ep,
char **mac_addr,
u8 mac_addr_max_cnt,
u8 *mac_addr_cnt)
{
switch (record->header.id) {
case TI_AM6_EEPROM_RECORD_BOARD_INFO:
if (record->header.len != sizeof(record->data.board_info))
return -EINVAL;
if (!ep)
break;
/* Populate (and clean, if needed) the board name */
strlcpy(ep->name, record->data.board_info.name,
sizeof(ep->name));
ti_eeprom_string_cleanup(ep->name);
/* Populate selected other fields from the board info record */
strlcpy(ep->version, record->data.board_info.version,
sizeof(ep->version));
strlcpy(ep->software_revision,
record->data.board_info.software_revision,
sizeof(ep->software_revision));
strlcpy(ep->serial, record->data.board_info.serial,
sizeof(ep->serial));
break;
case TI_AM6_EEPROM_RECORD_MAC_INFO:
if (record->header.len != sizeof(record->data.mac_info))
return -EINVAL;
if (!mac_addr || !mac_addr_max_cnt)
break;
*mac_addr_cnt = ((record->data.mac_info.mac_control &
TI_AM6_EEPROM_MAC_ADDR_COUNT_MASK) >>
TI_AM6_EEPROM_MAC_ADDR_COUNT_SHIFT) + 1;
/*
* The EEPROM can (but may not) hold a very large amount
* of MAC addresses, by far exceeding what we want/can store
* in the common memory array, so only grab what we can fit.
* Note that a value of 0 means 1 MAC address, and so on.
*/
*mac_addr_cnt = min(*mac_addr_cnt, mac_addr_max_cnt);
memcpy(mac_addr, record->data.mac_info.mac_addr,
*mac_addr_cnt * TI_EEPROM_HDR_ETH_ALEN);
break;
case 0x00:
/* Illegal value... Fall through... */
case 0xFF:
/* Illegal value... Something went horribly wrong... */
return -EINVAL;
default:
pr_warn("%s: Ignoring record id %u\n", __func__,
record->header.id);
}
return 0;
}
int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int dev_addr,
struct ti_am6_eeprom *ep,
char **mac_addr,
u8 mac_addr_max_cnt,
u8 *mac_addr_cnt)
{
struct udevice *dev;
struct udevice *bus;
unsigned int eeprom_addr;
struct ti_am6_eeprom_record_board_id board_id;
struct ti_am6_eeprom_record record;
int rc;
board: ti: common: Optimize boot when detecting consecutive bad records The eeprom data area is much bigger than the data we intend to store, however, with bad programming, we might end up reading bad records over and over till we run out of eeprom space. instead just exit when 10 consecutive records are read. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:10 +00:00
int consecutive_bad_records = 0;
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
/* Initialize with a known bad marker for i2c fails.. */
memset(ep, 0, sizeof(*ep));
ep->header = TI_DEAD_EEPROM_MAGIC;
/* Read the board ID record which is always the first EEPROM record */
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;
}
/* Establish DM handle to board config EEPROM */
rc = uclass_get_device_by_seq(UCLASS_I2C, bus_addr, &bus);
if (rc)
return rc;
rc = i2c_get_chip(bus, dev_addr, 1, &dev);
if (rc)
return rc;
ep->header = TI_EEPROM_HEADER_MAGIC;
/* Ready to parse TLV structure. Initialize variables... */
*mac_addr_cnt = 0;
/*
* After the all-encompassing board ID record all other records follow
* a TLV-type scheme. Point to the first such record and then start
* parsing those one by one.
*/
eeprom_addr = sizeof(board_id);
board: ti: common: Optimize boot when detecting consecutive bad records The eeprom data area is much bigger than the data we intend to store, however, with bad programming, we might end up reading bad records over and over till we run out of eeprom space. instead just exit when 10 consecutive records are read. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:10 +00:00
while (consecutive_bad_records < 10) {
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
rc = dm_i2c_read(dev, eeprom_addr, (uint8_t *)&record.header,
sizeof(record.header));
if (rc)
return rc;
/*
* Check for end of list marker. If we reached it don't go
* any further and stop parsing right here.
*/
if (record.header.id == TI_AM6_EEPROM_RECORD_END_LIST)
break;
eeprom_addr += sizeof(record.header);
debug("%s: dev_addr=0x%02x header.id=%u header.len=%u\n",
__func__, dev_addr, record.header.id,
record.header.len);
/* Read record into memory if it fits */
if (record.header.len <= sizeof(record.data)) {
rc = dm_i2c_read(dev, eeprom_addr,
(uint8_t *)&record.data,
record.header.len);
if (rc)
return rc;
/* Process record */
rc = ti_i2c_eeprom_am6_parse_record(&record, ep,
mac_addr,
mac_addr_max_cnt,
mac_addr_cnt);
if (rc) {
pr_err("%s: EEPROM parsing error!\n", __func__);
return rc;
}
board: ti: common: Optimize boot when detecting consecutive bad records The eeprom data area is much bigger than the data we intend to store, however, with bad programming, we might end up reading bad records over and over till we run out of eeprom space. instead just exit when 10 consecutive records are read. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:10 +00:00
consecutive_bad_records = 0;
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
} else {
/*
* We may get here in case of larger records which
* are not yet understood.
*/
pr_err("%s: Ignoring record id %u\n", __func__,
record.header.id);
board: ti: common: Optimize boot when detecting consecutive bad records The eeprom data area is much bigger than the data we intend to store, however, with bad programming, we might end up reading bad records over and over till we run out of eeprom space. instead just exit when 10 consecutive records are read. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-17 18:26:10 +00:00
consecutive_bad_records++;
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
}
eeprom_addr += record.header.len;
}
return 0;
}
int __maybe_unused ti_i2c_eeprom_am6_get_base(int bus_addr, int dev_addr)
{
struct ti_am6_eeprom *ep = TI_AM6_EEPROM_DATA;
int ret;
/*
* Always execute EEPROM read by not allowing to bypass it during the
* first invocation of SPL which happens on the R5 core.
*/
#if !(defined(CONFIG_SPL_BUILD) && defined(CONFIG_CPU_V7R))
if (ep->header == TI_EEPROM_HEADER_MAGIC) {
debug("%s: EEPROM has already been read\n", __func__);
return 0;
}
#endif
ret = ti_i2c_eeprom_am6_get(bus_addr, dev_addr, ep,
(char **)ep->mac_addr,
AM6_EEPROM_HDR_NO_OF_MAC_ADDR,
&ep->mac_addr_cnt);
return ret;
}
board: ti: j721e: Use EEPROM-based board detection The TI J721E EVM system on module (SOM), the common processor board, and the associated daughtercards have on-board I2C-based EEPROMs containing board config data. Use the board detection infrastructure to do the following: 1) Parse the J721E SOM EEPROM and populate items like board name, board HW and SW revision as well as board serial number into the TI common EEPROM data structure residing in SRAM scratch space 2) Check for presence of daughter card(s) by probing associated I2C addresses used for on-board EEPROMs containing daughter card-specific data. If such a card is found, parse the EEPROM data such as for additional Ethernet MAC addresses and populate those into U-Boot accordingly 3) Dynamically apply daughter card DTB overlays to the U-Boot (proper) DTB during SPL execution 4) Dynamically create an U-Boot ENV variable called name_overlays during U-Boot execution containing a list of daugherboard-specific DTB overlays based on daughercards found to be used during Kernel boot. This patch adds support for the J721E system on module boards containing the actual SoC ("J721EX-PM2-SOM", accessed via CONFIG_EEPROM_CHIP_ADDRESS), the common processor board ("J7X-BASE-CPB"), the Quad-Port Ethernet Expansion Board ("J7X-VSC8514-ETH"), the infotainment board ("J7X-INFOTAN-EXP") as well as for the gateway/Ethernet switch/industrial expansion board ("J7X-GESI-EXP"). Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-07 07:45:54 +00:00
bool __maybe_unused board_ti_k3_is(char *name_tag)
{
struct ti_am6_eeprom *ep = TI_AM6_EEPROM_DATA;
if (ep->header == TI_DEAD_EEPROM_MAGIC)
return false;
return !strncmp(ep->name, name_tag, AM6_EEPROM_HDR_NAME_LEN);
}
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
bool __maybe_unused board_ti_is(char *name_tag)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
if (ep->header == TI_DEAD_EEPROM_MAGIC)
return false;
return !strncmp(ep->name, name_tag, TI_EEPROM_HDR_NAME_LEN);
}
bool __maybe_unused board_ti_rev_is(char *rev_tag, int cmp_len)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
int l;
if (ep->header == TI_DEAD_EEPROM_MAGIC)
return false;
l = cmp_len > TI_EEPROM_HDR_REV_LEN ? TI_EEPROM_HDR_REV_LEN : cmp_len;
return !strncmp(ep->version, rev_tag, l);
}
char * __maybe_unused board_ti_get_rev(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
ti: common: board_detect: Return a valid empty string for un-initialized eeprom Current logic for query of revision, board_name, config returns NULL. Users of these functions do a direct strncmp to compare. Unfortunately, as per conventions require two valid strings to compare against and the current implementation causes a crash when compared with NULL. We'd still like to maintain the simplistic usage of these APIs instead of redundant if (string) res=strncmp(fn(),"cmp",n); flowing all over the place. Hence, since the version, name and config is already pre-initialized with empty string, just dont check for invalid header in the first place and return the empty string to the caller. Reported-by: Brad Griffis <bgriffis@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Correct was'nt -> wasn't typo] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-11 17:39:05 +00:00
/* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
return ep->version;
}
char * __maybe_unused board_ti_get_config(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
ti: common: board_detect: Return a valid empty string for un-initialized eeprom Current logic for query of revision, board_name, config returns NULL. Users of these functions do a direct strncmp to compare. Unfortunately, as per conventions require two valid strings to compare against and the current implementation causes a crash when compared with NULL. We'd still like to maintain the simplistic usage of these APIs instead of redundant if (string) res=strncmp(fn(),"cmp",n); flowing all over the place. Hence, since the version, name and config is already pre-initialized with empty string, just dont check for invalid header in the first place and return the empty string to the caller. Reported-by: Brad Griffis <bgriffis@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Correct was'nt -> wasn't typo] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-11 17:39:05 +00:00
/* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
return ep->config;
}
char * __maybe_unused board_ti_get_name(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
ti: common: board_detect: Return a valid empty string for un-initialized eeprom Current logic for query of revision, board_name, config returns NULL. Users of these functions do a direct strncmp to compare. Unfortunately, as per conventions require two valid strings to compare against and the current implementation causes a crash when compared with NULL. We'd still like to maintain the simplistic usage of these APIs instead of redundant if (string) res=strncmp(fn(),"cmp",n); flowing all over the place. Hence, since the version, name and config is already pre-initialized with empty string, just dont check for invalid header in the first place and return the empty string to the caller. Reported-by: Brad Griffis <bgriffis@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Correct was'nt -> wasn't typo] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-11 17:39:05 +00:00
/* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
return ep->name;
}
void __maybe_unused
board_ti_get_eth_mac_addr(int index,
u8 mac_addr[TI_EEPROM_HDR_ETH_ALEN])
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
if (ep->header == TI_DEAD_EEPROM_MAGIC)
goto fail;
if (index < 0 || index >= TI_EEPROM_HDR_NO_OF_MAC_ADDR)
goto fail;
memcpy(mac_addr, ep->mac_addr[index], TI_EEPROM_HDR_ETH_ALEN);
return;
fail:
memset(mac_addr, 0, TI_EEPROM_HDR_ETH_ALEN);
}
ti: common: am6: Add support for setting MAC addresses The AM654x EVM based on the TI K3 family of SoCs has an updated board detection EEPROM structure that contains a TLV record of dedicated MAC addresses rather than a range of MAC addresses as it was used on earlier platforms such as DRA7. Add a basic function that allows us setting up Ethernet MAC addresses into the U-Boot environment based on the MAC address record contained in the common TI EEPROM structure. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:25 +00:00
void __maybe_unused
board_ti_am6_get_eth_mac_addr(int index,
u8 mac_addr[TI_EEPROM_HDR_ETH_ALEN])
{
struct ti_am6_eeprom *ep = TI_AM6_EEPROM_DATA;
if (ep->header == TI_DEAD_EEPROM_MAGIC)
goto fail;
if (index < 0 || index >= ep->mac_addr_cnt)
goto fail;
memcpy(mac_addr, ep->mac_addr[index], TI_EEPROM_HDR_ETH_ALEN);
return;
fail:
memset(mac_addr, 0, TI_EEPROM_HDR_ETH_ALEN);
}
ti: common: dra7: Add standard access for board description EEPROM DRA7 EVM revH and later EVMs have EEPROM populated that can contain board description information such as name, revision, DDR definition, etc. Adding support for this EEPROM format. Acked-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-03-08 03:48:04 +00:00
u64 __maybe_unused board_ti_get_emif1_size(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
if (ep->header != DRA7_EEPROM_HEADER_MAGIC)
return 0;
return ep->emif1_size;
}
u64 __maybe_unused board_ti_get_emif2_size(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
if (ep->header != DRA7_EEPROM_HEADER_MAGIC)
return 0;
return ep->emif2_size;
}
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
void __maybe_unused set_board_info_env(char *name)
{
char *unknown = "unknown";
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
if (name)
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_name", name);
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
else if (strlen(ep->name) != 0)
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_name", ep->name);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
else
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_name", unknown);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
if (strlen(ep->version) != 0)
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_rev", ep->version);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
else
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_rev", unknown);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
if (strlen(ep->serial) != 0)
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_serial", ep->serial);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
else
env: Rename setenv() to env_set() We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:09 +00:00
env_set("board_serial", unknown);
ARM: omap-common: Add standard access for board description EEPROM Several TI EVMs have EEPROM that can contain board description information such as revision, DDR definition, serial number, etc. In just about all cases, these EEPROM are on the I2C bus and provides us the opportunity to centralize the generic operations involved. The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM, AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format. However, DRA-7* EVMs, OMAP4SDP use a modified format. We hence introduce logic which is generic between these platforms without enforcing any specific format. This allows the boards to use the relevant format for operations that they might choose. This module will compile for all TI SoC based boards when CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for platforms that require this support. It is important to note that this logic is fundamental to the board configuration process such as DDR configuration which is needed in SPL, hence cannot be part of the standard u-boot driver model (which is available later in the process). Hence, to aid efficiency, the eeprom contents are copied over to SRAM scratchpad memory area at the first invocation to retrieve data. To prevent churn with cases such as DRA7, where eeprom format maybe incompatible, we introduce a generic common format in eeprom which is made available over accessor functions for usage. Special handling for BBG1 EEPROM had to be introduced thanks to the weird eeprom rev contents used. The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-24 18:30:54 +00:00
}
ti: common: board_detect: commodify ethaddr environment setting code Keystone and OMAP platforms will need this to set ethernet MAC addresses from board EEPROM. Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-14 13:04:19 +00:00
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
void __maybe_unused set_board_info_env_am6(char *name)
{
char *unknown = "unknown";
struct ti_am6_eeprom *ep = TI_AM6_EEPROM_DATA;
if (name)
env_set("board_name", name);
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
else if (strlen(ep->name) != 0)
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
env_set("board_name", ep->name);
else
env_set("board_name", unknown);
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
if (strlen(ep->version) != 0)
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
env_set("board_rev", ep->version);
else
env_set("board_rev", unknown);
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
if (strlen(ep->software_revision) != 0)
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
env_set("board_software_revision", ep->software_revision);
else
env_set("board_software_revision", unknown);
board: ti: common: Fix pointer-bool-conversion warnings When building this code with clang-10 a number of warnings will be generated along the lines of: warning: address of array 'ep->version' will always evaluate to 'true' Convert these checks to checking the strlen of the part of the array we care about. As this array will be null terminated previously by us, this is safe. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-06-04 19:45:08 +00:00
if (strlen(ep->serial) != 0)
ti: common: am6: Add support for board description EEPROM The AM654x EVM based on the TI K3 family of SoCs have an updated board detection EEPROM structure, now comprising variable-sized TLV-type records, containing a superset of what is already being provided on earlier platforms such as DRA7. Add basic support for parsing the new data structures contained on the base board into the common TI EEPROM structure while also providing infrastructure that can be used later on to parse data from additional EEPROMs such as the ones that are used on daughtercards for this platform. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:24 +00:00
env_set("board_serial", ep->serial);
else
env_set("board_serial", unknown);
}
ti: common: board_detect: commodify ethaddr environment setting code Keystone and OMAP platforms will need this to set ethernet MAC addresses from board EEPROM. Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-14 13:04:19 +00:00
static u64 mac_to_u64(u8 mac[6])
{
int i;
u64 addr = 0;
for (i = 0; i < 6; i++) {
addr <<= 8;
addr |= mac[i];
}
return addr;
}
static void u64_to_mac(u64 addr, u8 mac[6])
{
mac[5] = addr;
mac[4] = addr >> 8;
mac[3] = addr >> 16;
mac[2] = addr >> 24;
mac[1] = addr >> 32;
mac[0] = addr >> 40;
}
void board_ti_set_ethaddr(int index)
{
uint8_t mac_addr[6];
int i;
u64 mac1, mac2;
u8 mac_addr1[6], mac_addr2[6];
int num_macs;
/*
* Export any Ethernet MAC addresses from EEPROM.
* The 2 MAC addresses in EEPROM define the address range.
*/
board_ti_get_eth_mac_addr(0, mac_addr1);
board_ti_get_eth_mac_addr(1, mac_addr2);
if (is_valid_ethaddr(mac_addr1) && is_valid_ethaddr(mac_addr2)) {
mac1 = mac_to_u64(mac_addr1);
mac2 = mac_to_u64(mac_addr2);
/* must contain an address range */
num_macs = mac2 - mac1 + 1;
if (num_macs <= 0)
return;
if (num_macs > 50) {
printf("%s: Too many MAC addresses: %d. Limiting to 50\n",
__func__, num_macs);
num_macs = 50;
}
for (i = 0; i < num_macs; i++) {
u64_to_mac(mac1 + i, mac_addr);
if (is_valid_ethaddr(mac_addr)) {
env: Rename eth_setenv_enetaddr() to eth_env_set_enetaddr() Rename this function for consistency with env_set(). Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-03 18:22:11 +00:00
eth_env_set_enetaddr_by_index("eth", i + index,
mac_addr);
ti: common: board_detect: commodify ethaddr environment setting code Keystone and OMAP platforms will need this to set ethernet MAC addresses from board EEPROM. Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-14 13:04:19 +00:00
}
}
}
}
ti: common: board_detect: Add function to determine if EEPROM was read When the EEPROM is first read its contents are stored in memory as a cache to avoid further I2C operations. To determine if the EEPROM was previously read the easiest way is to check the memory to see if the EEPROM's magic header value is set. Create a new function that can determine if the EEPROM was previously read or not without having to perform a I2C transaction. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-06-16 22:25:08 +00:00
ti: common: am6: Add support for setting MAC addresses The AM654x EVM based on the TI K3 family of SoCs has an updated board detection EEPROM structure that contains a TLV record of dedicated MAC addresses rather than a range of MAC addresses as it was used on earlier platforms such as DRA7. Add a basic function that allows us setting up Ethernet MAC addresses into the U-Boot environment based on the MAC address record contained in the common TI EEPROM structure. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 23:08:25 +00:00
void board_ti_am6_set_ethaddr(int index, int count)
{
u8 mac_addr[6];
int i;
for (i = 0; i < count; i++) {
board_ti_am6_get_eth_mac_addr(i, mac_addr);
if (is_valid_ethaddr(mac_addr))
eth_env_set_enetaddr_by_index("eth", i + index,
mac_addr);
}
}
ti: common: board_detect: Add function to determine if EEPROM was read When the EEPROM is first read its contents are stored in memory as a cache to avoid further I2C operations. To determine if the EEPROM was previously read the easiest way is to check the memory to see if the EEPROM's magic header value is set. Create a new function that can determine if the EEPROM was previously read or not without having to perform a I2C transaction. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-06-16 22:25:08 +00:00
bool __maybe_unused board_ti_was_eeprom_read(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
if (ep->header == TI_EEPROM_HEADER_MAGIC)
return true;
else
return false;
}
Reference in a new issue Copy permalink