[U-Boot] [PATCH v3] Adding support for DevKit8000

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Frederik Kriewitz]

This patch adds support for the DevKit8000 board.

Signed-off-by: Frederik Kriewitz <frederik@kriewitz.eu>
---
mach-types.h needs to be synced (MACH_TYPE_DEVKIT8000)
---
 MAINTAINERS                   |    4 +
 MAKEALL                       |    1 +
 Makefile                      |    3 +
 board/devkit8000/Makefile     |   52 ++++++
 board/devkit8000/config.mk    |   35 ++++
 board/devkit8000/devkit8000.c |  127 ++++++++++++++
 board/devkit8000/devkit8000.h |  373 +++++++++++++++++++++++++++++++++++++++++
 doc/README.devkit8000         |    8 +
 include/configs/devkit8000.h  |  322 +++++++++++++++++++++++++++++++++++
 9 files changed, 925 insertions(+), 0 deletions(-)
 create mode 100644 board/devkit8000/Makefile
 create mode 100644 board/devkit8000/config.mk
 create mode 100644 board/devkit8000/devkit8000.c
 create mode 100644 board/devkit8000/devkit8000.h
 create mode 100644 doc/README.devkit8000
 create mode 100644 include/configs/devkit8000.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 620604c..03b2d10 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -706,6 +706,10 @@ Alex Z
 	lart		SA1100
 	dnp1110		SA1110
 
+Frederik Kriewitz <frederik@kriewitz.eu>
+
+	devkit8000	ARM CORTEX-A8 (OMAP3530 SoC)
+
 -------------------------------------------------------------------------
 
 Unknown / orphaned boards:
diff --git a/MAKEALL b/MAKEALL
index edebaea..34235b7 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8="		\
 	omap3_pandora		\
 	omap3_zoom1		\
 	omap3_zoom2		\
+	devkit8000	\
 "
 
 #########################################################################
diff --git a/Makefile b/Makefile
index 329e0f5..9e3aa11 100644
--- a/Makefile
+++ b/Makefile
@@ -3066,6 +3066,9 @@ SMN42_config	:	unconfig
 ## ARM CORTEX Systems
 #########################################################################
 
+devkit8000_config :	unconfig
+	@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 NULL omap3
+
 omap3_beagle_config :	unconfig
 	@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle omap3 omap3
 
diff --git a/board/devkit8000/Makefile b/board/devkit8000/Makefile
new file mode 100644
index 0000000..38600c4
--- /dev/null
+++ b/board/devkit8000/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# (C) Copyright 2009
+# Frederik Kriewitz <frederik@kriewitz.eu>
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	:= devkit8000.o
+
+SRCS	:= $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+	rm -f $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak $(obj).depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/devkit8000/config.mk b/board/devkit8000/config.mk
new file mode 100644
index 0000000..6bfcef7
--- /dev/null
+++ b/board/devkit8000/config.mk
@@ -0,0 +1,35 @@
+#
+# (C) Copyright 2006
+# Texas Instruments, <www.ti.com>
+#
+# (C) Copyright 2009
+# Frederik Kriewitz <frederik@kriewitz.eu>
+#
+# DevKit8000 uses OMAP3 (ARM-CortexA8) cpu
+# see http://www.ti.com/ for more information on Texas Instruments
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+# Physical Address:
+# 8000'0000 (bank0)
+# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
+# (mem base + reserved)
+
+# For use with external or internal boots.
+TEXT_BASE = 0x80e80000
diff --git a/board/devkit8000/devkit8000.c b/board/devkit8000/devkit8000.c
new file mode 100644
index 0000000..f9070d0
--- /dev/null
+++ b/board/devkit8000/devkit8000.c
@@ -0,0 +1,127 @@
+/*
+ * (C) Copyright 2004-2008
+ * Texas Instruments, <www.ti.com>
+ *
+ * Author :
+ *	Sunil Kumar <sunilsaini05@gmail.com>
+ *	Shashi Ranjan <shashiranjanmca05@gmail.com>
+ *
+ * (C) Copyright 2009
+ * Frederik Kriewitz <frederik@kriewitz.eu>
+ *
+ * Derived from Beagle Board and 3430 SDP code by
+ *	Richard Woodruff <r-woodruff2@ti.com>
+ *	Syed Mohammed Khasim <khasim@ti.com>
+ *
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <common.h>
+#include <twl4030.h>
+#include <asm/io.h>
+#include <asm/arch/mux.h>
+#include <asm/arch/sys_proto.h>
+#include <asm/arch/mem.h>
+#include <asm/mach-types.h>
+#include "devkit8000.h"
+#ifdef CONFIG_DRIVER_DM9000
+#include <net.h>
+#include <netdev.h>
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Routine: board_init
+ * Description: Early hardware init.
+ */
+int board_init(void)
+{
+	gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+	/* board id for Linux */
+	gd->bd->bi_arch_number = MACH_TYPE_DEVKIT8000;
+	/* boot param addr */
+	gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+
+	return 0;
+}
+
+/*
+ * Routine: misc_init_r
+ * Description: Configure board specific parts
+ */
+int misc_init_r(void)
+{
+	struct ctrl_id *id_base = (struct ctrl_id *)OMAP34XX_ID_L4_IO_BASE;
+#ifdef CONFIG_DRIVER_DM9000
+	uchar enetaddr[6];
+	u32 die_id_0;
+#endif
+
+	twl4030_power_init();
+#ifdef CONFIG_TWL4030_LED
+	twl4030_led_init();
+#endif
+
+#ifdef CONFIG_DRIVER_DM9000
+	/* Configure GPMC registers for DM9000 */
+	writel(NET_GPMC_CONFIG1, &gpmc_cfg->cs[6].config1);
+	writel(NET_GPMC_CONFIG2, &gpmc_cfg->cs[6].config2);
+	writel(NET_GPMC_CONFIG3, &gpmc_cfg->cs[6].config3);
+	writel(NET_GPMC_CONFIG4, &gpmc_cfg->cs[6].config4);
+	writel(NET_GPMC_CONFIG5, &gpmc_cfg->cs[6].config5);
+	writel(NET_GPMC_CONFIG6, &gpmc_cfg->cs[6].config6);
+	writel(NET_GPMC_CONFIG7, &gpmc_cfg->cs[6].config7);
+
+	/* Use OMAP DIE_ID as MAC address */
+	if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
+		printf("ethaddr not set, using Die ID\n");
+		die_id_0 = readl(&id_base->die_id_0);
+		enetaddr[0] = 0x02; /* locally administered */
+		enetaddr[1] = readl(&id_base->die_id_1) & 0xff;
+		enetaddr[2] = (die_id_0 & 0xff000000) >> 24;
+		enetaddr[3] = (die_id_0 & 0x00ff0000) >> 16;
+		enetaddr[4] = (die_id_0 & 0x0000ff00) >> 8;
+		enetaddr[5] = (die_id_0 & 0x000000ff);
+		eth_setenv_enetaddr("ethaddr", enetaddr);
+	}
+#endif
+
+	dieid_num_r();
+
+	return 0;
+}
+
+/*
+ * Routine: set_muxconf_regs
+ * Description: Setting up the configuration Mux registers specific to the
+ *		hardware. Many pins need to be moved from protect to primary
+ *		mode.
+ */
+void set_muxconf_regs(void)
+{
+	MUX_DEVKIT8000();
+}
+
+#ifdef CONFIG_DRIVER_DM9000
+int board_eth_init(bd_t *bis)
+{
+	return dm9000_initialize(bis);
+}
+#endif
diff --git a/board/devkit8000/devkit8000.h b/board/devkit8000/devkit8000.h
new file mode 100644
index 0000000..6fcc75a
--- /dev/null
+++ b/board/devkit8000/devkit8000.h
@@ -0,0 +1,373 @@
+/*
+ * (C) Copyright 2008
+ * Dirk Behme <dirk.behme@gmail.com>
+ *
+ * (C) Copyright 2009
+ * Frederik Kriewitz <frederik@kriewitz.eu>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _DEVKIT8000_H_
+#define _DEVKIT8000_H_
+
+const omap3_sysinfo sysinfo = {
+	DDR_STACKED,
+	"OMAP3 DevKit8000",
+	"NAND",
+};
+
+/*
+ * IEN  - Input Enable
+ * IDIS - Input Disable
+ * PTD  - Pull type Down
+ * PTU  - Pull type Up
+ * DIS  - Pull type selection is inactive
+ * EN   - Pull type selection is active
+ * M0   - Mode 0
+ * The commented string gives the final mux configuration for that pin
+ */
+
+#define MUX_DEVKIT8000() \
+ /* SDRC */\
+ MUX_VAL(CP(SDRC_D0),		(IEN  | PTD | DIS | M0)) /*SDRC_D0*/\
+ MUX_VAL(CP(SDRC_D1),		(IEN  | PTD | DIS | M0)) /*SDRC_D1*/\
+ MUX_VAL(CP(SDRC_D2),		(IEN  | PTD | DIS | M0)) /*SDRC_D2*/\
+ MUX_VAL(CP(SDRC_D3),		(IEN  | PTD | DIS | M0)) /*SDRC_D3*/\
+ MUX_VAL(CP(SDRC_D4),		(IEN  | PTD | DIS | M0)) /*SDRC_D4*/\
+ MUX_VAL(CP(SDRC_D5),		(IEN  | PTD | DIS | M0)) /*SDRC_D5*/\
+ MUX_VAL(CP(SDRC_D6),		(IEN  | PTD | DIS | M0)) /*SDRC_D6*/\
+ MUX_VAL(CP(SDRC_D7),		(IEN  | PTD | DIS | M0)) /*SDRC_D7*/\
+ MUX_VAL(CP(SDRC_D8),		(IEN  | PTD | DIS | M0)) /*SDRC_D8*/\
+ MUX_VAL(CP(SDRC_D9),		(IEN  | PTD | DIS | M0)) /*SDRC_D9*/\
+ MUX_VAL(CP(SDRC_D10),		(IEN  | PTD | DIS | M0)) /*SDRC_D10*/\
+ MUX_VAL(CP(SDRC_D11),		(IEN  | PTD | DIS | M0)) /*SDRC_D11*/\
+ MUX_VAL(CP(SDRC_D12),		(IEN  | PTD | DIS | M0)) /*SDRC_D12*/\
+ MUX_VAL(CP(SDRC_D13),		(IEN  | PTD | DIS | M0)) /*SDRC_D13*/\
+ MUX_VAL(CP(SDRC_D14),		(IEN  | PTD | DIS | M0)) /*SDRC_D14*/\
+ MUX_VAL(CP(SDRC_D15),		(IEN  | PTD | DIS | M0)) /*SDRC_D15*/\
+ MUX_VAL(CP(SDRC_D16),		(IEN  | PTD | DIS | M0)) /*SDRC_D16*/\
+ MUX_VAL(CP(SDRC_D17),		(IEN  | PTD | DIS | M0)) /*SDRC_D17*/\
+ MUX_VAL(CP(SDRC_D18),		(IEN  | PTD | DIS | M0)) /*SDRC_D18*/\
+ MUX_VAL(CP(SDRC_D19),		(IEN  | PTD | DIS | M0)) /*SDRC_D19*/\
+ MUX_VAL(CP(SDRC_D20),		(IEN  | PTD | DIS | M0)) /*SDRC_D20*/\
+ MUX_VAL(CP(SDRC_D21),		(IEN  | PTD | DIS | M0)) /*SDRC_D21*/\
+ MUX_VAL(CP(SDRC_D22),		(IEN  | PTD | DIS | M0)) /*SDRC_D22*/\
+ MUX_VAL(CP(SDRC_D23),		(IEN  | PTD | DIS | M0)) /*SDRC_D23*/\
+ MUX_VAL(CP(SDRC_D24),		(IEN  | PTD | DIS | M0)) /*SDRC_D24*/\
+ MUX_VAL(CP(SDRC_D25),		(IEN  | PTD | DIS | M0)) /*SDRC_D25*/\
+ MUX_VAL(CP(SDRC_D26),		(IEN  | PTD | DIS | M0)) /*SDRC_D26*/\
+ MUX_VAL(CP(SDRC_D27),		(IEN  | PTD | DIS | M0)) /*SDRC_D27*/\
+ MUX_VAL(CP(SDRC_D28),		(IEN  | PTD | DIS | M0)) /*SDRC_D28*/\
+ MUX_VAL(CP(SDRC_D29),		(IEN  | PTD | DIS | M0)) /*SDRC_D29*/\
+ MUX_VAL(CP(SDRC_D30),		(IEN  | PTD | DIS | M0)) /*SDRC_D30*/\
+ MUX_VAL(CP(SDRC_D31),		(IEN  | PTD | DIS | M0)) /*SDRC_D31*/\
+ MUX_VAL(CP(SDRC_CLK),		(IEN  | PTD | DIS | M0)) /*SDRC_CLK*/\
+ MUX_VAL(CP(SDRC_DQS0),		(IEN  | PTD | DIS | M0)) /*SDRC_DQS0*/\
+ MUX_VAL(CP(SDRC_DQS1),		(IEN  | PTD | DIS | M0)) /*SDRC_DQS1*/\
+ MUX_VAL(CP(SDRC_DQS2),		(IEN  | PTD | DIS | M0)) /*SDRC_DQS2*/\
+ MUX_VAL(CP(SDRC_DQS3),		(IEN  | PTD | DIS | M0)) /*SDRC_DQS3*/\
+ /* GPMC */\
+ MUX_VAL(CP(GPMC_A1),		(IDIS | PTD | DIS | M0)) /*GPMC_A1*/\
+ MUX_VAL(CP(GPMC_A2),		(IDIS | PTD | DIS | M0)) /*GPMC_A2*/\
+ MUX_VAL(CP(GPMC_A3),		(IDIS | PTD | DIS | M0)) /*GPMC_A3*/\
+ MUX_VAL(CP(GPMC_A4),		(IDIS | PTD | DIS | M0)) /*GPMC_A4*/\
+ MUX_VAL(CP(GPMC_A5),		(IDIS | PTD | DIS | M0)) /*GPMC_A5*/\
+ MUX_VAL(CP(GPMC_A6),		(IDIS | PTD | DIS | M0)) /*GPMC_A6*/\
+ MUX_VAL(CP(GPMC_A7),		(IDIS | PTD | DIS | M0)) /*GPMC_A7*/\
+ MUX_VAL(CP(GPMC_A8),		(IDIS | PTD | DIS | M0)) /*GPMC_A8*/\
+ MUX_VAL(CP(GPMC_A9),		(IDIS | PTD | DIS | M0)) /*GPMC_A9*/\
+ MUX_VAL(CP(GPMC_A10),		(IDIS | PTD | DIS | M0)) /*GPMC_A10*/\
+ MUX_VAL(CP(GPMC_D0),		(IEN  | PTD | DIS | M0)) /*GPMC_D0*/\
+ MUX_VAL(CP(GPMC_D1),		(IEN  | PTD | DIS | M0)) /*GPMC_D1*/\
+ MUX_VAL(CP(GPMC_D2),		(IEN  | PTD | DIS | M0)) /*GPMC_D2*/\
+ MUX_VAL(CP(GPMC_D3),		(IEN  | PTD | DIS | M0)) /*GPMC_D3*/\
+ MUX_VAL(CP(GPMC_D4),		(IEN  | PTD | DIS | M0)) /*GPMC_D4*/\
+ MUX_VAL(CP(GPMC_D5),		(IEN  | PTD | DIS | M0)) /*GPMC_D5*/\
+ MUX_VAL(CP(GPMC_D6),		(IEN  | PTD | DIS | M0)) /*GPMC_D6*/\
+ MUX_VAL(CP(GPMC_D7),		(IEN  | PTD | DIS | M0)) /*GPMC_D7*/\
+ MUX_VAL(CP(GPMC_D8),		(IEN  | PTD | DIS | M0)) /*GPMC_D8*/\
+ MUX_VAL(CP(GPMC_D9),		(IEN  | PTD | DIS | M0)) /*GPMC_D9*/\
+ MUX_VAL(CP(GPMC_D10),		(IEN  | PTD | DIS | M0)) /*GPMC_D10*/\
+ MUX_VAL(CP(GPMC_D11),		(IEN  | PTD | DIS | M0)) /*GPMC_D11*/\
+ MUX_VAL(CP(GPMC_D12),		(IEN  | PTD | DIS | M0)) /*GPMC_D12*/\
+ MUX_VAL(CP(GPMC_D13),		(IEN  | PTD | DIS | M0)) /*GPMC_D13*/\
+ MUX_VAL(CP(GPMC_D14),		(IEN  | PTD | DIS | M0)) /*GPMC_D14*/\
+ MUX_VAL(CP(GPMC_D15),		(IEN  | PTD | DIS | M0)) /*GPMC_D15*/\
+ MUX_VAL(CP(GPMC_NCS0),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS0 NAND*/\
+ MUX_VAL(CP(GPMC_NCS1),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS1*/\
+ MUX_VAL(CP(GPMC_NCS2),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS2*/\
+ MUX_VAL(CP(GPMC_NCS3),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS3*/\
+ MUX_VAL(CP(GPMC_NCS4),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS4*/\
+ MUX_VAL(CP(GPMC_NCS5),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS5*/\
+ MUX_VAL(CP(GPMC_NCS6),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS6 DM9000*/\
+ MUX_VAL(CP(GPMC_NCS7),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS7*/\
+ MUX_VAL(CP(GPMC_NBE1),		(IEN  | PTD | DIS | M0)) /*GPMC_nBE1*/\
+ MUX_VAL(CP(GPMC_WAIT2),	(IEN  | PTU | EN  | M0)) /*GPMC_WAIT2*/\
+ MUX_VAL(CP(GPMC_WAIT3),	(IEN  | PTU | EN  | M0)) /*GPMC_WAIT3*/\
+ MUX_VAL(CP(GPMC_CLK),		(IDIS | PTD | DIS | M0)) /*GPMC_CLK*/\
+ MUX_VAL(CP(GPMC_NADV_ALE),	(IDIS | PTD | DIS | M0)) /*GPMC_nADV_ALE*/\
+ MUX_VAL(CP(GPMC_NOE),		(IDIS | PTD | DIS | M0)) /*GPMC_nOE*/\
+ MUX_VAL(CP(GPMC_NWE),		(IDIS | PTD | DIS | M0)) /*GPMC_nWE*/\
+ MUX_VAL(CP(GPMC_NBE0_CLE),	(IDIS | PTD | DIS | M0)) /*GPMC_nBE0_CLE*/\
+ MUX_VAL(CP(GPMC_NWP),		(IEN  | PTD | DIS | M0)) /*GPMC_nWP*/\
+ MUX_VAL(CP(GPMC_WAIT0),	(IEN  | PTU | EN  | M0)) /*GPMC_WAIT0*/\
+ MUX_VAL(CP(GPMC_WAIT1),	(IEN  | PTU | EN  | M0)) /*GPMC_WAIT1*/\
+ /* DSS */\
+ MUX_VAL(CP(DSS_PCLK),		(IDIS | PTD | DIS | M0)) /*DSS_PCLK*/\
+ MUX_VAL(CP(DSS_HSYNC),		(IDIS | PTD | DIS | M0)) /*DSS_HSYNC*/\
+ MUX_VAL(CP(DSS_VSYNC),		(IDIS | PTD | DIS | M0)) /*DSS_VSYNC*/\
+ MUX_VAL(CP(DSS_ACBIAS),	(IDIS | PTD | DIS | M0)) /*DSS_ACBIAS*/\
+ MUX_VAL(CP(DSS_DATA0),		(IDIS | PTD | DIS | M0)) /*DSS_DATA0*/\
+ MUX_VAL(CP(DSS_DATA1),		(IDIS | PTD | DIS | M0)) /*DSS_DATA1*/\
+ MUX_VAL(CP(DSS_DATA2),		(IDIS | PTD | DIS | M0)) /*DSS_DATA2*/\
+ MUX_VAL(CP(DSS_DATA3),		(IDIS | PTD | DIS | M0)) /*DSS_DATA3*/\
+ MUX_VAL(CP(DSS_DATA4),		(IDIS | PTD | DIS | M0)) /*DSS_DATA4*/\
+ MUX_VAL(CP(DSS_DATA5),		(IDIS | PTD | DIS | M0)) /*DSS_DATA5*/\
+ MUX_VAL(CP(DSS_DATA6),		(IDIS | PTD | DIS | M0)) /*DSS_DATA6*/\
+ MUX_VAL(CP(DSS_DATA7),		(IDIS | PTD | DIS | M0)) /*DSS_DATA7*/\
+ MUX_VAL(CP(DSS_DATA8),		(IDIS | PTD | DIS | M0)) /*DSS_DATA8*/\
+ MUX_VAL(CP(DSS_DATA9),		(IDIS | PTD | DIS | M0)) /*DSS_DATA9*/\
+ MUX_VAL(CP(DSS_DATA10),	(IDIS | PTD | DIS | M0)) /*DSS_DATA10*/\
+ MUX_VAL(CP(DSS_DATA11),	(IDIS | PTD | DIS | M0)) /*DSS_DATA11*/\
+ MUX_VAL(CP(DSS_DATA12),	(IDIS | PTD | DIS | M0)) /*DSS_DATA12*/\
+ MUX_VAL(CP(DSS_DATA13),	(IDIS | PTD | DIS | M0)) /*DSS_DATA13*/\
+ MUX_VAL(CP(DSS_DATA14),	(IDIS | PTD | DIS | M0)) /*DSS_DATA14*/\
+ MUX_VAL(CP(DSS_DATA15),	(IDIS | PTD | DIS | M0)) /*DSS_DATA15*/\
+ MUX_VAL(CP(DSS_DATA16),	(IDIS | PTD | DIS | M0)) /*DSS_DATA16*/\
+ MUX_VAL(CP(DSS_DATA17),	(IDIS | PTD | DIS | M0)) /*DSS_DATA17*/\
+ MUX_VAL(CP(DSS_DATA18),	(IDIS | PTD | DIS | M0)) /*DSS_DATA18*/\
+ MUX_VAL(CP(DSS_DATA19),	(IDIS | PTD | DIS | M0)) /*DSS_DATA19*/\
+ MUX_VAL(CP(DSS_DATA20),	(IDIS | PTD | DIS | M0)) /*DSS_DATA20*/\
+ MUX_VAL(CP(DSS_DATA21),	(IDIS | PTD | DIS | M0)) /*DSS_DATA21*/\
+ MUX_VAL(CP(DSS_DATA22),	(IDIS | PTD | DIS | M0)) /*DSS_DATA22*/\
+ MUX_VAL(CP(DSS_DATA23),	(IDIS | PTD | DIS | M0)) /*DSS_DATA23*/\
+ /* CAMERA */\
+ MUX_VAL(CP(CAM_HS),		(IEN  | PTU | EN  | M0)) /*CAM_HS */\
+ MUX_VAL(CP(CAM_VS),		(IEN  | PTU | EN  | M0)) /*CAM_VS */\
+ MUX_VAL(CP(CAM_XCLKA),		(IDIS | PTD | DIS | M0)) /*CAM_XCLKA*/\
+ MUX_VAL(CP(CAM_PCLK),		(IEN  | PTU | EN  | M0)) /*CAM_PCLK*/\
+ MUX_VAL(CP(CAM_FLD),		(IDIS | PTD | DIS | M4)) /*GPIO_98*/\
+ MUX_VAL(CP(CAM_D0),		(IEN  | PTD | DIS | M0)) /*CAM_D0*/\
+ MUX_VAL(CP(CAM_D1),		(IEN  | PTD | DIS | M0)) /*CAM_D1*/\
+ MUX_VAL(CP(CAM_D2),		(IEN  | PTD | DIS | M0)) /*CAM_D2*/\
+ MUX_VAL(CP(CAM_D3),		(IEN  | PTD | DIS | M0)) /*CAM_D3*/\
+ MUX_VAL(CP(CAM_D4),		(IEN  | PTD | DIS | M0)) /*CAM_D4*/\
+ MUX_VAL(CP(CAM_D5),		(IEN  | PTD | DIS | M0)) /*CAM_D5*/\
+ MUX_VAL(CP(CAM_D6),		(IEN  | PTD | DIS | M0)) /*CAM_D6*/\
+ MUX_VAL(CP(CAM_D7),		(IEN  | PTD | DIS | M0)) /*CAM_D7*/\
+ MUX_VAL(CP(CAM_D8),		(IEN  | PTD | DIS | M0)) /*CAM_D8*/\
+ MUX_VAL(CP(CAM_D9),		(IEN  | PTD | DIS | M0)) /*CAM_D9*/\
+ MUX_VAL(CP(CAM_D10),		(IEN  | PTD | DIS | M0)) /*CAM_D10*/\
+ MUX_VAL(CP(CAM_D11),		(IEN  | PTD | DIS | M0)) /*CAM_D11*/\
+ MUX_VAL(CP(CAM_XCLKB),		(IDIS | PTD | DIS | M0)) /*CAM_XCLKB*/\
+ MUX_VAL(CP(CAM_WEN),		(IEN  | PTD | DIS | M4)) /*GPIO_167*/\
+ MUX_VAL(CP(CAM_STROBE),	(IDIS | PTD | DIS | M0)) /*CAM_STROBE*/\
+ MUX_VAL(CP(CSI2_DX0),		(IEN  | PTD | DIS | M0)) /*CSI2_DX0*/\
+ MUX_VAL(CP(CSI2_DY0),		(IEN  | PTD | DIS | M0)) /*CSI2_DY0*/\
+ MUX_VAL(CP(CSI2_DX1),		(IEN  | PTD | DIS | M0)) /*CSI2_DX1*/\
+ MUX_VAL(CP(CSI2_DY1),		(IEN  | PTD | DIS | M0)) /*CSI2_DY1*/\
+ /* Audio Interface */\
+ MUX_VAL(CP(MCBSP2_FSX),	(IEN  | PTD | DIS | M0)) /*McBSP2_FSX*/\
+ MUX_VAL(CP(MCBSP2_CLKX),	(IEN  | PTD | DIS | M0)) /*McBSP2_CLKX*/\
+ MUX_VAL(CP(MCBSP2_DR),		(IEN  | PTD | DIS | M0)) /*McBSP2_DR*/\
+ MUX_VAL(CP(MCBSP2_DX),		(IDIS | PTD | DIS | M0)) /*McBSP2_DX*/\
+ /* MMC Slot */\
+ MUX_VAL(CP(MMC1_CLK),		(IDIS | PTU | EN  | M0)) /*MMC1_CLK*/\
+ MUX_VAL(CP(MMC1_CMD),		(IEN  | PTU | EN  | M0)) /*MMC1_CMD*/\
+ MUX_VAL(CP(MMC1_DAT0),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT0*/\
+ MUX_VAL(CP(MMC1_DAT1),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT1*/\
+ MUX_VAL(CP(MMC1_DAT2),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT2*/\
+ MUX_VAL(CP(MMC1_DAT3),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT3*/\
+ MUX_VAL(CP(MMC1_DAT4),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT4*/\
+ MUX_VAL(CP(MMC1_DAT5),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT5*/\
+ MUX_VAL(CP(MMC1_DAT6),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT6*/\
+ MUX_VAL(CP(MMC1_DAT7),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT7*/\
+ /* Expansion Header */\
+ MUX_VAL(CP(MMC2_CLK),		(IEN  | PTU | EN  | M4)) /*GPIO_130*/\
+ MUX_VAL(CP(MMC2_CMD),		(IEN  | PTU | EN  | M4)) /*GPIO_131*/\
+ MUX_VAL(CP(MMC2_DAT0),		(IEN  | PTU | EN  | M4)) /*GPIO_132*/\
+ MUX_VAL(CP(MMC2_DAT1),		(IEN  | PTU | EN  | M4)) /*GPIO_133*/\
+ MUX_VAL(CP(MMC2_DAT2),		(IEN  | PTU | EN  | M4)) /*GPIO_134*/\
+ MUX_VAL(CP(MMC2_DAT3),		(IEN  | PTU | EN  | M4)) /*GPIO_135*/\
+ MUX_VAL(CP(MMC2_DAT4),		(IEN  | PTU | EN  | M4)) /*GPIO_136*/\
+ MUX_VAL(CP(MMC2_DAT5),		(IEN  | PTU | EN  | M4)) /*GPIO_137*/\
+ MUX_VAL(CP(MMC2_DAT6),		(IEN  | PTU | EN  | M4)) /*GPIO_138*/\
+ MUX_VAL(CP(MMC2_DAT7),		(IEN  | PTU | EN  | M4)) /*GPIO_139*/\
+ MUX_VAL(CP(MCBSP3_DX),		(IDIS | PTD | DIS | M4)) /*GPIO_140*/\
+ MUX_VAL(CP(MCBSP3_DR),		(IDIS | PTD | DIS | M4)) /*GPIO_141*/\
+ MUX_VAL(CP(MCBSP3_CLKX),	(IDIS | PTD | DIS | M4)) /*GPIO_142*/\
+ MUX_VAL(CP(MCBSP3_FSX),	(IDIS | PTD | DIS | M4)) /*GPIO_143*/\
+ MUX_VAL(CP(UART2_CTS),		(IDIS | PTD | DIS | M4)) /*GPIO_144*/\
+ MUX_VAL(CP(UART2_RTS),		(IDIS | PTD | DIS | M4)) /*GPIO_145*/\
+ MUX_VAL(CP(UART2_TX),		(IDIS | PTD | DIS | M4)) /*GPIO_146*/\
+ MUX_VAL(CP(UART2_RX),		(IDIS | PTD | DIS | M4)) /*GPIO_147*/\
+ MUX_VAL(CP(UART1_TX),		(IDIS | PTD | DIS | M0)) /*GPIO_148*/\
+ MUX_VAL(CP(UART1_RTS),		(IDIS | PTD | DIS | M4)) /*GPIO_149*/ \
+ MUX_VAL(CP(UART1_CTS),		(IDIS | PTD | DIS | M4)) /*GPIO_150*/ \
+ MUX_VAL(CP(UART1_RX),		(IEN  | PTD | DIS | M0)) /*GPIO_151*/\
+ MUX_VAL(CP(MCBSP4_CLKX),	(IEN  | PTD | DIS | M1)) /*GPIO_152*/\
+ MUX_VAL(CP(MCBSP4_DR),		(IEN  | PTD | DIS | M1)) /*GPIO_153*/\
+ MUX_VAL(CP(MCBSP4_DX),		(IEN  | PTD | DIS | M1)) /*GPIO_154*/\
+ MUX_VAL(CP(MCBSP4_FSX),	(IEN  | PTD | DIS | M1)) /*GPIO_155*/\
+ MUX_VAL(CP(MCBSP1_CLKR),	(IDIS | PTD | DIS | M4)) /*GPIO_156*/\
+ MUX_VAL(CP(MCBSP1_FSR),	(IDIS | PTU | EN  | M4)) /*GPIO_157*/\
+ MUX_VAL(CP(MCBSP1_DX),		(IDIS | PTD | DIS | M4)) /*GPIO_158*/\
+ MUX_VAL(CP(MCBSP1_DR),		(IDIS | PTD | DIS | M4)) /*GPIO_159*/\
+ MUX_VAL(CP(MCBSP_CLKS),	(IEN  | PTU | DIS | M0)) /*GPIO_160*/\
+ MUX_VAL(CP(MCBSP1_FSX),	(IDIS | PTD | DIS | M4)) /*GPIO_161*/\
+ MUX_VAL(CP(MCBSP1_CLKX),	(IDIS | PTD | DIS | M4)) /*GPIO_162*/\
+ /* Serial Interface */\
+ MUX_VAL(CP(UART3_CTS_RCTX),	(IDIS | PTD | EN  | M4)) /*GPIO_163 - LED2*/\
+ MUX_VAL(CP(UART3_RTS_SD),	(IDIS | PTU | EN  | M4)) /*GPIO_164 - LED3*/\
+ MUX_VAL(CP(UART3_RX_IRRX),	(IEN  | PTD | DIS | M0)) /*UART3_RX_IRRX*/\
+ MUX_VAL(CP(UART3_TX_IRTX),	(IDIS | PTD | DIS | M0)) /*UART3_TX_IRTX*/\
+ /* Host USB0 */\
+ MUX_VAL(CP(HSUSB0_CLK),	(IEN  | PTD | DIS | M0)) /*HSUSB0_CLK*/\
+ MUX_VAL(CP(HSUSB0_STP),	(IDIS | PTU | EN  | M0)) /*HSUSB0_STP*/\
+ MUX_VAL(CP(HSUSB0_DIR),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DIR*/\
+ MUX_VAL(CP(HSUSB0_NXT),	(IEN  | PTD | DIS | M0)) /*HSUSB0_NXT*/\
+ MUX_VAL(CP(HSUSB0_DATA0),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA0*/\
+ MUX_VAL(CP(HSUSB0_DATA1),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA1*/\
+ MUX_VAL(CP(HSUSB0_DATA2),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA2*/\
+ MUX_VAL(CP(HSUSB0_DATA3),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA3*/\
+ MUX_VAL(CP(HSUSB0_DATA4),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA4*/\
+ MUX_VAL(CP(HSUSB0_DATA5),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA5*/\
+ MUX_VAL(CP(HSUSB0_DATA6),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA6*/\
+ MUX_VAL(CP(HSUSB0_DATA7),	(IEN  | PTD | DIS | M0)) /*HSUSB0_DATA7*/\
+ MUX_VAL(CP(I2C1_SCL),		(IEN  | PTU | EN  | M0)) /*I2C1_SCL*/\
+ MUX_VAL(CP(I2C1_SDA),		(IEN  | PTU | EN  | M0)) /*I2C1_SDA*/\
+ MUX_VAL(CP(I2C2_SCL),		(IDIS | PTU | DIS | M4)) /*GPIO_168*/\
+ MUX_VAL(CP(I2C2_SDA),		(IEN  | PTU | EN  | M4)) /*GPIO_183*/\
+ MUX_VAL(CP(I2C3_SCL),		(IEN  | PTU | EN  | M0)) /*I2C3_SCL*/\
+ MUX_VAL(CP(I2C3_SDA),		(IEN  | PTU | EN  | M0)) /*I2C3_SDA*/\
+ MUX_VAL(CP(I2C4_SCL),		(IEN  | PTU | EN  | M0)) /*I2C4_SCL*/\
+ MUX_VAL(CP(I2C4_SDA),		(IEN  | PTU | DIS | M0)) /*I2C4_SDA*/\
+ MUX_VAL(CP(HDQ_SIO),		(IDIS | PTD | DIS | M4)) /*GPIO_170*/\
+ MUX_VAL(CP(MCSPI1_CLK),	(IEN  | PTD | DIS | M4)) /*GPIO_171*/\
+ MUX_VAL(CP(MCSPI1_SIMO),	(IEN  | PTD | DIS | M4)) /*GPIO_172*/\
+ MUX_VAL(CP(MCSPI1_SOMI),	(IEN  | PTD | DIS | M0)) /*MCSPI1_SOMI*/\
+ MUX_VAL(CP(MCSPI1_CS0),	(IEN  | PTD | DIS | M0)) /*MCSPI1_CS0*/\
+ MUX_VAL(CP(MCSPI1_CS1),	(IDIS | PTD | DIS | M0)) /*MCSPI1_CS1*/\
+ MUX_VAL(CP(MCSPI1_CS2),	(IDIS | PTD | DIS | M4)) /*GPIO_176*/\
+ /* USB EHCI (port 2) */\
+ MUX_VAL(CP(MCSPI1_CS3),	(IEN  | PTD | EN  | M0)) /*HSUSB2_DATA2*/\
+ MUX_VAL(CP(MCSPI2_CLK),	(IEN  | PTD | DIS | M0)) /*HSUSB2_DATA7*/\
+ MUX_VAL(CP(MCSPI2_SIMO),	(IEN  | PTD | DIS | M0)) /*HSUSB2_DATA4*/\
+ MUX_VAL(CP(MCSPI2_SOMI),	(IEN  | PTD | DIS | M0)) /*HSUSB2_DATA5*/\
+ MUX_VAL(CP(MCSPI2_CS0),	(IEN  | PTD | EN  | M0)) /*HSUSB2_DATA6*/\
+ MUX_VAL(CP(MCSPI2_CS1),	(IEN  | PTD | EN  | M0)) /*HSUSB2_DATA3*/\
+ /*Control and debug */\
+ MUX_VAL(CP(SYS_32K),		(IEN  | PTD | DIS | M0)) /*SYS_32K*/\
+ MUX_VAL(CP(SYS_CLKREQ),	(IEN  | PTD | DIS | M0)) /*SYS_CLKREQ*/\
+ MUX_VAL(CP(SYS_NIRQ),		(IEN  | PTU | EN  | M0)) /*SYS_nIRQ*/\
+ MUX_VAL(CP(SYS_BOOT0),		(IEN  | PTD | DIS | M4)) /*GPIO_2*/\
+ MUX_VAL(CP(SYS_BOOT1),		(IEN  | PTD | DIS | M4)) /*GPIO_3*/\
+ MUX_VAL(CP(SYS_BOOT2),		(IEN  | PTD | DIS | M4)) /*GPIO_4 - MMC1_WP*/\
+ MUX_VAL(CP(SYS_BOOT3),		(IEN  | PTD | DIS | M4)) /*GPIO_5*/\
+ MUX_VAL(CP(SYS_BOOT4),		(IEN  | PTD | DIS | M4)) /*GPIO_6*/\
+ MUX_VAL(CP(SYS_BOOT5),		(IEN  | PTD | DIS | M4)) /*GPIO_7*/\
+ MUX_VAL(CP(SYS_BOOT6),		(IDIS | PTD | DIS | M4)) /*GPIO_8*/ \
+ MUX_VAL(CP(SYS_OFF_MODE),	(IEN  | PTD | DIS | M0)) /*SYS_OFF_MODE*/\
+ MUX_VAL(CP(SYS_CLKOUT1),	(IDIS | PTD | EN  | M0)) /*SYS_CLKOUT1*/\
+ MUX_VAL(CP(SYS_CLKOUT2),	(IDIS | PTU | EN  | M4)) /*GPIO_186 - LED1*/\
+ MUX_VAL(CP(ETK_CLK_ES2),	(IDIS | PTD | DIS | M3)) /*HSUSB1_STP*/\
+ MUX_VAL(CP(ETK_CTL_ES2),	(IDIS | PTD | EN  | M3)) /*HSUSB1_CLK*/\
+ MUX_VAL(CP(ETK_D0_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA0*/\
+ MUX_VAL(CP(ETK_D1_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA1*/\
+ MUX_VAL(CP(ETK_D2_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA2*/\
+ MUX_VAL(CP(ETK_D3_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA7*/\
+ MUX_VAL(CP(ETK_D4_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA4*/\
+ MUX_VAL(CP(ETK_D5_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA5*/\
+ MUX_VAL(CP(ETK_D6_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA6*/\
+ MUX_VAL(CP(ETK_D7_ES2),	(IDIS | PTU | EN  | M3)) /*HSUSB1_DATA3*/\
+ MUX_VAL(CP(ETK_D8_ES2),	(IEN  | PTD | DIS | M3)) /*HSUSB1_DIR*/\
+ MUX_VAL(CP(ETK_D9_ES2),	(IEN  | PTD | DIS | M3)) /*HSUSB1_NXT*/\
+ MUX_VAL(CP(ETK_D10_ES2),	(IDIS | PTU | EN  | M4)) /*GPIO_24*/\
+ MUX_VAL(CP(ETK_D11_ES2),	(IEN  | PTU | EN  | M4)) /*GPIO_25*/\
+ MUX_VAL(CP(ETK_D12_ES2),	(IEN  | PTU | EN  | M4)) /*GPIO_26*/\
+ MUX_VAL(CP(ETK_D13_ES2),	(IEN  | PTU | EN  | M4)) /*GPIO_27*/\
+ MUX_VAL(CP(ETK_D14_ES2),	(IEN  | PTU | EN  | M4)) /*GPIO_28*/\
+ MUX_VAL(CP(ETK_D15_ES2),	(IEN  | PTU | EN  | M4)) /*GPIO_29*/\
+ MUX_VAL(CP(D2D_MCAD1),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD1*/\
+ MUX_VAL(CP(D2D_MCAD2),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD2*/\
+ MUX_VAL(CP(D2D_MCAD3),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD3*/\
+ MUX_VAL(CP(D2D_MCAD4),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD4*/\
+ MUX_VAL(CP(D2D_MCAD5),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD5*/\
+ MUX_VAL(CP(D2D_MCAD6),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD6*/\
+ MUX_VAL(CP(D2D_MCAD7),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD7*/\
+ MUX_VAL(CP(D2D_MCAD8),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD8*/\
+ MUX_VAL(CP(D2D_MCAD9),		(IEN  | PTD | EN  | M0)) /*D2D_MCAD9*/\
+ MUX_VAL(CP(D2D_MCAD10),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD10*/\
+ MUX_VAL(CP(D2D_MCAD11),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD11*/\
+ MUX_VAL(CP(D2D_MCAD12),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD12*/\
+ MUX_VAL(CP(D2D_MCAD13),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD13*/\
+ MUX_VAL(CP(D2D_MCAD14),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD14*/\
+ MUX_VAL(CP(D2D_MCAD15),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD15*/\
+ MUX_VAL(CP(D2D_MCAD16),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD16*/\
+ MUX_VAL(CP(D2D_MCAD17),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD17*/\
+ MUX_VAL(CP(D2D_MCAD18),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD18*/\
+ MUX_VAL(CP(D2D_MCAD19),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD19*/\
+ MUX_VAL(CP(D2D_MCAD20),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD20*/\
+ MUX_VAL(CP(D2D_MCAD21),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD21*/\
+ MUX_VAL(CP(D2D_MCAD22),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD22*/\
+ MUX_VAL(CP(D2D_MCAD23),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD23*/\
+ MUX_VAL(CP(D2D_MCAD24),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD24*/\
+ MUX_VAL(CP(D2D_MCAD25),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD25*/\
+ MUX_VAL(CP(D2D_MCAD26),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD26*/\
+ MUX_VAL(CP(D2D_MCAD27),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD27*/\
+ MUX_VAL(CP(D2D_MCAD28),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD28*/\
+ MUX_VAL(CP(D2D_MCAD29),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD29*/\
+ MUX_VAL(CP(D2D_MCAD30),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD30*/\
+ MUX_VAL(CP(D2D_MCAD31),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD31*/\
+ MUX_VAL(CP(D2D_MCAD32),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD32*/\
+ MUX_VAL(CP(D2D_MCAD33),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD33*/\
+ MUX_VAL(CP(D2D_MCAD34),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD34*/\
+ MUX_VAL(CP(D2D_MCAD35),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD35*/\
+ MUX_VAL(CP(D2D_MCAD36),	(IEN  | PTD | EN  | M0)) /*D2D_MCAD36*/\
+ MUX_VAL(CP(D2D_CLK26MI),	(IEN  | PTD | DIS | M0)) /*D2D_clk26mi*/\
+ MUX_VAL(CP(D2D_NRESPWRON),	(IEN  | PTD | EN  | M0)) /*D2D_nrespwron*/\
+ MUX_VAL(CP(D2D_NRESWARM),	(IEN  | PTU | EN  | M0)) /*D2D_nreswarm */\
+ MUX_VAL(CP(D2D_ARM9NIRQ),	(IEN  | PTD | DIS | M0)) /*D2D_arm9nirq */\
+ MUX_VAL(CP(D2D_UMA2P6FIQ),	(IEN  | PTD | DIS | M0)) /*D2D_uma2p6fiq*/\
+ MUX_VAL(CP(D2D_SPINT),		(IEN  | PTD | EN  | M0)) /*D2D_spint*/\
+ MUX_VAL(CP(D2D_FRINT),		(IEN  | PTD | EN  | M0)) /*D2D_frint*/\
+ MUX_VAL(CP(D2D_DMAREQ0),	(IEN  | PTD | DIS | M0)) /*D2D_dmareq0*/\
+ MUX_VAL(CP(D2D_DMAREQ1),	(IEN  | PTD | DIS | M0)) /*D2D_dmareq1*/\
+ MUX_VAL(CP(D2D_DMAREQ2),	(IEN  | PTD | DIS | M0)) /*D2D_dmareq2*/\
+ MUX_VAL(CP(D2D_DMAREQ3),	(IEN  | PTD | DIS | M0)) /*D2D_dmareq3*/\
+ MUX_VAL(CP(D2D_N3GTRST),	(IEN  | PTD | DIS | M0)) /*D2D_n3gtrst*/\
+ MUX_VAL(CP(D2D_N3GTDI),	(IEN  | PTD | DIS | M0)) /*D2D_n3gtdi*/\
+ MUX_VAL(CP(D2D_N3GTDO),	(IEN  | PTD | DIS | M0)) /*D2D_n3gtdo*/\
+ MUX_VAL(CP(D2D_N3GTMS),	(IEN  | PTD | DIS | M0)) /*D2D_n3gtms*/\
+ MUX_VAL(CP(D2D_N3GTCK),	(IEN  | PTD | DIS | M0)) /*D2D_n3gtck*/\
+ MUX_VAL(CP(D2D_N3GRTCK),	(IEN  | PTD | DIS | M0)) /*D2D_n3grtck*/\
+ MUX_VAL(CP(D2D_MSTDBY),	(IEN  | PTU | EN  | M0)) /*D2D_mstdby*/\
+ MUX_VAL(CP(D2D_SWAKEUP),	(IEN  | PTD | EN  | M0)) /*D2D_swakeup*/\
+ MUX_VAL(CP(D2D_IDLEREQ),	(IEN  | PTD | DIS | M0)) /*D2D_idlereq*/\
+ MUX_VAL(CP(D2D_IDLEACK),	(IEN  | PTU | EN  | M0)) /*D2D_idleack*/\
+ MUX_VAL(CP(D2D_MWRITE),	(IEN  | PTD | DIS | M0)) /*D2D_mwrite*/\
+ MUX_VAL(CP(D2D_SWRITE),	(IEN  | PTD | DIS | M0)) /*D2D_swrite*/\
+ MUX_VAL(CP(D2D_MREAD),		(IEN  | PTD | DIS | M0)) /*D2D_mread*/\
+ MUX_VAL(CP(D2D_SREAD),		(IEN  | PTD | DIS | M0)) /*D2D_sread*/\
+ MUX_VAL(CP(D2D_MBUSFLAG),	(IEN  | PTD | DIS | M0)) /*D2D_mbusflag*/\
+ MUX_VAL(CP(D2D_SBUSFLAG),	(IEN  | PTD | DIS | M0)) /*D2D_sbusflag*/\
+ MUX_VAL(CP(SDRC_CKE0),		(IDIS | PTU | EN  | M0)) /*sdrc_cke0*/\
+ MUX_VAL(CP(SDRC_CKE1),		(IDIS | PTD | DIS | M7)) /*sdrc_cke1*/
+
+#endif
diff --git a/doc/README.devkit8000 b/doc/README.devkit8000
new file mode 100644
index 0000000..671280f
--- /dev/null
+++ b/doc/README.devkit8000
@@ -0,0 +1,8 @@
+The OMAP3 DevKit8000 from Embest/Timll is a clone of the OMAP3 beagle board
+with Ethernet and Touch Screen on board.
+
+For more information go to:
+http://www.embedinfo.com/English/Product/devkit8000.asp
+
+There's no real MAC address available.
+If ethaddr is not set, 5 Bytes of the OMAP Die ID will be used.
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
new file mode 100644
index 0000000..61d7147
--- /dev/null
+++ b/include/configs/devkit8000.h
@@ -0,0 +1,322 @@
+/*
+ * (C) Copyright 2006-2008
+ * Texas Instruments.
+ * Richard Woodruff <r-woodruff2@ti.com>
+ * Syed Mohammed Khasim <x0khasim@ti.com>
+ *
+ * (C) Copyright 2009
+ * Frederik Kriewitz <frederik@kriewitz.eu>
+ *
+ * Configuration settings for the DevKit8000 board.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+#include <asm/sizes.h>
+
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_ARMCORTEXA8	1	/* This is an ARM V7 CPU core */
+#define CONFIG_OMAP		1	/* in a TI OMAP core */
+#define CONFIG_OMAP34XX		1	/* which is a 34XX */
+#define CONFIG_OMAP3430		1	/* which is in a 3430 */
+#define CONFIG_OMAP3_DEVKIT8000	1	/* working with DevKit8000 */
+
+#include <asm/arch/cpu.h>		/* get chip and board defs */
+#include <asm/arch/omap3.h>
+
+/* Display CPU and Board information */
+#define CONFIG_DISPLAY_CPUINFO		1
+#define CONFIG_DISPLAY_BOARDINFO	1
+
+/* Clock Defines */
+#define V_OSCK				26000000	/* Clock output from T2 */
+#define V_SCLK				(V_OSCK >> 1)
+
+#undef CONFIG_USE_IRQ			/* no support for IRQs */
+#define CONFIG_MISC_INIT_R
+
+#define CONFIG_CMDLINE_TAG		1	/* enable passing of ATAGs */
+#define CONFIG_SETUP_MEMORY_TAGS	1
+#define CONFIG_INITRD_TAG		1
+#define CONFIG_REVISION_TAG		1
+
+/* Size of malloc() pool */
+#define CONFIG_ENV_SIZE			SZ_128K	/* Total Size Environment */
+						/* Sector */
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + SZ_128K)
+#define CONFIG_SYS_GBL_DATA_SIZE	128	/* bytes reserved for */
+						/* initial data */
+
+#define CONFIG_SYS_NO_FLASH		/* no NOR flash */
+
+/* Hardware drivers */
+
+/* DM9000 */
+#define CONFIG_NET_MULTI		1
+#define CONFIG_NET_RETRY_COUNT		20
+#define	CONFIG_DRIVER_DM9000		1
+#define	CONFIG_DM9000_BASE		0x2c000000
+#define	DM9000_IO			CONFIG_DM9000_BASE
+#define	DM9000_DATA			(CONFIG_DM9000_BASE + 0x400)
+#define	CONFIG_DM9000_USE_16BIT		1
+#define CONFIG_DM9000_NO_SROM		1
+#undef	CONFIG_DM9000_DEBUG
+
+/* NS16550 Configuration */
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE	(-4)
+#define CONFIG_SYS_NS16550_CLK		48000000 /* 48MHz (APLL96/2) */
+
+/* select serial console configuration */
+#define CONFIG_CONS_INDEX		3
+#define CONFIG_SYS_NS16550_COM3		OMAP34XX_UART3
+#define CONFIG_SERIAL3			3
+#define CONFIG_BAUDRATE			115200
+#define CONFIG_SYS_BAUDRATE_TABLE	{4800, 9600, 19200, 38400, 57600,\
+					115200}
+
+/* MMC */
+#define CONFIG_MMC			1
+#define CONFIG_OMAP3_MMC		1
+#define CONFIG_DOS_PARTITION		1
+
+/* commands to include */
+#include <config_cmd_default.h>
+
+#define CONFIG_CMD_DHCP			/* DHCP support			*/
+#define CONFIG_CMD_EXT2			/* EXT2 Support			*/
+#define CONFIG_CMD_FAT			/* FAT support			*/
+#define CONFIG_CMD_I2C			/* I2C serial bus support	*/
+#define CONFIG_CMD_JFFS2		/* JFFS2 Support		*/
+#define CONFIG_CMD_MMC			/* MMC support			*/
+#define CONFIG_CMD_MTDPARTS		/* Enable MTD parts commands	*/
+#define CONFIG_CMD_NAND			/* NAND support			*/
+#define CONFIG_CMD_NAND_LOCK_UNLOCK	/* nand (un)lock commands	*/
+
+#undef CONFIG_CMD_FPGA			/* FPGA configuration Support	*/
+#undef CONFIG_CMD_IMI			/* iminfo			*/
+
+/* I2C */
+#define CONFIG_SYS_I2C_SPEED		100000
+#define CONFIG_SYS_I2C_SLAVE		1
+#define CONFIG_SYS_I2C_BUS		0
+#define CONFIG_SYS_I2C_BUS_SELECT	1
+#define CONFIG_DRIVER_OMAP34XX_I2C	1
+
+/* TWL4030 */
+#define CONFIG_TWL4030_POWER		1
+#define CONFIG_TWL4030_LED		1
+
+/* Board NAND Info */
+#define CONFIG_MTD_DEVICE		/* needed for mtdparts commands */
+#define MTDIDS_DEFAULT			"nand0=nand"
+#define MTDPARTS_DEFAULT		"mtdparts=nand:" \
+						"512k(x-loader)," \
+						"1920k(u-boot)," \
+						"128k(u-boot-env)," \
+						"4m(kernel)," \
+						"-(fs)"
+
+#define CONFIG_NAND_OMAP_GPMC
+#define CONFIG_SYS_NAND_ADDR		NAND_BASE	/* physical address */
+							/* to access nand */
+#define CONFIG_SYS_NAND_BASE		NAND_BASE	/* physical address */
+							/* to access nand at */
+							/* CS0 */
+#define GPMC_NAND_ECC_LP_x16_LAYOUT	1
+
+#define CONFIG_SYS_MAX_NAND_DEVICE	1		/* Max number of NAND */
+							/* devices */
+#define CONFIG_SYS_64BIT_VSPRINTF			/* needed for nand_util.c */
+
+#define CONFIG_JFFS2_NAND
+/* nand device jffs2 lives on */
+#define CONFIG_JFFS2_DEV		"nand0"
+/* start of jffs2 partition */
+#define CONFIG_JFFS2_PART_OFFSET	0x680000
+#define CONFIG_JFFS2_PART_SIZE		0xf980000	/* size of jffs2 */
+							/* partition */
+
+/* BOOTP/DHCP options */
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_HOSTNAME
+#define CONFIG_BOOTP_NISDOMAIN
+#define CONFIG_BOOTP_BOOTPATH
+#define CONFIG_BOOTP_BOOTFILESIZE
+#define CONFIG_BOOTP_DNS
+#define CONFIG_BOOTP_DNS2
+#define CONFIG_BOOTP_SEND_HOSTNAME
+#define CONFIG_BOOTP_NTPSERVER
+#define CONFIG_BOOTP_TIMEOFFSET
+#undef CONFIG_BOOTP_VENDOREX
+
+/* Environment information */
+#define CONFIG_ENV_OVERWRITE /* allow to overwrite serial and ethaddr */
+
+#define CONFIG_BOOTDELAY		3
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"loadaddr=0x82000000\0" \
+	"console=ttyS2,115200n8\0" \
+	"vram=12M\0" \
+	"dvimode=1024x768MR-16 at 60\0" \
+	"defaultdisplay=dvi\0" \
+	"nfsopts=hard,tcp,rsize=65536,wsize=65536\0" \
+	"kernelopts=rw\0" \
+	"commonargs=" \
+		"setenv bootargs console=${console} " \
+		"vram=${vram} " \
+		"omapfb.mode=dvi:${dvimode} " \
+		"omapdss.def_disp=${defaultdisplay}\0" \
+	"mmcargs=" \
+		"run commonargs; " \
+		"setenv bootargs ${bootargs} " \
+		"root=/dev/mmcblk0p2 " \
+		"${kernelopts}\0" \
+	"nandargs=" \
+		"run commonargs; " \
+		"setenv bootargs ${bootargs} " \
+		"omapfb.mode=dvi:${dvimode} " \
+		"omapdss.def_disp=${defaultdisplay} " \
+		"root=/dev/mtdblock4 " \
+		"rootfstype=jffs2 " \
+		"${kernelopts}\0" \
+	"netargs=" \
+		"run commonargs; " \
+		"setenv bootargs ${bootargs} " \
+		"root=/dev/nfs " \
+		"nfsroot=${serverip}:${rootpath},${nfsopts} " \
+		"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off " \
+		"${kernelopts} " \
+		"dnsip1=${dnsip} " \
+		"dnsip2=${dnsip2}\0" \
+	"loadbootscript=fatload mmc 0 ${loadaddr} boot.scr\0" \
+	"bootscript=echo Running bootscript from mmc ...; " \
+		"source ${loadaddr}\0" \
+	"loaduimage=fatload mmc 0 ${loadaddr} uImage\0" \
+	"eraseenv=nand unlock 0x260000 0x20000; nand erase 0x260000 0x20000\0" \
+	"mmcboot=echo Booting from mmc ...; " \
+		"run mmcargs; " \
+		"bootm ${loadaddr}\0" \
+	"nandboot=echo Booting from nand ...; " \
+		"run nandargs; " \
+		"nand read ${loadaddr} 280000 400000; " \
+		"bootm ${loadaddr}\0" \
+	"netboot=echo Booting from network ...; " \
+		"dhcp ${loadaddr}; " \
+		"run netargs; " \
+		"bootm ${loadaddr}\0" \
+	"autoboot=if mmc init 0; then " \
+			"if run loadbootscript; then " \
+				"run bootscript; " \
+			"else " \
+				"if run loaduimage; then " \
+					"run mmcboot; " \
+				"else run nandboot; " \
+				"fi; " \
+			"fi; " \
+		"else run nandboot; fi\0"
+
+
+#define CONFIG_BOOTCOMMAND "run autoboot"
+
+/* Miscellaneous configurable options */
+#define CONFIG_SYS_LONGHELP		/* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER		/* use "hush" command parser */
+#define CONFIG_AUTO_COMPLETE		1
+#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "
+#define CONFIG_SYS_PROMPT		"OMAP3 DevKit8000 # "
+#define CONFIG_SYS_CBSIZE		512	/* Console I/O Buffer Size */
+/* Print Buffer Size */
+#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
+					sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_MAXARGS		128	/* max number of command args */
+
+/* Boot Argument Buffer Size */
+#define CONFIG_SYS_BARGSIZE		(CONFIG_SYS_CBSIZE)
+
+#define CONFIG_SYS_MEMTEST_START	(OMAP34XX_SDRC_CS0 + 0x07000000)
+#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + \
+					0x01000000) /* 16MB */
+
+#define CONFIG_SYS_LOAD_ADDR		(OMAP34XX_SDRC_CS0 + 0x02000000)
+
+/*
+ * OMAP3 has 12 GP timers, they can be driven by the system clock
+ * (12/13/16.8/19.2/38.4MHz) or by 32KHz clock. We use 13MHz (V_SCLK).
+ * This rate is divided by a local divisor.
+ */
+#define CONFIG_SYS_TIMERBASE		(OMAP34XX_GPT2)
+#define CONFIG_SYS_PTV			2	/* Divisor: 2^(PTV+1) => 8 */
+#define CONFIG_SYS_HZ			1000
+
+/*-----------------------------------------------------------------------
+ * Stack sizes
+ *
+ * The stack sizes are set up in start.S using the settings below
+ */
+#define CONFIG_STACKSIZE	SZ_128K	/* regular stack */
+#ifdef CONFIG_USE_IRQ
+#define CONFIG_STACKSIZE_IRQ	SZ_4K	/* IRQ stack */
+#define CONFIG_STACKSIZE_FIQ	SZ_4K	/* FIQ stack */
+#endif
+
+/*-----------------------------------------------------------------------
+ * Physical Memory Map
+ */
+#define CONFIG_NR_DRAM_BANKS	2	/* CS1 may or may not be populated */
+#define PHYS_SDRAM_1		OMAP34XX_SDRC_CS0
+#define PHYS_SDRAM_1_SIZE	SZ_128M	/* at least 128 meg */
+#define PHYS_SDRAM_2		OMAP34XX_SDRC_CS1
+
+/* SDRAM Bank Allocation method */
+#define SDRC_R_B_C		1
+
+/*-----------------------------------------------------------------------
+ * FLASH and environment organization
+ */
+
+/* **** PISMO SUPPORT *** */
+
+/* Configure the PISMO */
+#define PISMO1_NAND_SIZE		GPMC_SIZE_128M
+
+#define CONFIG_SYS_MONITOR_LEN		SZ_256K	/* Reserve 2 sectors */
+
+#define CONFIG_ENV_IS_IN_NAND		1
+#define SMNAND_ENV_OFFSET		0x260000 /* environment starts here */
+
+#define CONFIG_ENV_OFFSET		boot_flash_off
+
+#ifndef __ASSEMBLY__
+extern struct gpmc *gpmc_cfg;
+extern unsigned int boot_flash_base;
+extern volatile unsigned int boot_flash_env_addr;
+extern unsigned int boot_flash_off;
+extern unsigned int boot_flash_sec;
+extern unsigned int boot_flash_type;
+#endif
+
+#endif /* __CONFIG_H */
-- 
1.6.3.3

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Peter Tyser]

Hi Frederik,
I had some minor aesthetic nitpicks.  I'd change the title to "Add
support for the DevKit8000 board".

<snip>

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 620604c..03b2d10 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -706,6 +706,10 @@ Alex Z
>  	lart		SA1100
>  	dnp1110		SA1110
>  
> +Frederik Kriewitz <frederik@kriewitz.eu>
> +
> +	devkit8000	ARM CORTEX-A8 (OMAP3530 SoC)
> +

You should maintain the alphabetical order of MAINTAINERS when adding
yourself.

>  -------------------------------------------------------------------------
>  
>  Unknown / orphaned boards:
> diff --git a/MAKEALL b/MAKEALL
> index edebaea..34235b7 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8="		\
>  	omap3_pandora		\
>  	omap3_zoom1		\
>  	omap3_zoom2		\
> +	devkit8000	\
>  "

You should maintain the alphabetical order of LIST_ARM_CORTEX_A8.

<snip>

> +/*-----------------------------------------------------------------------
> + * Stack sizes
> + *
> + * The stack sizes are set up in start.S using the settings below
> + */

Other's might disagree, but I think the "----" in the comments above are
not necessary/non-standard.  I'd personally use:

/*
 * Stack sizes
 *
 * The stack sizes are set up in start.S using the settings below
 */

Or just:
/* The stack sizes are set up in start.S using the settings below */

> +#define CONFIG_STACKSIZE	SZ_128K	/* regular stack */
> +#ifdef CONFIG_USE_IRQ
> +#define CONFIG_STACKSIZE_IRQ	SZ_4K	/* IRQ stack */
> +#define CONFIG_STACKSIZE_FIQ	SZ_4K	/* FIQ stack */
> +#endif
> +
> +/*-----------------------------------------------------------------------
> + * Physical Memory Map
> + */
> +#define CONFIG_NR_DRAM_BANKS	2	/* CS1 may or may not be populated */
> +#define PHYS_SDRAM_1		OMAP34XX_SDRC_CS0
> +#define PHYS_SDRAM_1_SIZE	SZ_128M	/* at least 128 meg */
> +#define PHYS_SDRAM_2		OMAP34XX_SDRC_CS1
> +
> +/* SDRAM Bank Allocation method */
> +#define SDRC_R_B_C		1
> +
> +/*-----------------------------------------------------------------------
> + * FLASH and environment organization
> + */
> +
> +/* **** PISMO SUPPORT *** */

You should use a standard comment style for "PISMO SUPPORT", eg less *'s
and standard capitalization.

> +
> +/* Configure the PISMO */

Maybe get rid of the above comment too - its pretty clear that you're
configuring the PISMO based on the "PISMO SUPPORT" comment above and the
define name.

> +#define PISMO1_NAND_SIZE		GPMC_SIZE_128M

Best,
Peter

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Dirk Behme]

Peter Tyser wrote:
> Hi Frederik,
> I had some minor aesthetic nitpicks.  I'd change the title to "Add
> support for the DevKit8000 board".
> 
> <snip>
>>  Unknown / orphaned boards:
>> diff --git a/MAKEALL b/MAKEALL
>> index edebaea..34235b7 100755
>> --- a/MAKEALL
>> +++ b/MAKEALL
>> @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8="		\
>>  	omap3_pandora		\
>>  	omap3_zoom1		\
>>  	omap3_zoom2		\
>> +	devkit8000	\
>>  "
> 
> You should maintain the alphabetical order of LIST_ARM_CORTEX_A8.

What's about using 'omap3_devkit8000' ?

Best regards

Dirk

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Frederik Kriewitz]

On Thu, Aug 20, 2009 at 7:28 PM, Dirk Behme<dirk.behme@googlemail.com> wrote:
> Peter Tyser wrote:
>>
>> Hi Frederik,
>> I had some minor aesthetic nitpicks. ?I'd change the title to "Add
>> support for the DevKit8000 board".
>>

I'll fix them

>>>
>>> ?Unknown / orphaned boards:
>>> diff --git a/MAKEALL b/MAKEALL
>>> index edebaea..34235b7 100755
>>> --- a/MAKEALL
>>> +++ b/MAKEALL
>>> @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" ? ? ? ? ? ? ? ?\
>>> ? ? ? ?omap3_pandora ? ? ? ? ? \
>>> ? ? ? ?omap3_zoom1 ? ? ? ? ? ? \
>>> ? ? ? ?omap3_zoom2 ? ? ? ? ? ? \
>>> + ? ? ? devkit8000 ? ? ?\
>>> ?"
>>
>> You should maintain the alphabetical order of LIST_ARM_CORTEX_A8.
>
> What's about using 'omap3_devkit8000' ?

On Thu, Aug 20, 2009 at 7:02 PM, Peter Tyser<ptyser@xes-inc.com> wrote:
> Hi Frederik,
> I had some minor aesthetic nitpicks.  I'd change the title to "Add
> support for the DevKit8000 board".

Ok, I'll fix them.

Jean-Christophe asked me to move it out of the omap3 "vendor" directory:

On 10:55 Thu 20 Aug     , Frederik Kriewitz wrote:
> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
> PLAGNIOL-VILLARD<plagnioj@jcrosoft.com> wrote:
> >>  board/omap3/devkit8000/Makefile     |   52 +++++
> >>  board/omap3/devkit8000/config.mk    |   35 ++++
> >>  board/omap3/devkit8000/devkit8000.c |  124 ++++++++++++
> >>  board/omap3/devkit8000/devkit8000.h |  373 +++++++++++++++++++++++++++++++++++
> > no need board are allow in board/omap3
> > please create your own vendor dirent or just put it in board/
> What do you mean with that?
board/devkit8000/devkit8000.h
or board/embedinfo/devkit8000/devkit8000.h

I'm confused, where am I supposed to use omap3 and where not?

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:37 Thu 20 Aug     , Frederik Kriewitz wrote:
> On Thu, Aug 20, 2009 at 7:28 PM, Dirk Behme<dirk.behme@googlemail.com> wrote:
> > Peter Tyser wrote:
> >>
> >> Hi Frederik,
> >> I had some minor aesthetic nitpicks. ?I'd change the title to "Add
> >> support for the DevKit8000 board".
> >>
> 
> I'll fix them
> 
> >>>
> >>> ?Unknown / orphaned boards:
> >>> diff --git a/MAKEALL b/MAKEALL
> >>> index edebaea..34235b7 100755
> >>> --- a/MAKEALL
> >>> +++ b/MAKEALL
> >>> @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" ? ? ? ? ? ? ? ?\
> >>> ? ? ? ?omap3_pandora ? ? ? ? ? \
> >>> ? ? ? ?omap3_zoom1 ? ? ? ? ? ? \
> >>> ? ? ? ?omap3_zoom2 ? ? ? ? ? ? \
> >>> + ? ? ? devkit8000 ? ? ?\
> >>> ?"
> >>
> >> You should maintain the alphabetical order of LIST_ARM_CORTEX_A8.
> >
> > What's about using 'omap3_devkit8000' ?
> 
> On Thu, Aug 20, 2009 at 7:02 PM, Peter Tyser<ptyser@xes-inc.com> wrote:
> > Hi Frederik,
> > I had some minor aesthetic nitpicks.  I'd change the title to "Add
> > support for the DevKit8000 board".
> 
> Ok, I'll fix them.
> 
> Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
I agree with Dirk for the config name it will be good to have omap3_devkit8000
but if you prefer devkit8000 it's fine also

and yes I've ask you about the boardir to move it out of the omap3 dirent

Best Regards,
J.

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Dirk Behme]

Frederik Kriewitz wrote:
> Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
> 
> On 10:55 Thu 20 Aug     , Frederik Kriewitz wrote:
>> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
>> PLAGNIOL-VILLARD<plagnioj@jcrosoft.com> wrote:
>>>>  board/omap3/devkit8000/Makefile     |   52 +++++
>>>>  board/omap3/devkit8000/config.mk    |   35 ++++
>>>>  board/omap3/devkit8000/devkit8000.c |  124 ++++++++++++
>>>>  board/omap3/devkit8000/devkit8000.h |  373 +++++++++++++++++++++++++++++++++++
>>> no need board are allow in board/omap3
>>> please create your own vendor dirent or just put it in board/
>> What do you mean with that?
> board/devkit8000/devkit8000.h
> or board/embedinfo/devkit8000/devkit8000.h
> 
> I'm confused, where am I supposed to use omap3 and where not?

Yes, sometimes it can be confusing ;)

 From earlier discussions I understood that Jean-Christophe doesn't like

board/omap3/

I'm not totally sure what he actually wants, but I think something like

board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davinci

etc. (e.g. like board/atmel).

While I don't care what we use, like with other discussions we should 
do it consistent. That is, having already x boards in omap3 and now 
adding the next board somewhere else isn't ok. As long as we don't 
have the new directory layout, new boards should use the old one. If 
we want an other directory layout, we should *first* move all existing 
boards to the other directory (ideally doing this directly in git). 
*Then* new patches can and have to use this new layout.

Conclusion: Until we don't have an other directory layout, I'm fine 
with board/omap3/devkit8000

Best regards

Dirk

[U-Boot] [PATCH v3] Adding support for DevKit8000

[Peter Tyser]

Hi Dirk,

On Fri, 2009-08-21 at 15:00 +0200, Dirk Behme wrote:
> Frederik Kriewitz wrote:
> > Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
> > 
> > On 10:55 Thu 20 Aug     , Frederik Kriewitz wrote:
> >> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
> >> PLAGNIOL-VILLARD<plagnioj@jcrosoft.com> wrote:
> >>>>  board/omap3/devkit8000/Makefile     |   52 +++++
> >>>>  board/omap3/devkit8000/config.mk    |   35 ++++
> >>>>  board/omap3/devkit8000/devkit8000.c |  124 ++++++++++++
> >>>>  board/omap3/devkit8000/devkit8000.h |  373 +++++++++++++++++++++++++++++++++++
> >>> no need board are allow in board/omap3
> >>> please create your own vendor dirent or just put it in board/
> >> What do you mean with that?
> > board/devkit8000/devkit8000.h
> > or board/embedinfo/devkit8000/devkit8000.h
> > 
> > I'm confused, where am I supposed to use omap3 and where not?
> 
> Yes, sometimes it can be confusing ;)
> 
>  From earlier discussions I understood that Jean-Christophe doesn't like
> 
> board/omap3/
> 
> I'm not totally sure what he actually wants, but I think something like
> 
> board/ti/omap3
> board/ti/omap2
> board/ti/omap1
> board/ti/davinci
> 
> etc. (e.g. like board/atmel).

My understanding is that the board/ layout should be "/board/<board
vendor or board name>/...".  So even though the Frederik's board has a
TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since
neither TI nor OMAP3 made the DevKit8000.

I believe all the boards in board/atmel are made by atmel and use atmel
cpus, same with board/freescale.  But if anyone else makes a custom
atmel or freescale-based board, it should not go in board/atmel or
board/freescale.

For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based
boards in board/xes, but they are all made by the X-ES company.

Jean-Christophe is saying you should put your board in either:
board/devkit8000/

or, if your company (embedinfo?) plans on adding more than just the
devkit8000, put it in:
board/embedinfo/devkit8000
board/embedinto/<future_board_x>

> While I don't care what we use, like with other discussions we should 
> do it consistent. That is, having already x boards in omap3 and now 
> adding the next board somewhere else isn't ok. As long as we don't 
> have the new directory layout, new boards should use the old one. If 
> we want an other directory layout, we should *first* move all existing 
> boards to the other directory (ideally doing this directly in git). 
> *Then* new patches can and have to use this new layout.

I agree that other boards currently in board/omap3 should be moved to an
appropriate board/<board vendor or board name> directory in the long
run, ideally sooner rather than later:)  That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or
board/embedinfo/devkit8000 now as that is the "correct" place for it.

> Conclusion: Until we don't have an other directory layout, I'm fine 
> with board/omap3/devkit8000

Doesn't really matter to me, just thought I'd mention my $.02 about how
thing should be organized in the long run.

Best,
Peter

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Dirk Behme]

Peter Tyser wrote:
> Hi Dirk,
> 
> On Fri, 2009-08-21 at 15:00 +0200, Dirk Behme wrote:
>> Frederik Kriewitz wrote:
>>> Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
>>>
>>> On 10:55 Thu 20 Aug     , Frederik Kriewitz wrote:
>>>> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
>>>> PLAGNIOL-VILLARD<plagnioj@jcrosoft.com> wrote:
>>>>>>  board/omap3/devkit8000/Makefile     |   52 +++++
>>>>>>  board/omap3/devkit8000/config.mk    |   35 ++++
>>>>>>  board/omap3/devkit8000/devkit8000.c |  124 ++++++++++++
>>>>>>  board/omap3/devkit8000/devkit8000.h |  373 +++++++++++++++++++++++++++++++++++
>>>>> no need board are allow in board/omap3
>>>>> please create your own vendor dirent or just put it in board/
>>>> What do you mean with that?
>>> board/devkit8000/devkit8000.h
>>> or board/embedinfo/devkit8000/devkit8000.h
>>>
>>> I'm confused, where am I supposed to use omap3 and where not?
>> Yes, sometimes it can be confusing ;)
>>
>>  From earlier discussions I understood that Jean-Christophe doesn't like
>>
>> board/omap3/
>>
>> I'm not totally sure what he actually wants, but I think something like
>>
>> board/ti/omap3
>> board/ti/omap2
>> board/ti/omap1
>> board/ti/davinci
>>
>> etc. (e.g. like board/atmel).
> 
> My understanding is that the board/ layout should be "/board/<board
> vendor or board name>/...".  So even though the Frederik's board has a
> TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since
> neither TI nor OMAP3 made the DevKit8000.
...
> For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based
> boards in board/xes, but they are all made by the X-ES company.
> 
> Jean-Christophe is saying you should put your board in either:
> board/devkit8000/
> 
> or, if your company (embedinfo?) plans on adding more than just the
> devkit8000, put it in:
> board/embedinfo/devkit8000
> board/embedinto/<future_board_x>

I really dislike this. With OMAP3 this would result in something like

board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2

etc.

Same for DaVinci.

After some time, or for somebody not familiar with it, it would be 
really hard to identify that all these are the same platform where 
grouping (and identifying common code) makes sense. It would pollute 
the number of directories in board even more.

> I agree that other boards currently in board/omap3 should be moved to an
> appropriate board/<board vendor or board name> directory in the long
> run, ideally sooner rather than later:)  

I disagree with this.

Having board/<board vendor or board name>

resulting in e.g.

board/embedinfo/devkit8000
board/embedinto/<future_board_x>

would result in a lot of more (unorganized) directories in board/* . I 
can't see any advantage in adding *more* directories into board/*. 
Instead, I see an advantage in having less directories in board/*, 
resulting in more organization/grouping.

Doing something like

board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davinci

would help to make board/* cleaner.

At the moment we have

board/omap3
board/davinci

what I feel is even better (cleaner) than what we would get with 
board/<board vendor or board name>

> That being said, I think it
> would make sense to put the devkit8000 in either board/devkit8000/ or
> board/embedinfo/devkit8000 now as that is the "correct" place for it.

Well, I just can't see what the advantage of this "correct" place 
might be. So from the rule point of view, it might make sense, but 
maybe we should adapt the rule, then?

Looking at the TI stuff, it seems to me that a lot of (small? 
different?) companies are using the same SoCs and doing boards with 
these. Most of the U-Boot code is similar, then. But these companies 
are doing only one or two boards. So it makes more sense to group 
these boards based on the SoC (vendor), instead of the board vendor or 
even worse the board name.

Best regards

Dirk

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Detlev Zundel]

Hi Dirk,

>> That being said, I think it
>> would make sense to put the devkit8000 in either board/devkit8000/ or
>> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>
> Well, I just can't see what the advantage of this "correct" place 
> might be. So from the rule point of view, it might make sense, but 
> maybe we should adapt the rule, then?
>
> Looking at the TI stuff, it seems to me that a lot of (small? 
> different?) companies are using the same SoCs and doing boards with 
> these. Most of the U-Boot code is similar, then. But these companies 
> are doing only one or two boards. So it makes more sense to group 
> these boards based on the SoC (vendor), instead of the board vendor or 
> even worse the board name.

Well actually (I think) we agreed on doing the board/vendor scheme.  For
example look at board/amcc - there are all the AMCC evalboards basically
each one with a different SoC.  Turning this around into board/<soc>
would throw pieces all over the places, which is definitely not what we
want.

Let's look at it from this perspective - on a board level there is
really more adhesion between two different cpu boards from one vendor
than between two same cpu boards from different vendors.  Just take the
AMCC boards - they all have the same feel to them, so this is the
natural way to group the boards.

Even more, sharing of stuff should be done outside of board/ - if it
applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3
and *not at all* below board/.

Finding boards with the same architecture was always very easy by
grepping the include/config/* files.  We do not need a representation of
this fact below board/.

Although I think that these arguments carry some value, I know that
one can come up with - basically arbitrarily many other arguments.  But
still, we had this discussion already and I do not see that anything
fundamental has changed since the last time around, so please let's not
got into bike-shed painting right now ;)

Cheers
  Detlev

-- 
["From 2.4 to 2.6 to 2.7" discussing release numbering of the Linux kernel]
Let the bike-shed-painting begin.
                                     -- Linus Torvalds 
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Peter Tyser]

Hi Dirk,

> > My understanding is that the board/ layout should be "/board/<board
> > vendor or board name>/...".  So even though the Frederik's board has a
> > TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since
> > neither TI nor OMAP3 made the DevKit8000.
> ...
> > For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based
> > boards in board/xes, but they are all made by the X-ES company.
> > 
> > Jean-Christophe is saying you should put your board in either:
> > board/devkit8000/
> > 
> > or, if your company (embedinfo?) plans on adding more than just the
> > devkit8000, put it in:
> > board/embedinfo/devkit8000
> > board/embedinto/<future_board_x>
> 
> I really dislike this. With OMAP3 this would result in something like
> 
> board/DigiKey/beagle (or board/TI/beagle?)
> board/gumstix/overo
> board/mistral/evm (or board/TI/evm? )
> board/xx/pandora
> board/zz/zoom1
> board/yy/zoom2
> 
> etc.
> 
> Same for DaVinci.
> 
> After some time, or for somebody not familiar with it, it would be 
> really hard to identify that all these are the same platform where 
> grouping (and identifying common code) makes sense. It would pollute 
> the number of directories in board even more.

I don't think most end users care much about which boards correlate to
which platform - they care about where the board they are currently
working with is located in the U-Boot tree.  From this perspective, I
think board/<vendor> makes sense.  Eg I'm working on an X-ES board, I'll
look in board/xes, I'm working on a Freescale reference platform, I look
in board/freescale.

> > I agree that other boards currently in board/omap3 should be moved to an
> > appropriate board/<board vendor or board name> directory in the long
> > run, ideally sooner rather than later:)  
> 
> I disagree with this.
> 
> Having board/<board vendor or board name>
> 
> resulting in e.g.
> 
> board/embedinfo/devkit8000
> board/embedinto/<future_board_x>
> 
> would result in a lot of more (unorganized) directories in board/* . I 
> can't see any advantage in adding *more* directories into board/*. 
> Instead, I see an advantage in having less directories in board/*, 
> resulting in more organization/grouping.
> 
> Doing something like
> 
> board/ti/omap3
> board/ti/omap2
> board/ti/omap1
> board/ti/davinci
> 
> would help to make board/* cleaner.

I think its a matter of opinion.  Some companies support many different
cpu architectures.  I like having our X-ES-specific code in 1 location,
board/xes.  X-ES boards can then easily share common code too, eg
board/xes/common/.  Where would vendor-specific code that was used on
multiple boards be located if the board/<vendor> layout is not used?
The alternative is something like:

board/freescale/mpc85xx/xpedite5370/
board/freescale/mpc86xx/xpedite5170/
board/amcc/ppc44x/xpedite1000/
<somewhere else?>/xes-common/

This seems more disorganized than board/xes to me.

> At the moment we have
> 
> board/omap3
> board/davinci
> 
> what I feel is even better (cleaner) than what we would get with 
> board/<board vendor or board name>

I think this breaks down (or at least is less appealing) when a board
vendor supports a number of different cpus and has some code that is
shared between their boards.

> > That being said, I think it
> > would make sense to put the devkit8000 in either board/devkit8000/ or
> > board/embedinfo/devkit8000 now as that is the "correct" place for it.
> 
> Well, I just can't see what the advantage of this "correct" place 
> might be. So from the rule point of view, it might make sense, but 
> maybe we should adapt the rule, then?
> 
> Looking at the TI stuff, it seems to me that a lot of (small? 
> different?) companies are using the same SoCs and doing boards with 
> these. Most of the U-Boot code is similar, then. But these companies 
> are doing only one or two boards. So it makes more sense to group 
> these boards based on the SoC (vendor), instead of the board vendor or 
> even worse the board name.

I can see that angle, but I can see other angles too.  I'd lean towards
the current layout (technically how the PPC boards are currently
organized), but if you had a good solution for us vendors that support a
number of different CPUs and have some common vendor code, it'd be
interesting to discuss.

Best,
Peter

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Dirk Behme]

Hi Detlev,

Detlev Zundel wrote:
> Hi Dirk,
> 
>>> That being said, I think it
>>> would make sense to put the devkit8000 in either board/devkit8000/ or
>>> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>> Well, I just can't see what the advantage of this "correct" place 
>> might be. So from the rule point of view, it might make sense, but 
>> maybe we should adapt the rule, then?
>>
>> Looking at the TI stuff, it seems to me that a lot of (small? 
>> different?) companies are using the same SoCs and doing boards with 
>> these. Most of the U-Boot code is similar, then. But these companies 
>> are doing only one or two boards. So it makes more sense to group 
>> these boards based on the SoC (vendor), instead of the board vendor or 
>> even worse the board name.
> 
> Well actually (I think) we agreed on doing the board/vendor scheme.  For
> example look at board/amcc - there are all the AMCC evalboards basically
> each one with a different SoC.  Turning this around into board/<soc>
> would throw pieces all over the places, which is definitely not what we
> want.

Yes, I agree that it makes no sense to *completely* change the rule.

Maybe we should just be a little bit more flexible about this rule and 
have look, where something else makes more sense.

> Let's look at it from this perspective - on a board level there is
> really more adhesion between two different cpu boards from one vendor
> than between two same cpu boards from different vendors.  Just take the
> AMCC boards - they all have the same feel to them, so this is the
> natural way to group the boards.

I could add the opposite example:

A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with 
a <vendor == TI> DaVinci board.

> Even more, sharing of stuff should be done outside of board/ - if it
> applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3
> and *not at all* below board/.

Sounds like you propose to put omap3 *board* common stuff into *cpu* 
directory?

> Finding boards with the same architecture was always very easy by
> grepping the include/config/* files.  We do not need a representation of
> this fact below board/.

But it wouldn't hurt?

> Although I think that these arguments carry some value, I know that
> one can come up with - basically arbitrarily many other arguments.

Yes ;)

> But
> still, we had this discussion already and I do not see that anything
> fundamental has changed since the last time around, so please let's not
> got into bike-shed painting right now ;)

Could we agree to be more flexible with this rule?

Or, the other way around:

Independent of the rule, do you see any advantage of switching existing

board/omap3/
board/davinci/

into something like

board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2

etc.?

Except to follow the rule?

Thanks

Dirk

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Detlev Zundel]

Hi Dirk,

>> Well actually (I think) we agreed on doing the board/vendor scheme.  For
>> example look at board/amcc - there are all the AMCC evalboards basically
>> each one with a different SoC.  Turning this around into board/<soc>
>> would throw pieces all over the places, which is definitely not what we
>> want.
>
> Yes, I agree that it makes no sense to *completely* change the rule.
>
> Maybe we should just be a little bit more flexible about this rule and
> have look, where something else makes more sense.

I doubt that we can be more flexible with this rule without effectively
introducing another rule.  After all, that's what you say: "generally we
follow rule a, only if it doesn't make sense (which one cannot tell
beforehand) and then we follow rule b".

Such a "metarule" is not a big help - precisely because one cannot tell
beforehand which "sub-rule" is applicable.

>> Let's look at it from this perspective - on a board level there is
>> really more adhesion between two different cpu boards from one vendor
>> than between two same cpu boards from different vendors.  Just take the
>> AMCC boards - they all have the same feel to them, so this is the
>> natural way to group the boards.
>
> I could add the opposite example:
>
> A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with
> a <vendor == TI> DaVinci board.

To which I reply - then TI should better shape up their U-Boot support
and get the boards in line ;)

>> Even more, sharing of stuff should be done outside of board/ - if it
>> applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3
>> and *not at all* below board/.
>
> Sounds like you propose to put omap3 *board* common stuff into *cpu*
> directory?

No way.  I only say that stuff which boards have in common *additional*
to what they share from their architecture *should* be very little.
Ideally a board/ directory is *very* light.  The heavyweight stuff
should be below cpu, drivers, etc.

>> Finding boards with the same architecture was always very easy by
>> grepping the include/config/* files.  We do not need a representation of
>> this fact below board/.
>
> But it wouldn't hurt?

It hurts if it stops us from having a single rule.

>> But still, we had this discussion already and I do not see that
>> anything fundamental has changed since the last time around, so
>> please let's not got into bike-shed painting right now ;)
>
> Could we agree to be more flexible with this rule?
>
> Or, the other way around:
>
> Independent of the rule, do you see any advantage of switching existing
>
> board/omap3/
> board/davinci/
>
> into something like
>
> board/DigiKey/beagle (or board/TI/beagle?)
> board/gumstix/overo
> board/mistral/evm (or board/TI/evm? )
> board/xx/pandora
> board/zz/zoom1
> board/yy/zoom2
>
> etc.?
>
> Except to follow the rule?

A rule is only good if it really helps to organize stuff.  So yes, I see
an advantage of the latter examples, namely that someone looking into
board/ has a single rule which will allow him to find what he is looking
for.

Cheers
  Detlev

-- 
I talk to planets baby
                                       -- Dave Wyndorf (Monstermagnet)
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Wolfgang Denk]

Dear Detlev Zundel,

In message <m24os18a3w.fsf@ohwell.denx.de> you wrote:
> 
> >> That being said, I think it
> >> would make sense to put the devkit8000 in either board/devkit8000/ or
> >> board/embedinfo/devkit8000 now as that is the "correct" place for it.
> >
> > Well, I just can't see what the advantage of this "correct" place 
> > might be. So from the rule point of view, it might make sense, but 
> > maybe we should adapt the rule, then?
> >
> > Looking at the TI stuff, it seems to me that a lot of (small? 
> > different?) companies are using the same SoCs and doing boards with 
> > these. Most of the U-Boot code is similar, then. But these companies 
> > are doing only one or two boards. So it makes more sense to group 
> > these boards based on the SoC (vendor), instead of the board vendor or 
> > even worse the board name.
> 
> Well actually (I think) we agreed on doing the board/vendor scheme.  For
> example look at board/amcc - there are all the AMCC evalboards basically
> each one with a different SoC.  Turning this around into board/<soc>
> would throw pieces all over the places, which is definitely not what we
> want.

Correct. That's the cuirrent "official" definiiton, and so far I see
no reason to change it.

> Although I think that these arguments carry some value, I know that
> one can come up with - basically arbitrarily many other arguments.  But
> still, we had this discussion already and I do not see that anything
> fundamental has changed since the last time around, so please let's not
> got into bike-shed painting right now ;)

Full ACK.

We have a pretty clear definition, and I see no reason to change this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Pig: An animal (Porcus omnivorous) closely allied to the  human  race
by  the splendor and vivacity of its appetite, which, however, is in-
ferior in scope, for it balks at pig.                - Ambrose Bierce

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Wolfgang Denk]

Dear Dirk Behme,

In message <4A8EC01F.7040307@googlemail.com> you wrote:
> 
> I could add the opposite example:
> 
> A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with 
> a <vendor == TI> DaVinci board.

I tend to interpret this as poor board support by that vendor, then.

A vendor  who  has  several  boards  to  suuport,  does  himself  and
especially  all his users a big fevour if he implements a common look
and feel - compare what boards  manufactured  for  example  by  AMCC,
Freescale  (at least more recent ports) or TQ are doing (alphabetical
oder, in case you did not notice) - they try  to  provide  a  similar
setup  of  their environment variables, etc. - no matter which actual
processor or SoC a board may be based on.

It is intentional that the current directury struxcture supports this.

> Sounds like you propose to put omap3 *board* common stuff into *cpu* 
> directory?

If _all_ OMAP3 boards share this stuff, then t i indeed not board
common, but CPU coomon, and should go into the CPU directory. Well
spotted.

> > Finding boards with the same architecture was always very easy by
> > grepping the include/config/* files.  We do not need a representation of
> > this fact below board/.
> 
> But it wouldn't hurt?

Yes, it would, It would disrupt order.

> Could we agree to be more flexible with this rule?

No. :-)

> Independent of the rule, do you see any advantage of switching existing
> 
> board/omap3/
> board/davinci/
> 
> into something like
> 
> board/DigiKey/beagle (or board/TI/beagle?)
> board/gumstix/overo
> board/mistral/evm (or board/TI/evm? )
> board/xx/pandora
> board/zz/zoom1
> board/yy/zoom2

That should indeed be board/TI/beagle, board/TI/evm, if TI is the
board vendor.

> Except to follow the rule?

Yes, please follow the rules :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I can type faster than I can move a  mouse,  so  I  find  menu-driven
drawing packages time consuming and frustrating.      - W. R. Stevens

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Frederik Kriewitz]

On Fri, Aug 21, 2009 at 7:59 PM, Wolfgang Denk<wd@denx.de> wrote:

> In message <m24os18a3w.fsf@ohwell.denx.de> you wrote:
>>
>> >> That being said, I think it
>> >> would make sense to put the devkit8000 in either board/devkit8000/ or
>> >> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>> >
>> > Well, I just can't see what the advantage of this "correct" place
>> > might be. So from the rule point of view, it might make sense, but
>> > maybe we should adapt the rule, then?
>> >
>> > Looking at the TI stuff, it seems to me that a lot of (small?
>> > different?) companies are using the same SoCs and doing boards with
>> > these. Most of the U-Boot code is similar, then. But these companies
>> > are doing only one or two boards. So it makes more sense to group
>> > these boards based on the SoC (vendor), instead of the board vendor or
>> > even worse the board name.
>>
>> Well actually (I think) we agreed on doing the board/vendor scheme. ?For
>> example look at board/amcc - there are all the AMCC evalboards basically
>> each one with a different SoC. ?Turning this around into board/<soc>
>> would throw pieces all over the places, which is definitely not what we
>> want.
>
> Correct. That's the cuirrent "official" definiiton, and so far I see
> no reason to change it.

Ok, is there a official naming convention for the include/configs/*.h
files and the *_config targets? Should they be grouped by CPU/SoC
and/or vendor (Makefile/MAKEALL)?

[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Wolfgang Denk]

Dear Frederik Kriewitz,

In message <f67028d40908211627v31668e61k859d431f3ecc577@mail.gmail.com> you wrote:
> 
> Ok, is there a official naming convention for the include/configs/*.h
> files and the *_config targets? Should they be grouped by CPU/SoC
> and/or vendor (Makefile/MAKEALL)?

There is no such convention except that *_config targets are expected
to use lower case characters only. We try to match the  real  product
names  as  close  as possible so everybody is able to recognize "his"
board. The only grouping done in Makefilke  and  Makeall  is  by  CPU
architecture  (i.  e. ARM9, ARM11, ARM_CORTEX_A8, ... 4xx, 83xx, ...)
etc. Within each group, lists  are  sorted  alphabetically  (ignoring
case).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"One planet is all you get."