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

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@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@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 */

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

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

On Thu, Aug 20, 2009 at 7:28 PM, Dirk Behmedirk.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 Tyserptyser@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-VILLARDplagnioj@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?

On 20:37 Thu 20 Aug , Frederik Kriewitz wrote:
On Thu, Aug 20, 2009 at 7:28 PM, Dirk Behmedirk.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 Tyserptyser@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.

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-VILLARDplagnioj@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

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-VILLARDplagnioj@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

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-VILLARDplagnioj@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

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

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

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

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

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

On Fri, Aug 21, 2009 at 7:59 PM, Wolfgang Denkwd@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)?

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

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
participants (6)
-
Detlev Zundel
-
Dirk Behme
-
Frederik Kriewitz
-
Jean-Christophe PLAGNIOL-VILLARD
-
Peter Tyser
-
Wolfgang Denk