Skip to contentSkip to conversation

ARM: omap-common: Add board detection support for TI EVMs

PATCH New Steve Kipisz 4 participants 25 messages Feb 24, 2016 – Mar 15, 2016 Arm (32-bit)

lore
Share & tools
lore
#0 lore raw

v5 cover ARM: omap-common: Add board detection support for TI EVMs

Several TI EVMs have onboard EEPROM that contain board description information. The onboard EEPROM on Beaglebone, Beaglebone Black, AM335x EVM, AM43x EVM, AM57xx EVM, Beagleboard-x15 all share the same format.

This series of patches introduces code which is generic among these platforms. The boards can use the data for any operations they might choose.

V5 of the series now updates the v4 series to ensure that latest u-boot platform support including BBG is supported as well.
This also setsup easier introduction of DRA7-evm variant of eeproms as well.

Testing:
AM335x:

	BeagleBone-Green: http://pastebin.ubuntu.com/15183845/
	BeagleBone-Black: http://pastebin.ubuntu.com/15183885/
	AM335x-SK: http://pastebin.ubuntu.com/15188966/

AM437x:

	AM437x-GPEVM: http://pastebin.ubuntu.com/15188896/
	AM437x-SK: http://pastebin.ubuntu.com/15188940/

Am57xx:

	AM57xx-gpevm: http://pastebin.ubuntu.com/15188997/

baseline:
master 595af9db2422 Merge branch 'master' of git://www.denx.de/git/u-boot-imx

Lokesh Vutla (1):
ARM: omap-common: Add standard access for board description EEPROM

Nishanth Menon (2):
ti: AM335x: Use generic EEPROM detection logic
ti: AM437x: Use generic EEPROM detection logic

Steve Kipisz (4):
ARM: OMAP4/5: Centralize early clock initialization
ARM: OMAP4/5: Centralize gpi2c_init
ARM: OMAP4/5: Add generic board detection hook
board: ti: AM57xx: Add detection logic for AM57xx-evm

 arch/arm/Kconfig                               |   2 +
 arch/arm/cpu/armv7/omap-common/clocks-common.c |  21 +-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |  14 +-
 arch/arm/cpu/armv7/omap5/Kconfig               |   1 +
 arch/arm/include/asm/arch-omap4/sys_proto.h    |   4 +-
 arch/arm/include/asm/arch-omap5/sys_proto.h    |   4 +-
 arch/arm/include/asm/omap_common.h             |   7 +-
 board/ti/am335x/Kconfig                        |   2 +
 board/ti/am335x/board.c                        | 115 ++++-------
 board/ti/am335x/board.h                        |  49 ++---
 board/ti/am335x/mux.c                          |  13 +-
 board/ti/am43xx/Kconfig                        |   2 +
 board/ti/am43xx/board.c                        |  87 +++------
 board/ti/am43xx/board.h                        |  37 +---
 board/ti/am43xx/mux.c                          |   1 +
 board/ti/am57xx/Kconfig                        |   2 +
 board/ti/am57xx/board.c                        |  70 ++++++-
 board/ti/common/Kconfig                        |   5 +
 board/ti/common/Makefile                       |   6 +
 board/ti/common/board_detect.c                 | 254 +++++++++++++++++++++++++
 board/ti/common/board_detect.h                 | 140 ++++++++++++++
 include/configs/am57xx_evm.h                   |   4 +
 include/configs/ti_omap5_common.h              |   2 +
 23 files changed, 623 insertions(+), 219 deletions(-)
 create mode 100644 board/ti/common/Kconfig
 create mode 100644 board/ti/common/Makefile
 create mode 100644 board/ti/common/board_detect.c
 create mode 100644 board/ti/common/board_detect.h
Signature · 1 line
2.7.0
#1 lore raw

PATCH v5 1/7 ARM: OMAP4/5: Centralize early clock initialization

Early clock initialization is currently done in two stages for OMAP4/5 SoCs. The first stage is the initialization of console clocks and then we initialize basic clocks for functionality necessary for SoC initialization and basic board functionality.

By splitting up prcm_init and centralizing this clock initialization, we setup the code for follow on patches that can do board specific initialization such as board detection which will depend on these basic clocks.

As part of this change, since the early clock initialization is centralized, we no longer need to expose the console clock initialization.

NOTE: we change the sequence slightly by initializing console clocks timer after the io settings are complete, but this is not expected to have any functioanlity impact since we setup the basic IO drive strength initialization as part of do_io_settings.

---
V5: No changes
v4: https://patchwork.ozlabs.org/patch/540775/
v3: https://patchwork.ozlabs.org/patch/540193/

v2: http://marc.info/?t=144655363000001&r=1&w=2
(mailing list squashed original submission)

v1: Did not exist

 arch/arm/cpu/armv7/omap-common/clocks-common.c | 21 +++++++++++++++++++--
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |  3 +--
 arch/arm/include/asm/arch-omap4/sys_proto.h    |  2 +-
 arch/arm/include/asm/arch-omap5/sys_proto.h    |  2 +-
 4 files changed, 22 insertions(+), 6 deletions(-)
arch/arm/cpu/armv7/omap-common/clocks-common.c +19 -2
index e28b79568d1d..367d224361be 100644
@@ -769,7 +769,7 @@ void lock_dpll(u32 const base)
 	wait_for_lock(base);
 }
 
-void setup_clocks_for_console(void)
+static void setup_clocks_for_console(void)
 {
 	/* Do not add any spl_debug prints in this function */
 	clrsetbits_le32((*prcm)->cm_l4per_clkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
@@ -853,14 +853,31 @@ void do_disable_clocks(u32 const *clk_domains,
 		disable_clock_domain(clk_domains[i]);
 }
 
-void prcm_init(void)
+/**
+ * setup_early_clocks() - Setup early clocks needed for SoC
+ *
+ * Setup clocks for console, SPL basic initialization clocks and initialize
+ * the timer. This is invoked prior prcm_init.
+ */
+void setup_early_clocks(void)
 {
 	switch (omap_hw_init_context()) {
 	case OMAP_INIT_CONTEXT_SPL:
 	case OMAP_INIT_CONTEXT_UBOOT_FROM_NOR:
 	case OMAP_INIT_CONTEXT_UBOOT_AFTER_CH:
+		setup_clocks_for_console();
 		enable_basic_clocks();
 		timer_init();
+		/* Fall through */
+	}
+}
+
+void prcm_init(void)
+{
+	switch (omap_hw_init_context()) {
+	case OMAP_INIT_CONTEXT_SPL:
+	case OMAP_INIT_CONTEXT_UBOOT_FROM_NOR:
+	case OMAP_INIT_CONTEXT_UBOOT_AFTER_CH:
 		scale_vcores(*omap_vcores);
 		setup_dplls();
 		setup_warmreset_time();
arch/arm/cpu/armv7/omap-common/hwinit-common.c +1 -2
index 80794f9c611a..91f2dead364b 100644
@@ -125,10 +125,9 @@ void s_init(void)
 	set_mux_conf_regs();
 #ifdef CONFIG_SPL_BUILD
 	srcomp_enable();
-	setup_clocks_for_console();
-
 	do_io_settings();
 #endif
+	setup_early_clocks();
 	prcm_init();
 }
 
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -1
index f30f86539130..71e3d776aa0d 100644
@@ -37,7 +37,7 @@ void do_set_mux(u32 base, struct pad_conf_entry const *array, int size);
 void set_muxconf_regs_essential(void);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
-void setup_clocks_for_console(void);
+void setup_early_clocks(void);
 void prcm_init(void);
 void bypass_dpll(u32 const base);
 void freq_update_core(void);
arch/arm/include/asm/arch-omap5/sys_proto.h +1 -1
index 7fcb78389403..b9e09e7c52a8 100644
@@ -48,7 +48,7 @@ void do_set_mux32(u32 base, struct pad_conf_entry const *array, int size);
 void set_muxconf_regs_essential(void);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
-void setup_clocks_for_console(void);
+void setup_early_clocks(void);
 void prcm_init(void);
 void bypass_dpll(u32 const base);
 void freq_update_core(void);
Signature · 1 line
2.7.0
#2 lore raw

PATCH v5 1/7 ARM: OMAP4/5: Centralize early clock initialization

Quoted 14 lines · Steve Kipisz

Early clock initialization is currently done in two stages for OMAP4/5 SoCs. The first stage is the initialization of console clocks and then we initialize basic clocks for functionality necessary for SoC initialization and basic board functionality.

By splitting up prcm_init and centralizing this clock initialization, we setup the code for follow on patches that can do board specific initialization such as board detection which will depend on these basic clocks.

As part of this change, since the early clock initialization is centralized, we no longer need to expose the console clock initialization.

Quoted 8 lines

NOTE: we change the sequence slightly by initializing console clocks timer after the io settings are complete, but this is not expected to have any functioanlity impact since we setup the basic IO drive strength initialization as part of do_io_settings.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/0114880d/attachment.sig>
#3 lore raw

PATCH v5 1/7 ARM: OMAP4/5: Centralize early clock initialization

In reply to Steve Kipisz
Quoted 19 lines · Steven

Early clock initialization is currently done in two stages for OMAP4/5 SoCs. The first stage is the initialization of console clocks and then we initialize basic clocks for functionality necessary for SoC initialization and basic board functionality.

By splitting up prcm_init and centralizing this clock initialization, we setup the code for follow on patches that can do board specific initialization such as board detection which will depend on these basic clocks.

As part of this change, since the early clock initialization is centralized, we no longer need to expose the console clock initialization.

NOTE: we change the sequence slightly by initializing console clocks timer after the io settings are complete, but this is not expected to have any functioanlity impact since we setup the basic IO drive strength initialization as part of do_io_settings.

Quoted 4 lines

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/4e1430c3/attachment.sig>
#4 lore raw

PATCH v5 2/7 ARM: OMAP4/5: Centralize gpi2c_init

In reply to Steve Kipisz

Centralize gpi2c_init into omap_common from the sys_proto header so that the information can be reused across SoCs.

---
V5: No changes
V4: https://patchwork.ozlabs.org/patch/540771/

v3: https://patchwork.ozlabs.org/patch/540196/

v2: http://marc.info/?t=144655344600007&r=1&w=2
(mailing list squashed original submission)

Changes in v2:
- New patch

 arch/arm/include/asm/arch-omap4/sys_proto.h | 1 -
 arch/arm/include/asm/arch-omap5/sys_proto.h | 1 -
 arch/arm/include/asm/omap_common.h          | 3 +++
 3 files changed, 3 insertions(+), 2 deletions(-)
arch/arm/include/asm/arch-omap4/sys_proto.h +0 -1
index 71e3d776aa0d..26e9a194f036 100644
@@ -51,7 +51,6 @@ void save_omap_boot_params(void);
 void init_omap_revision(void);
 void do_io_settings(void);
 void sri2c_init(void);
-void gpi2c_init(void);
 int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 reg_data);
 u32 warm_reset(void);
 void force_emif_self_refresh(void);
arch/arm/include/asm/arch-omap5/sys_proto.h +0 -1
index b9e09e7c52a8..18902628739b 100644
@@ -62,7 +62,6 @@ void save_omap_boot_params(void);
 void init_omap_revision(void);
 void do_io_settings(void);
 void sri2c_init(void);
-void gpi2c_init(void);
 int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 reg_data);
 u32 warm_reset(void);
 void force_emif_self_refresh(void);
arch/arm/include/asm/omap_common.h +3 -0
index d7b81c101b79..d773b0430ad4 100644
@@ -617,6 +617,9 @@ void disable_edma3_clocks(void);
 
 void omap_die_id(unsigned int *die_id);
 
+/* Initialize general purpose I2C(0) on the SoC */
+void gpi2c_init(void);
+
 /* ABB */
 #define OMAP_ABB_NOMINAL_OPP		0
 #define OMAP_ABB_FAST_OPP		1
Signature · 1 line
2.7.0
#5 lore raw

PATCH v5 2/7 ARM: OMAP4/5: Centralize gpi2c_init

Quoted 6 lines · Steve Kipisz

Centralize gpi2c_init into omap_common from the sys_proto header so that the information can be reused across SoCs.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/645a0926/attachment.sig>
#6 lore raw

PATCH v5 2/7 ARM: OMAP4/5: Centralize gpi2c_init

In reply to Steve Kipisz
Quoted 7 lines · Steven

Centralize gpi2c_init into omap_common from the sys_proto header so that the information can be reused across SoCs.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/7042459a/attachment.sig>
#7 lore raw

PATCH v5 3/7 ARM: omap-common: Add standard access for board description EEPROM

In reply to Steve Kipisz

From: Lokesh Vutla <[email protected]>

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.

---
Changes in V5:
- Dropped dependency on https://patchwork.ozlabs.org/patch/540280/
- library now completely abstracts eeprom format away from consumers
- data access over apis to the library - now made reusable for dra7 (follow on series)
- mac address api access introduced (Thanks to Roger)
- a "generic" eeprom structure which is board independent is stored in sram (instead of actual eeprom contents)
- To optimize compile time usage, TI_I2C_BOARD_DETECT introduced
- BBG hack incorporated

V4: https://patchwork.ozlabs.org/patch/540773/
v3: https://patchwork.ozlabs.org/patch/540197/

v2: http://marc.info/?t=144655344800001&r=1&w=2
(mailing list squashed original submission)

Changes in v2:
- New patch

 arch/arm/include/asm/omap_common.h |   4 +-
 board/ti/common/Kconfig            |   5 +
 board/ti/common/Makefile           |   6 +
 board/ti/common/board_detect.c     | 254 +++++++++++++++++++++++++++++++++++++
 board/ti/common/board_detect.h     | 140 ++++++++++++++++++++
 5 files changed, 408 insertions(+), 1 deletion(-)
 create mode 100644 board/ti/common/Kconfig
 create mode 100644 board/ti/common/Makefile
 create mode 100644 board/ti/common/board_detect.c
 create mode 100644 board/ti/common/board_detect.h
arch/arm/include/asm/omap_common.h +3 -1
index d773b0430ad4..aef31266ce9e 100644
@@ -713,7 +713,9 @@ static inline u8 is_dra72x(void)
 #define OMAP_SRAM_SCRATCH_VCORES_PTR    (SRAM_SCRATCH_SPACE_ADDR + 0x1C)
 #define OMAP_SRAM_SCRATCH_SYS_CTRL	(SRAM_SCRATCH_SPACE_ADDR + 0x20)
 #define OMAP_SRAM_SCRATCH_BOOT_PARAMS	(SRAM_SCRATCH_SPACE_ADDR + 0x24)
-#define OMAP5_SRAM_SCRATCH_SPACE_END	(SRAM_SCRATCH_SPACE_ADDR + 0x28)
+#define OMAP_SRAM_SCRATCH_BOARD_EEPROM_START (SRAM_SCRATCH_SPACE_ADDR + 0x28)
+#define OMAP_SRAM_SCRATCH_BOARD_EEPROM_END (SRAM_SCRATCH_SPACE_ADDR + 0x200)
+#define OMAP_SRAM_SCRATCH_SPACE_END	(OMAP_SRAM_SCRATCH_BOARD_EEPROM_END)
 
 /* Boot parameters */
 #define DEVICE_DATA_OFFSET	0x18
board/ti/common/Kconfig new file +5 -0
new file mode 100644
index 000000000000..adf73abc9358
@@ -0,0 +1,5 @@
+config TI_I2C_BOARD_DETECT
+	bool "Support for Board detection for TI platforms"
+	help
+	   Support for detection board information on Texas Instrument's
+	   Evaluation Boards which have I2C based EEPROM detection
board/ti/common/Makefile new file +6 -0
new file mode 100644
index 000000000000..7170eac81e87
@@ -0,0 +1,6 @@
+# Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
board/ti/common/board_detect.c new file +254 -0

254 lines not on this page · raw message

board/ti/common/board_detect.h new file +140 -0

140 lines not on this page · raw message

Signature · 1 line
2.7.0
#8 lore raw

PATCH v5 3/7 ARM: omap-common: Add standard access for board description EEPROM

Quoted 33 lines · Steve Kipisz

From: Lokesh Vutla <[email protected]>

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.

Quoted 7 lines

The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/f46681e2/attachment.sig>
#9 lore raw

PATCH v5 3/7 ARM: omap-common: Add standard access for board description EEPROM

In reply to Steve Kipisz
Quoted 33 lines · Steven

From: Lokesh Vutla <[email protected]>

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.

Quoted 8 lines

The follow on patches introduce the use of this library for AM335x, AM437x, and AM57xx.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/e7f65c18/attachment.sig>
#10 lore raw

PATCH v5 4/7 ti: AM335x: Use generic EEPROM detection logic

In reply to Steve Kipisz

From: Nishanth Menon <[email protected]>

Use the generic EEPROM detection logic instead of duplicating the AM eeprom logic.

---
V5:
- Drops dependency on https://patchwork.ozlabs.org/patch/540280/
- newer API usage
v4: https://patchwork.ozlabs.org/patch/540772/

V3-v1: did not exist

 arch/arm/Kconfig        |   1 +
 board/ti/am335x/Kconfig |   2 +
 board/ti/am335x/board.c | 115 ++++++++++++++----------------------------------
 board/ti/am335x/board.h |  49 ++++++++-------------
 board/ti/am335x/mux.c   |  13 +++---
 5 files changed, 60 insertions(+), 120 deletions(-)
arch/arm/Kconfig +1 -0
index d8b63e940768..38dd19a7197b 100644
@@ -368,6 +368,7 @@ config TARGET_AM335X_EVM
 	select DM
 	select DM_SERIAL
 	select DM_GPIO
+	select TI_I2C_BOARD_DETECT
 
 config TARGET_AM335X_SL50
 	bool "Support am335x_sl50"
board/ti/am335x/Kconfig +2 -0
index 49b73abc2090..11ef3caf3908 100644
@@ -38,4 +38,6 @@ config NOR_BOOT
 	  as the ROM only partially sets up pinmux.  We also default to using
 	  NOR for environment.
 
+source "board/ti/common/Kconfig"
+
 endif
board/ti/am335x/board.c +32 -83

234 lines not on this page · raw message

board/ti/am335x/board.h +18 -31

76 lines not on this page · raw message

board/ti/am335x/mux.c +7 -6
index 79ed02f68f77..fdf827fe541d 100644
@@ -19,6 +19,7 @@
 #include <asm/arch/mux.h>
 #include <asm/io.h>
 #include <i2c.h>
+#include "../common/board_detect.h"
 #include "board.h"
 
 static struct module_pin_mux uart0_pin_mux[] = {
@@ -312,10 +313,10 @@ static unsigned short detect_daughter_board_profile(void)
 	return (1 << (val & PROFILE_MASK));
 }
 
-void enable_board_pin_mux(struct am335x_baseboard_id *header)
+void enable_board_pin_mux(void)
 {
 	/* Do board-specific muxes. */
-	if (board_is_bone(header)) {
+	if (board_is_bone()) {
 		/* Beaglebone pinmux */
 		configure_module_pin_mux(mii1_pin_mux);
 		configure_module_pin_mux(mmc0_pin_mux);
@@ -326,7 +327,7 @@ void enable_board_pin_mux(struct am335x_baseboard_id *header)
 #else
 		configure_module_pin_mux(mmc1_pin_mux);
 #endif
-	} else if (board_is_gp_evm(header)) {
+	} else if (board_is_gp_evm()) {
 		/* General Purpose EVM */
 		unsigned short profile = detect_daughter_board_profile();
 		configure_module_pin_mux(rgmii1_pin_mux);
@@ -343,17 +344,17 @@ void enable_board_pin_mux(struct am335x_baseboard_id *header)
 			configure_module_pin_mux(mmc1_pin_mux);
 			configure_module_pin_mux(spi0_pin_mux);
 		}
-	} else if (board_is_idk(header)) {
+	} else if (board_is_idk()) {
 		/* Industrial Motor Control (IDK) */
 		configure_module_pin_mux(mii1_pin_mux);
 		configure_module_pin_mux(mmc0_no_cd_pin_mux);
-	} else if (board_is_evm_sk(header)) {
+	} else if (board_is_evm_sk()) {
 		/* Starter Kit EVM */
 		configure_module_pin_mux(i2c1_pin_mux);
 		configure_module_pin_mux(gpio0_7_pin_mux);
 		configure_module_pin_mux(rgmii1_pin_mux);
 		configure_module_pin_mux(mmc0_pin_mux_sk_evm);
-	} else if (board_is_bone_lt(header)) {
+	} else if (board_is_bone_lt()) {
 		/* Beaglebone LT pinmux */
 		configure_module_pin_mux(mii1_pin_mux);
 		configure_module_pin_mux(mmc0_pin_mux);
Signature · 1 line
2.7.0
#11 lore raw

PATCH v5 4/7 ti: AM335x: Use generic EEPROM detection logic

Quoted 8 lines · Steve Kipisz

From: Nishanth Menon <[email protected]>

Use the generic EEPROM detection logic instead of duplicating the AM eeprom logic.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/36214bbf/attachment.sig>
#12 lore raw

PATCH v5 4/7 ti: AM335x: Use generic EEPROM detection logic

In reply to Steve Kipisz
Quoted 9 lines · Steven

From: Nishanth Menon <[email protected]>

Use the generic EEPROM detection logic instead of duplicating the AM eeprom logic.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/6841af52/attachment.sig>
#13 lore raw

PATCH v5 5/7 ti: AM437x: Use generic EEPROM detection logic

In reply to Steve Kipisz

From: Nishanth Menon <[email protected]>

Now that we have a generic TI eeprom logic which can be reused across platforms, reuse the same.

This revision also includes fixes identified by Dave Gerlach <[email protected]>

---
V5:
- updated fixes from Dave on i2c init
- rebased to latest api changes
V4: https://patchwork.ozlabs.org/patch/540280/
V1-v3: did not exist

 arch/arm/Kconfig        |  1 +
 board/ti/am43xx/Kconfig |  2 ++
 board/ti/am43xx/board.c | 87 +++++++++++++++----------------------------------
 board/ti/am43xx/board.h | 37 +++++----------------
 board/ti/am43xx/mux.c   |  1 +
 5 files changed, 39 insertions(+), 89 deletions(-)
arch/arm/Kconfig +1 -0
index 38dd19a7197b..3f2faf0d595e 100644
@@ -381,6 +381,7 @@ config TARGET_AM43XX_EVM
 	bool "Support am43xx_evm"
 	select CPU_V7
 	select SUPPORT_SPL
+	select TI_I2C_BOARD_DETECT
 
 config TARGET_BAV335X
 	bool "Support bav335x"
board/ti/am43xx/Kconfig +2 -0
index 8d1c16883d8b..9cb80cc3f1da 100644
@@ -12,4 +12,6 @@ config SYS_SOC
 config SYS_CONFIG_NAME
 	default "am43xx_evm"
 
+source "board/ti/common/Kconfig"
+
 endif
board/ti/am43xx/board.c +27 -60

136 lines not on this page · raw message

board/ti/am43xx/board.h +8 -29
index eb9493e191c6..2cf7a7751d41 100644
@@ -14,58 +14,37 @@
 
 #include <asm/arch/omap.h>
 
-static char *const am43xx_board_name = (char *)AM4372_BOARD_NAME_START;
-static char *const am43xx_board_rev = (char *)AM4372_BOARD_VERSION_START;
-
-/*
- * TI AM437x EVMs define a system EEPROM that defines certain sub-fields.
- * We use these fields to in turn see what board we are on, and what
- * that might require us to set or not set.
- */
-#define HDR_NO_OF_MAC_ADDR	3
-#define HDR_ETH_ALEN		6
-#define HDR_NAME_LEN		8
-
-#define DEV_ATTR_MAX_OFFSET	5
-#define DEV_ATTR_MIN_OFFSET	0
-
-struct am43xx_board_id {
-	unsigned int  magic;
-	char name[HDR_NAME_LEN];
-	char version[4];
-	char serial[12];
-	char config[32];
-	char mac_addr[HDR_NO_OF_MAC_ADDR][HDR_ETH_ALEN];
-};
+#define DEV_ATTR_MAX_OFFSET    5
+#define DEV_ATTR_MIN_OFFSET    0
 
 static inline int board_is_eposevm(void)
 {
-	return !strncmp(am43xx_board_name, "AM43EPOS", HDR_NAME_LEN);
+	return board_ti_is("AM43EPOS");
 }
 
 static inline int board_is_gpevm(void)
 {
-	return !strncmp(am43xx_board_name, "AM43__GP", HDR_NAME_LEN);
+	return board_ti_is("AM43__GP");
 }
 
 static inline int board_is_sk(void)
 {
-	return !strncmp(am43xx_board_name, "AM43__SK", HDR_NAME_LEN);
+	return board_ti_is("AM43__SK");
 }
 
 static inline int board_is_idk(void)
 {
-	return !strncmp(am43xx_board_name, "AM43_IDK", HDR_NAME_LEN);
+	return board_ti_is("AM43_IDK");
 }
 
 static inline int board_is_evm_14_or_later(void)
 {
-	return (board_is_gpevm() && strncmp("1.4", am43xx_board_rev, 3) <= 0);
+	return (board_is_gpevm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0);
 }
 
 static inline int board_is_evm_12_or_later(void)
 {
-	return (board_is_gpevm() && strncmp("1.2", am43xx_board_rev, 3) <= 0);
+	return (board_is_gpevm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0);
 }
 
 void enable_uart0_pin_mux(void);
board/ti/am43xx/mux.c +1 -0
index 510477dad9e2..e03b1bcfaaa8 100644
@@ -9,6 +9,7 @@
 #include <common.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/mux.h>
+#include "../common/board_detect.h"
 #include "board.h"
 
 static struct module_pin_mux rmii1_pin_mux[] = {
Signature · 1 line
2.7.0
#14 lore raw

PATCH v5 5/7 ti: AM437x: Use generic EEPROM detection logic

Quoted 5 lines · Steve Kipisz

From: Nishanth Menon <[email protected]>

Now that we have a generic TI eeprom logic which can be reused across platforms, reuse the same.

Quoted 7 lines

This revision also includes fixes identified by Dave Gerlach <[email protected]>

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/57fa4174/attachment.sig>
#15 lore raw

PATCH v5 5/7 ti: AM437x: Use generic EEPROM detection logic

In reply to Steve Kipisz
Quoted 5 lines · Steven

From: Nishanth Menon <[email protected]>

Now that we have a generic TI eeprom logic which can be reused across platforms, reuse the same.

Quoted 8 lines

This revision also includes fixes identified by Dave Gerlach <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/1f50dc89/attachment.sig>
#16 lore raw

PATCH v5 6/7 ARM: OMAP4/5: Add generic board detection hook

In reply to Steve Kipisz

Many TI EVMs have capability to store relevant board information such as DDR description in EEPROM. Further many pad configuration variations can occur as part of revision changes in the platform. In-order to support these at runtime, we for a board detection hook which is available for override from board files that may desire to do so.

NOTE: All TI EVMs are capable of detecting board information based on early clocks that are configured. However, in case of additional needs this can be achieved within the override logic from within the board file.

---
V5:
- reviewed by picked up
- no functional changes
V4: https://patchwork.ozlabs.org/patch/540774/
v3: https://patchwork.ozlabs.org/patch/540194/

v2: http://marc.info/?t=144655344600006&r=1&w=2
(mailing list squashed original submission)

Changes in v2:
- New patch

 arch/arm/cpu/armv7/omap-common/hwinit-common.c | 11 +++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h    |  1 +
 arch/arm/include/asm/arch-omap5/sys_proto.h    |  1 +
 3 files changed, 13 insertions(+)
arch/arm/cpu/armv7/omap-common/hwinit-common.c +11 -0
index 91f2dead364b..9e9376d0e6e6 100644
@@ -97,6 +97,16 @@ int arch_cpu_init(void)
 }
 #endif /* CONFIG_ARCH_CPU_INIT */
 
+/**
+ * do_board_detect() - Detect board description
+ *
+ * Function to detect board description. This is expected to be
+ * overridden in the SoC family board file where desired.
+ */
+void __weak do_board_detect(void)
+{
+}
+
 /*
  * Routine: s_init
  * Description: Does early system init of watchdog, muxing,  andclocks
@@ -128,6 +138,7 @@ void s_init(void)
 	do_io_settings();
 #endif
 	setup_early_clocks();
+	do_board_detect();
 	prcm_init();
 }
 
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index 26e9a194f036..fbb52093c65a 100644
@@ -39,6 +39,7 @@ u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
 void setup_early_clocks(void);
 void prcm_init(void);
+void do_board_detect(void);
 void bypass_dpll(u32 const base);
 void freq_update_core(void);
 u32 get_sys_clk_freq(void);
arch/arm/include/asm/arch-omap5/sys_proto.h +1 -0
index 18902628739b..23a33cb233bb 100644
@@ -50,6 +50,7 @@ u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
 void setup_early_clocks(void);
 void prcm_init(void);
+void do_board_detect(void);
 void bypass_dpll(u32 const base);
 void freq_update_core(void);
 u32 get_sys_clk_freq(void);
Signature · 1 line
2.7.0
#17 lore raw

PATCH v5 6/7 ARM: OMAP4/5: Add generic board detection hook

Quoted 7 lines · Steve Kipisz

Many TI EVMs have capability to store relevant board information such as DDR description in EEPROM. Further many pad configuration variations can occur as part of revision changes in the platform. In-order to support these at runtime, we for a board detection hook which is available for override from board files that may desire to do so.

Quoted 8 lines

NOTE: All TI EVMs are capable of detecting board information based on early clocks that are configured. However, in case of additional needs this can be achieved within the override logic from within the board file.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/2df3c4ab/attachment.sig>
#18 lore raw

PATCH v5 6/7 ARM: OMAP4/5: Add generic board detection hook

In reply to Steve Kipisz
Quoted 12 lines · Steven

Many TI EVMs have capability to store relevant board information such as DDR description in EEPROM. Further many pad configuration variations can occur as part of revision changes in the platform. In-order to support these at runtime, we for a board detection hook which is available for override from board files that may desire to do so.

NOTE: All TI EVMs are capable of detecting board information based on early clocks that are configured. However, in case of additional needs this can be achieved within the override logic from within the board file.

Quoted 4 lines

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/b487f869/attachment.sig>
#19 lore raw

PATCH v5 7/7 board: ti: AM57xx: Add detection logic for AM57xx-evm

In reply to Steve Kipisz

Current AM57xx evm supports both BeagleBoard-X15
(http://beagleboard.org/x15) and AM57xx EVM
(http://www.ti.com/tool/tmdxevm5728).

The AM572x EValuation Module(EVM) provides an affordable platform to quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors (AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI, machine vision, networking, medical imaging and many other industrial applications. This EVM is based on the same BeagleBoard-X15 Chassis and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's wlink8 offering.

Since the EEPROM contents are compatible between the BeagleBoard-X15 and the AM57xx-evm, we add support for the detection logic to enable support for various user programmable scripting capability.

NOTE: U-boot configuration is currently a superset of AM57xx evm and BeagleBoard-X15 and no additional configuration tweaking is needed.

This change also sets up the stage for future support of TI AM57xx EVMs to the same base bootloader build.

---

V5:
- bug fixes for sys_info updates
- updated for newer API usage
- beagle-x15 and gpevm share the same dtb in findfdt - to ensure backward compatibility.

v4: https://patchwork.ozlabs.org/patch/540769/

v3: https://patchwork.ozlabs.org/patch/540195/

v2: http://marc.info/?t=144655344600003&r=1&w=2

v1: http://marc.info/?t=144608007900002&r=1&w=2
http://marc.info/?t=144608007900004&r=1&w=2
(mailing list squashed original submission)

 arch/arm/cpu/armv7/omap5/Kconfig  |  1 +
 board/ti/am57xx/Kconfig           |  2 ++
 board/ti/am57xx/board.c           | 70 ++++++++++++++++++++++++++++++++++++++-
 include/configs/am57xx_evm.h      |  4 +++
 include/configs/ti_omap5_common.h |  2 ++
 5 files changed, 78 insertions(+), 1 deletion(-)
arch/arm/cpu/armv7/omap5/Kconfig +1 -0
index bfa264eccc57..f265b34b6383 100644
@@ -15,6 +15,7 @@ config TARGET_DRA7XX_EVM
 
 config TARGET_BEAGLE_X15
 	bool "BeagleBoard X15"
+	select TI_I2C_BOARD_DETECT
 
 endchoice
 
board/ti/am57xx/Kconfig +2 -0
index bdb779511b66..17745ff7ea65 100644
@@ -9,4 +9,6 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
 	default "am57xx_evm"
 
+source "board/ti/common/Kconfig"
+
 endif
board/ti/am57xx/board.c +69 -1

97 lines not on this page · raw message

include/configs/am57xx_evm.h +4 -0
index 6308cab8e680..1fffdb18fbcd 100644
@@ -88,4 +88,8 @@
 #define CONFIG_SYS_SCSI_MAX_DEVICE	(CONFIG_SYS_SCSI_MAX_SCSI_ID * \
 						CONFIG_SYS_SCSI_MAX_LUN)
 
+/* EEPROM */
+#define CONFIG_EEPROM_CHIP_ADDRESS 0x50
+#define CONFIG_EEPROM_BUS_ADDRESS 0
+
 #endif /* __CONFIG_AM57XX_EVM_H */
include/configs/ti_omap5_common.h +2 -0
index d164e6abd450..d373cbc44a16 100644
@@ -117,6 +117,8 @@
 			"setenv fdtfile dra72-evm.dtb; fi;" \
 		"if test $board_name = beagle_x15; then " \
 			"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
+		"if test $board_name = am57xx_evm; then " \
+			"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
 		"if test $fdtfile = undefined; then " \
 			"echo WARNING: Could not determine device tree to use; fi; \0" \
 	"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
Signature · 1 line
2.7.0
#20 lore raw

PATCH v5 7/7 board: ti: AM57xx: Add detection logic for AM57xx-evm

[..snip..]

Quoted 18 lines
include/configs/am57xx_evm.h +4 -0
index 6308cab8e680..1fffdb18fbcd 100644
@@ -88,4 +88,8 @@
  #define CONFIG_SYS_SCSI_MAX_DEVICE	(CONFIG_SYS_SCSI_MAX_SCSI_ID * \
  						CONFIG_SYS_SCSI_MAX_LUN)
 
+/* EEPROM */
+#define CONFIG_EEPROM_CHIP_ADDRESS 0x50
+#define CONFIG_EEPROM_BUS_ADDRESS 0
+
  #endif /* __CONFIG_AM57XX_EVM_H */
include/configs/ti_omap5_common.h +0 -0
index d164e6abd450..d373cbc44a16 100644

include/configs/ti_omap5_common.h line 121

Quoted 5 lines
include/configs/ti_omap5_common.h +2 -0
@@ -117,6 +117,8 @@
  			"setenv fdtfile dra72-evm.dtb; fi;" \
  		"if test $board_name = beagle_x15; then " \
  			"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
+		"if test $board_name = am57xx_evm; then " \
+			"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \

Is it the same dtb file for am57xx_evm as well? or is this intentional and will be updated later?

Thanks and regards,
Lokesh

Quoted 4 lines
include/configs/ti_omap5_common.h +0 -0
  		"if test $fdtfile = undefined; then " \
  			"echo WARNING: Could not determine device tree to use; fi; \0" \
  	"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
#21 lore raw

PATCH v5 7/7 board: ti: AM57xx: Add detection logic for AM57xx-evm

Quoted 2 lines · Lokesh Vutla

[..snip..]

[...]

Quoted 8 lines

include/configs/ti_omap5_common.h line 121

Quoted 5 lines
  			"setenv fdtfile dra72-evm.dtb; fi;" \
  		"if test $board_name = beagle_x15; then " \
  			"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
include/configs/ti_omap5_common.h +2 -0
+		"if test $board_name = am57xx_evm; then " \
+			"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \

Is it the same dtb file for am57xx_evm as well? or is this intentional and will be updated later?

Yes - it should be the same dtb file for 2 reasons:
A) At this point in patch, we dont want to break am57xx-evm - mentioned in diffstat to remind ourselves.
B) we are attempting to move all these "cape" like variants into device tree overlays -> in which case the same dtb is reused even for am57xx-evm, and overlay with panel and touchscreen for the "gpevm" panel board.

So, in almost with 80% certainty, we might not introduce a am57xx_evm.dtb in upstream - we really dont need to. In fact, upstream kernel and current master u-boot does bootup successfully, and would like to maintain it so (point A).

Signature · 2 lines
Regards,
Nishanth Menon
#22 lore raw

PATCH v5 7/7 board: ti: AM57xx: Add detection logic for AM57xx-evm

In reply to Steve Kipisz
Quoted 19 lines · Steve Kipisz

Current AM57xx evm supports both BeagleBoard-X15
(http://beagleboard.org/x15) and AM57xx EVM
(http://www.ti.com/tool/tmdxevm5728).

The AM572x EValuation Module(EVM) provides an affordable platform to quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors (AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI, machine vision, networking, medical imaging and many other industrial applications. This EVM is based on the same BeagleBoard-X15 Chassis and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's wlink8 offering.

Since the EEPROM contents are compatible between the BeagleBoard-X15 and the AM57xx-evm, we add support for the detection logic to enable support for various user programmable scripting capability.

NOTE: U-boot configuration is currently a superset of AM57xx evm and BeagleBoard-X15 and no additional configuration tweaking is needed.

Quoted 6 lines

This change also sets up the stage for future support of TI AM57xx EVMs to the same base bootloader build.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/3ee90315/attachment.sig>
#23 lore raw

PATCH v5 7/7 board: ti: AM57xx: Add detection logic for AM57xx-evm

In reply to Steve Kipisz
Quoted 19 lines · Steven

Current AM57xx evm supports both BeagleBoard-X15
(http://beagleboard.org/x15) and AM57xx EVM
(http://www.ti.com/tool/tmdxevm5728).

The AM572x EValuation Module(EVM) provides an affordable platform to quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors (AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI, machine vision, networking, medical imaging and many other industrial applications. This EVM is based on the same BeagleBoard-X15 Chassis and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's wlink8 offering.

Since the EEPROM contents are compatible between the BeagleBoard-X15 and the AM57xx-evm, we add support for the detection logic to enable support for various user programmable scripting capability.

NOTE: U-boot configuration is currently a superset of AM57xx evm and BeagleBoard-X15 and no additional configuration tweaking is needed.

Quoted 7 lines

This change also sets up the stage for future support of TI AM57xx EVMs to the same base bootloader build.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/960d7674/attachment.sig>
#24 lore raw

v5 cover ARM: omap-common: Add board detection support for TI EVMs

In reply to Steve Kipisz
Quoted 19 lines · Steve Kipisz

Several TI EVMs have onboard EEPROM that contain board description information. The onboard EEPROM on Beaglebone, Beaglebone Black, AM335x EVM, AM43x EVM, AM57xx EVM, Beagleboard-x15 all share the same format.

This series of patches introduces code which is generic among these platforms. The boards can use the data for any operations they might choose.

V5 of the series now updates the v4 series to ensure that latest u-boot platform support including BBG is supported as well.
This also setsup easier introduction of DRA7-evm variant of eeproms as well.

Testing:
AM335x:

	BeagleBone-Green: http://pastebin.ubuntu.com/15183845/
	BeagleBone-Black: http://pastebin.ubuntu.com/15183885/
	AM335x-SK: http://pastebin.ubuntu.com/15188966/

AM437x:

Quoted 8 lines
	AM437x-GPEVM: http://pastebin.ubuntu.com/15188896/
	AM437x-SK: http://pastebin.ubuntu.com/15188940/

Am57xx:

	AM57xx-gpevm: http://pastebin.ubuntu.com/15188997/

baseline:
master 595af9db2422 Merge branch 'master' of git://www.denx.de/git/u-boot-imx

I like this, it all looks good. But it's too late to take in for this release given the number of different boards that get changed in the end. I'll pick this up after the v2016.03 release, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/6b55e9c1/attachment.sig>