summaryrefslogtreecommitdiff
path: root/board/ti/common/board_detect.h
AgeCommit message (Collapse)Author
2020-08-11board: ti: board_detect: Add stub functions for EEPROM detection apisLokesh Vutla
Current usage of eeprom apis produce a build failure when CONFIG_TI_I2C_BOARD_DETECT is not defined. Add stub function for these apis to avoid build failures. Reviewed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-05-18common: Drop linux/bitops.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-20board: ti: j721e: Use EEPROM-based board detectionAndreas Dannenberg
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-20board: ti: beagleboneai: emmc read changesCaleb Robey
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>
2019-07-17ti: common: am6: Add support for setting MAC addressesAndreas Dannenberg
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-07-17ti: common: am6: Add support for board description EEPROMAndreas Dannenberg
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>
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini
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>
2017-07-10ti: common: board_detect: Add function to determine if EEPROM was readCooper Jr., Franklin
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-07-10ti: common: board_detect: Allow settings board detection variables manuallyNishanth Menon
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-03-20ti: common: board_detect: commodify ethaddr environment setting codeRoger Quadros
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-20ti: common: board_detect: Rename EEPROM scratch start macroLokesh Vutla
Non OMAP platforms i.e. Keystone will also need to use the board EEPROM helpers so let's make the macro platform independent. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-31ti: common: board_detect: Return a valid empty string for un-initialized eepromNishanth Menon
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-03-14ti: common: dra7: Add standard access for board description EEPROMLokesh Vutla
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-14ARM: omap-common: Add standard access for board description EEPROMLokesh Vutla
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>