bcm63xx/u-boot/board/ti/common, branch master

ti: remove usage of DM_I2C_COMPAT and don't disable DM_I2C in SPL

2018-12-10T06:15:21Z

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 Reviewed-by: Tom Rini Reviewed-by: Heiko Schocher

ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT

2018-12-10T05:20:17Z

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 Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini Reviewed-by: Heiko Schocher

fastboot: Move fastboot to drivers/fastboot

2018-05-30T09:59:21Z

Separate CMD_FASTBOOT from FASTBOOT and move code and configuration to drivers/fastboot. Switch dependencies on FASTBOOT to USB_FUNCTION_FASTBOOT as anyone who wants FASTBOOT before this series wants USB_FUNCTION_FASTBOOT. Split USB_FUNCTION_FASTBOOT from FASTBOOT so they retain their existing behaviour. Signed-off-by: Alex Kiernan Reviewed-by: Simon Glass Acked-by: Joe Hershberger

SPDX: Convert all of our single license tags to Linux Kernel style

2018-05-07T13:34:12Z

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

env: Rename eth_setenv_enetaddr() to eth_env_set_enetaddr()

2017-08-16T12:23:56Z

Rename this function for consistency with env_set(). Signed-off-by: Simon Glass

env: Rename setenv() to env_set()

2017-08-16T12:22:18Z

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 Signed-off-by: Simon Glass

env: Convert CONFIG_ENV_IS_IN... to a choice

2017-08-16T00:50:01Z

At present we support multiple environment drivers but there is not way to select between them at run time. Also settings related to the position and size of the environment area are global (i.e. apply to all locations). Until these limitations are removed we cannot really support more than one environment location. Adjust the location to be a choice so that only one can be selected. By default the environment is 'nowhere', meaning that the environment exists only in memory and cannot be saved. Also expand the help for the 'nowhere' option and move it to the top since it is the default. Signed-off-by: Simon Glass [trini: Move all of the imply logic to default X if Y so it works again] Signed-off-by: Tom Rini

ti: Default to ENV_IS_IN_FAT if MMC_OMAP_HS

2017-07-31T16:21:25Z

When we have MMC available we assume that we want to put the env as a file on FAT. Cc: Lokesh Vutla Signed-off-by: Tom Rini

ti: common: board_detect: Add function to determine if EEPROM was read

2017-07-10T18:25:53Z

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 Reviewed-by: Tom Rini

ti: common: board_detect: Allow settings board detection variables manually

2017-07-10T17:45:35Z

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 Signed-off-by: Tero Kristo Signed-off-by: Keerthy Signed-off-by: Franklin S Cooper Jr. Reviewed-by: Tom Rini