[U-Boot] [PATCH] mx6qsabresd: Add basic support
Add basic support for mx6qsabresd board.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- MAINTAINERS | 1 + board/freescale/mx6qsabresd/Makefile | 37 ++++++ board/freescale/mx6qsabresd/imximage.cfg | 170 +++++++++++++++++++++++++++ board/freescale/mx6qsabresd/mx6qsabresd.c | 111 ++++++++++++++++++ boards.cfg | 1 + include/configs/mx6qsabresd.h | 178 +++++++++++++++++++++++++++++ 6 files changed, 498 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx6qsabresd/Makefile create mode 100644 board/freescale/mx6qsabresd/imximage.cfg create mode 100644 board/freescale/mx6qsabresd/mx6qsabresd.c create mode 100644 include/configs/mx6qsabresd.h
diff --git a/MAINTAINERS b/MAINTAINERS index 72f8b64..408167c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -648,6 +648,7 @@ Fabio Estevam fabio.estevam@freescale.com mx31pdk i.MX31 mx53ard i.MX53 mx53smd i.MX53 + mx6qsabresd i.MX6Q
Daniel Gorsulowski daniel.gorsulowski@esd.eu
diff --git a/board/freescale/mx6qsabresd/Makefile b/board/freescale/mx6qsabresd/Makefile new file mode 100644 index 0000000..477bc3a --- /dev/null +++ b/board/freescale/mx6qsabresd/Makefile @@ -0,0 +1,37 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski lg@denx.de +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# 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. +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS := mx6qsabresd.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +######################################################################### + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +######################################################################### diff --git a/board/freescale/mx6qsabresd/imximage.cfg b/board/freescale/mx6qsabresd/imximage.cfg new file mode 100644 index 0000000..c389427 --- /dev/null +++ b/board/freescale/mx6qsabresd/imximage.cfg @@ -0,0 +1,170 @@ +# Copyright (C) 2011 Freescale Semiconductor, Inc. +# Jason Liu r64343@freescale.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. 51 Franklin Street Fifth Floor Boston, +# MA 02110-1301 USA +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage + +# image version + +IMAGE_VERSION 2 + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd + +# Device Configuration Data (DCD) +# +# Each entry must have the format: +# Addr-type Address Value +# +# where: +# Addr-type register length (1,2 or 4 bytes) +# Address absolute address of the register +# value value to be stored in the register +DATA 4 0x020e05a8 0x00000030 +DATA 4 0x020e05b0 0x00000030 +DATA 4 0x020e0524 0x00000030 +DATA 4 0x020e051c 0x00000030 + +DATA 4 0x020e0518 0x00000030 +DATA 4 0x020e050c 0x00000030 +DATA 4 0x020e05b8 0x00000030 +DATA 4 0x020e05c0 0x00000030 + +DATA 4 0x020e05ac 0x00020030 +DATA 4 0x020e05b4 0x00020030 +DATA 4 0x020e0528 0x00020030 +DATA 4 0x020e0520 0x00020030 + +DATA 4 0x020e0514 0x00020030 +DATA 4 0x020e0510 0x00020030 +DATA 4 0x020e05bc 0x00020030 +DATA 4 0x020e05c4 0x00020030 + +DATA 4 0x020e056c 0x00020030 +DATA 4 0x020e0578 0x00020030 +DATA 4 0x020e0588 0x00020030 +DATA 4 0x020e0594 0x00020030 + +DATA 4 0x020e057c 0x00020030 +DATA 4 0x020e0590 0x00003000 +DATA 4 0x020e0598 0x00003000 +DATA 4 0x020e058c 0x00000000 + +DATA 4 0x020e059c 0x00003030 +DATA 4 0x020e05a0 0x00003030 +DATA 4 0x020e0784 0x00000030 +DATA 4 0x020e0788 0x00000030 + +DATA 4 0x020e0794 0x00000030 +DATA 4 0x020e079c 0x00000030 +DATA 4 0x020e07a0 0x00000030 +DATA 4 0x020e07a4 0x00000030 + +DATA 4 0x020e07a8 0x00000030 +DATA 4 0x020e0748 0x00000030 +DATA 4 0x020e074c 0x00000030 +DATA 4 0x020e0750 0x00020000 + +DATA 4 0x020e0758 0x00000000 +DATA 4 0x020e0774 0x00020000 +DATA 4 0x020e078c 0x00000030 +DATA 4 0x020e0798 0x000C0000 + +DATA 4 0x021b081c 0x33333333 +DATA 4 0x021b0820 0x33333333 +DATA 4 0x021b0824 0x33333333 +DATA 4 0x021b0828 0x33333333 + +DATA 4 0x021b481c 0x33333333 +DATA 4 0x021b4820 0x33333333 +DATA 4 0x021b4824 0x33333333 +DATA 4 0x021b4828 0x33333333 + +DATA 4 0x021b0018 0x00081740 + +DATA 4 0x021b001c 0x00008000 +DATA 4 0x021b000c 0x555A7975 +DATA 4 0x021b0010 0xFF538E64 +DATA 4 0x021b0014 0x01FF00DB +DATA 4 0x021b002c 0x000026D2 + +DATA 4 0x021b0030 0x005B0E21 +DATA 4 0x021b0008 0x09444040 +DATA 4 0x021b0004 0x00025576 +DATA 4 0x021b0040 0x00000027 +DATA 4 0x021b0000 0x831A0000 + +DATA 4 0x021b001c 0x04088032 +DATA 4 0x021b001c 0x0408803A +DATA 4 0x021b001c 0x00008033 +DATA 4 0x021b001c 0x0000803B +DATA 4 0x021b001c 0x00428031 +DATA 4 0x021b001c 0x00428039 +DATA 4 0x021b001c 0x09408030 +DATA 4 0x021b001c 0x09408038 + +DATA 4 0x021b001c 0x04008040 +DATA 4 0x021b001c 0x04008048 +DATA 4 0x021b0800 0xA1380003 +DATA 4 0x021b4800 0xA1380003 +DATA 4 0x021b0020 0x00005800 +DATA 4 0x021b0818 0x00022227 +DATA 4 0x021b4818 0x00022227 + +DATA 4 0x021b083c 0x434B0350 +DATA 4 0x021b0840 0x034C0359 +DATA 4 0x021b483c 0x434B0350 +DATA 4 0x021b4840 0x03650348 +DATA 4 0x021b0848 0x4436383B +DATA 4 0x021b4848 0x39393341 +DATA 4 0x021b0850 0x35373933 +DATA 4 0x021b4850 0x48254A36 + +DATA 4 0x021b080c 0x001F001F +DATA 4 0x021b0810 0x001F001F + +DATA 4 0x021b480c 0x00440044 +DATA 4 0x021b4810 0x00440044 + +DATA 4 0x021b08b8 0x00000800 +DATA 4 0x021b48b8 0x00000800 + +DATA 4 0x021b001c 0x00000000 +DATA 4 0x021b0404 0x00011006 + +# set the default clock gate to save power +DATA 4 0x020c4068 0x00C03F3F +DATA 4 0x020c406c 0x0030FC03 +DATA 4 0x020c4070 0x0FFFC000 +DATA 4 0x020c4074 0x3FF00000 +DATA 4 0x020c4078 0x00FFF300 +DATA 4 0x020c407c 0x0F0000C3 +DATA 4 0x020c4080 0x000003FF + +# enable AXI cache for VDOA/VPU/IPU +DATA 4 0x020e0010 0xF00000FF +# set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 +DATA 4 0x020e0018 0x007F007F +DATA 4 0x020e001c 0x007F007F diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c b/board/freescale/mx6qsabresd/mx6qsabresd.c new file mode 100644 index 0000000..7df2823 --- /dev/null +++ b/board/freescale/mx6qsabresd/mx6qsabresd.c @@ -0,0 +1,111 @@ +/* + * Copyright (C) 2012 Freescale Semiconductor, Inc. + * + * Author: Fabio Estevam fabio.estevam@freescale.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. + */ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/imx-regs.h> +#include <asm/arch/mx6x_pins.h> +#include <asm/arch/iomux-v3.h> +#include <asm/errno.h> +#include <asm/gpio.h> +#include <mmc.h> +#include <fsl_esdhc.h> + +DECLARE_GLOBAL_DATA_PTR; + +#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ + PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ + PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \ + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +int dram_init(void) +{ + gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); + + return 0; +} + +iomux_v3_cfg_t uart1_pads[] = { + MX6Q_PAD_CSI0_DAT10__UART1_TXD | MUX_PAD_CTRL(UART_PAD_CTRL), + MX6Q_PAD_CSI0_DAT11__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL), +}; + +iomux_v3_cfg_t usdhc3_pads[] = { + MX6Q_PAD_SD3_CLK__USDHC3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6Q_PAD_SD3_CMD__USDHC3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6Q_PAD_NANDF_D0__GPIO_2_0 | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ +}; + +static void setup_iomux_uart(void) +{ + imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads)); +} + +#ifdef CONFIG_FSL_ESDHC +struct fsl_esdhc_cfg usdhc_cfg[1] = { + {USDHC3_BASE_ADDR, 1}, +}; + +int board_mmc_getcd(struct mmc *mmc) +{ + gpio_direction_input(32); /*GPIO2_0*/ + return !gpio_get_value(32); +} + +int board_mmc_init(bd_t *bis) +{ + imx_iomux_v3_setup_multiple_pads(usdhc3_pads, ARRAY_SIZE(usdhc3_pads)); + + return fsl_esdhc_initialize(bis, &usdhc_cfg[0]); +} +#endif + +u32 get_board_rev(void) +{ + return 0x63000 ; +} + +int board_early_init_f(void) +{ + setup_iomux_uart(); + + return 0; +} + +int board_init(void) +{ + /* address of boot parameters */ + gd->bd->bi_boot_params = PHYS_SDRAM + 0x100; + + return 0; +} + +int checkboard(void) +{ + puts("Board: MX6Q-SabreSD\n"); + + return 0; +} diff --git a/boards.cfg b/boards.cfg index c6090ba..d9946ca 100644 --- a/boards.cfg +++ b/boards.cfg @@ -192,6 +192,7 @@ mx53smd arm armv7 mx53smd freesca vision2 arm armv7 vision2 ttcontrol mx5 vision2:IMX_CONFIG=board/ttcontrol/vision2/imximage_hynix.cfg mx6qarm2 arm armv7 mx6qarm2 freescale mx6 mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg mx6qsabrelite arm armv7 mx6qsabrelite freescale mx6 mx6qsabrelite:IMX_CONFIG=board/freescale/mx6qsabrelite/imximage.cfg +mx6qsabresd arm armv7 mx6qsabresd freescale mx6 mx6qsabresd:IMX_CONFIG=board/freescale/mx6qsabresd/imximage.cfg cm_t35 arm armv7 cm_t35 - omap3 omap3_overo arm armv7 overo - omap3 omap3_pandora arm armv7 pandora - omap3 diff --git a/include/configs/mx6qsabresd.h b/include/configs/mx6qsabresd.h new file mode 100644 index 0000000..984057c --- /dev/null +++ b/include/configs/mx6qsabresd.h @@ -0,0 +1,178 @@ +/* + * Copyright (C) 2012 Freescale Semiconductor, Inc. + * + * Configuration settings for the Freescale i.MX6Q SabreSD board. + * + * 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. + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +#define CONFIG_MX6Q +#define CONFIG_SYS_MX6_HCLK 24000000 +#define CONFIG_SYS_MX6_CLK32 32768 +#define CONFIG_DISPLAY_CPUINFO +#define CONFIG_DISPLAY_BOARDINFO + +#define CONFIG_MACH_TYPE 3980 + +#include <asm/arch/imx-regs.h> + +#define CONFIG_CMDLINE_TAG +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_INITRD_TAG +#define CONFIG_REVISION_TAG + +/* Size of malloc() pool */ +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024) + +#define CONFIG_ARCH_CPU_INIT +#define CONFIG_BOARD_EARLY_INIT_F +#define CONFIG_MXC_GPIO + +#define CONFIG_MXC_UART +#define CONFIG_MXC_UART_BASE UART1_BASE + +/* MMC Configs */ +#define CONFIG_FSL_ESDHC +#define CONFIG_FSL_USDHC +#define CONFIG_SYS_FSL_ESDHC_ADDR 0 +#define CONFIG_SYS_FSL_USDHC_NUM 2 + +#define CONFIG_MMC +#define CONFIG_CMD_MMC +#define CONFIG_GENERIC_MMC +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_FAT +#define CONFIG_DOS_PARTITION + +/* allow to overwrite serial and ethaddr */ +#define CONFIG_ENV_OVERWRITE +#define CONFIG_CONS_INDEX 1 +#define CONFIG_BAUDRATE 115200 +#define CONFIG_SYS_BAUDRATE_TABLE {9600, 19200, 38400, 57600, 115200} + +/* Command definition */ +#include <config_cmd_default.h> + +#undef CONFIG_CMD_IMLS + +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_LOADADDR 0x10800000 +#define CONFIG_SYS_TEXT_BASE 0x17800000 + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "script=boot.scr\0" \ + "uimage=uImage\0" \ + "console=ttymxc0\0" \ + "fdt_high=0xffffffff\0" \ + "initrd_high=0xffffffff\0" \ + "mmcdev=0\0" \ + "mmcpart=2\0" \ + "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \ + "mmcargs=setenv bootargs console=${console},${baudrate} " \ + "root=${mmcroot}\0" \ + "loadbootscript=" \ + "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ + "bootscript=echo Running bootscript from mmc ...; " \ + "source\0" \ + "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \ + "mmcboot=echo Booting from mmc ...; " \ + "run mmcargs; " \ + "bootm\0" \ + "netargs=setenv bootargs console=${console},${baudrate} " \ + "root=/dev/nfs " \ + "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \ + "netboot=echo Booting from net ...; " \ + "run netargs; " \ + "dhcp ${uimage}; bootm\0" \ + +#define CONFIG_BOOTCOMMAND \ + "mmc dev ${mmcdev};" \ + "if mmc rescan ${mmcdev}; then " \ + "if run loadbootscript; then " \ + "run bootscript; " \ + "else " \ + "if run loaduimage; then " \ + "run mmcboot; " \ + "else run netboot; " \ + "fi; " \ + "fi; " \ + "else run netboot; fi" + +#define CONFIG_ARP_TIMEOUT 200UL + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP +#define CONFIG_SYS_HUSH_PARSER +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " +#define CONFIG_SYS_PROMPT "MX6QSABRESD U-Boot > " +#define CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_CBSIZE 256 + +/* Print Buffer Size */ +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +#define CONFIG_SYS_MEMTEST_START 0x10000000 +#define CONFIG_SYS_MEMTEST_END 0x10010000 + +#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR +#define CONFIG_SYS_HZ 1000 + +#define CONFIG_CMDLINE_EDITING +#define CONFIG_STACKSIZE (128 * 1024) + +/* Physical Memory Map */ +#define CONFIG_NR_DRAM_BANKS 1 +#define PHYS_SDRAM MMDC0_ARB_BASE_ADDR +#define PHYS_SDRAM_SIZE (1u * 1024 * 1024 * 1024) + +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM +#define CONFIG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR +#define CONFIG_SYS_INIT_RAM_SIZE IRAM_SIZE + +#define CONFIG_SYS_INIT_SP_OFFSET \ + (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR \ + (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) + +/* FLASH and environment organization */ +#define CONFIG_SYS_NO_FLASH + +#define CONFIG_ENV_SIZE (8 * 1024) + +#define CONFIG_ENV_IS_IN_MMC + +#if defined(CONFIG_ENV_IS_IN_MMC) +#define CONFIG_ENV_OFFSET (6 * 64 * 1024) +#define CONFIG_SYS_MMC_ENV_DEV 0 +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_ENV_SECT_SIZE (8 * 1024) +#define CONFIG_ENV_SPI_BUS CONFIG_SF_DEFAULT_BUS +#define CONFIG_ENV_SPI_CS CONFIG_SF_DEFAULT_CS +#define CONFIG_ENV_SPI_MODE CONFIG_SF_DEFAULT_MODE +#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED +#endif + +#define CONFIG_OF_LIBFDT + +#define CONFIG_SYS_DCACHE_OFF + +#ifndef CONFIG_SYS_DCACHE_OFF +#define CONFIG_CMD_CACHE +#endif + +#endif /* __CONFIG_H */
Dear Fabio Estevam,
In message 1334158122-15219-1-git-send-email-festevam@gmail.com you wrote:
Add basic support for mx6qsabresd board.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Could you please add a bit information which sort of board this is, where to find documetnation about it, etc.?
+#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " +#define CONFIG_SYS_PROMPT "MX6QSABRESD U-Boot > "
Do we really need such verbose prompts? This appears to be overkill, and is becoming more and more a nuisance. [I wonder when I will see the first board which puts the full version string in the prompt :-( ]
+#define CONFIG_SYS_MEMTEST_START 0x10000000 +#define CONFIG_SYS_MEMTEST_END 0x10010000
Does this make sense?
Best regards,
Wolfgang Denk
On Wed, Apr 11, 2012 at 4:49 PM, Wolfgang Denk wd@denx.de wrote:
Could you please add a bit information which sort of board this is, where to find documetnation about it, etc.?
Ok, will add more information about this board.
I will not be able to point to any documentation about it as it is not yet publicly available.
+#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " +#define CONFIG_SYS_PROMPT "MX6QSABRESD U-Boot > "
Do we really need such verbose prompts? This appears to be overkill, and is becoming more and more a nuisance. [I wonder when I will see the first board which puts the full version string in the prompt :-( ]
Ok, I will make the prompt shorter
+#define CONFIG_SYS_MEMTEST_START 0x10000000 +#define CONFIG_SYS_MEMTEST_END 0x10010000
0x10000000 is the start address for DDR on mx6.
mx6qarm2 and mx6qsabrelite do the same approach.
Doesn't this seem OK?
Regards,
Fabio Estevam
Dear Fabio Estevam,
In message CAOMZO5B82CU=f_yNG9fmfbJ39i_oZuDfEEFf=PuCZLGwr7sfng@mail.gmail.com you wrote:
+#define CONFIG_SYS_MEMTEST_START 0x10000000 +#define CONFIG_SYS_MEMTEST_END 0x10010000
0x10000000 is the start address for DDR on mx6.
mx6qarm2 and mx6qsabrelite do the same approach.
Then these should eventually be fixed, too.
Doesn't this seem OK?
Does testing just the first 64 KiB of RAM make any sense? Not to me.
BTW: where are the exception vectors located?
Best regards,
Wolfgang Denk
On Wed, Apr 11, 2012 at 6:36 PM, Wolfgang Denk wd@denx.de wrote:
Does testing just the first 64 KiB of RAM make any sense? Not to me.
Ok, I will expand the mtest range.
BTW: where are the exception vectors located?
I don't know actually, but would like to learn about it. Looked at the generated u-boot.map and could not find it out.
Stefano,
Can you please help me to find a safer DDR location for performing mtest on mx6? I think we probably have the same issues on other i.MX processors as well. Do you know how can I locate the address range that the exception vectors occupy?
Thanks,
Fabio Estevam
On 13.04.2012 17:56, Fabio Estevam wrote:
On Wed, Apr 11, 2012 at 6:36 PM, Wolfgang Denkwd@denx.de wrote:
Does testing just the first 64 KiB of RAM make any sense? Not to me.
Ok, I will expand the mtest range.
BTW: where are the exception vectors located?
I don't know actually, but would like to learn about it. Looked at the generated u-boot.map and could not find it out.
Stefano,
Can you please help me to find a safer DDR location for performing mtest on mx6? I think we probably have the same issues on other i.MX processors as well. Do you know how can I locate the address range that the exception vectors occupy?
Regarding the exception vectors:
I would think that the code of the U-Boot exception vectors are located at
#define CONFIG_SYS_TEXT_BASE 0x17800000
and
#define CONFIG_LOADADDR 0x10800000
after relocation using
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/arm/cpu/arm...
and
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/arm/cpu/u-b...
So as long as we don't have the MMU enabled, these vectors aren't used at all. I would expect that the BootRom exception vectors at address 0x00000000 are used, instead.
I might be wrong, so people please correct me ;)
Best regards
Dirk
On Fri, Apr 13, 2012 at 1:14 PM, Dirk Behme dirk.behme@googlemail.com wrote:
Regarding the exception vectors:
I would think that the code of the U-Boot exception vectors are located at
#define CONFIG_SYS_TEXT_BASE 0x17800000
and
#define CONFIG_LOADADDR 0x10800000
Thanks, Dirk.
I am looking at the u-boot.map:
arch/arm/cpu/armv7/start.o(.text) .text 0x17800000 0x4a0 arch/arm/cpu/armv7/start.o 0x17800000 _start 0x17800040 _end_vect 0x17800040 _TEXT_BASE 0x17800044 _bss_start_ofs 0x17800048 _image_copy_end_ofs 0x1780004c _bss_end_ofs 0x17800050 _end_ofs 0x17800054 IRQ_STACK_START_IN 0x17800098 relocate_code 0x178001a8 cpu_init_cp15 *(.text)
So, would it be OK to use 0x10000000 - 0x177fffff as the memory range for mtest?
Thanks,
Fabio Estevam
On Fri, Apr 13, 2012 at 7:36 PM, Fabio Estevam festevam@gmail.com wrote:
So, would it be OK to use 0x10000000 - 0x177fffff as the memory range for mtest?
Looks like I forgot the relocation. So the range for mtest would be from 0x10000000 until 0x10800000 - 1, right?
Thanks,
Fabio Estevam
On 14.04.2012 01:04, Fabio Estevam wrote:
On Fri, Apr 13, 2012 at 7:36 PM, Fabio Estevam festevam@gmail.com wrote:
So, would it be OK to use 0x10000000 - 0x177fffff as the memory range for mtest?
Looks like I forgot the relocation. So the range for mtest would be from 0x10000000 until 0x10800000 - 1, right?
Yes.
Or somewhere between
0x10800000 + some space for the relocated U-Boot
and
0x177fffff
Best regards
Dirk
Am 14/04/2012 01:04, schrieb Fabio Estevam:
On Fri, Apr 13, 2012 at 7:36 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Fabio,
So, would it be OK to use 0x10000000 - 0x177fffff as the memory range for mtest?
Some considerations about this issue. hopefully I am not OT. The values put in the configuration file are the default parameters taken by the mtest command if no parameters are issued. I agree they must not be set to wrong values (I mean, outside the adressable RAM), but in any case mtest is not run automatically and the range can be adjusted in the console. I can always send a "mtest 0x0x10000000 - 0x177fffff" even if a restricted range is set in the config file, for example as it is set now for the mx6qsabrelite (64k).
The start address CONFIG_SYS_MEMTEST_START is the lowest address of the SDRAM that can be accessed, that is MMDC0_ARB_BASE_ADDR (0x10000000) for i.MX6.
Now we can take a look at the end address. IMHO it is better to inform always mtest about which is the end address to be tested, and not rely to a default value. And, because the total memory is computed dynamically, also the last RAM address that can be tested should be computed at run time and not at compile time with CONFIG_SYS_MEMTEST_END.
So I will be for a patch that changes the behavior of mtest and computes automatically the last testable address if the second parameter is not given, dropping CONFIG_SYS_MEMTEST_END - I know, this is not part of your patch, I have already said I can be OT ;-)
Regarding the i.MX6, I think it is not important to bind the last address to 0x10800000 (CONFIG_LOADADDR). This is only the default address used to load data. U-Boot is not multitasking, so we are sure that when mtest runs nothing is loaded, and we can test also this memory range. Maybe it is more important to test the range from 0x10800000, because it is used mostly to transfer data and we would like to know if there is some problem in this range.
The only thing we have to be sure is that we cannot overwrite where u-boot is currently running and its resorces (malloc area, stack, lcd memory,..). That is, after the relocation, quite at the end of the available memory (maybe gd->relocaddr -1 ?).
Best regards, Stefano Babic
Hi Stefano,
On Sat, Apr 14, 2012 at 11:41 AM, stefano babic sbabic@denx.de wrote:
Some considerations about this issue. hopefully I am not OT. The values put in the configuration file are the default parameters taken by the mtest command if no parameters are issued. I agree they must not be set to wrong values (I mean, outside the adressable RAM), but in any case mtest is not run automatically and the range can be adjusted in the console. I can always send a "mtest 0x0x10000000 - 0x177fffff" even if a restricted range is set in the config file, for example as it is set now for the mx6qsabrelite (64k).
Thanks for your and Dirk's explanations. Very helpful!
So I will be for a patch that changes the behavior of mtest and computes automatically the last testable address if the second parameter is not given, dropping CONFIG_SYS_MEMTEST_END - I know, this is not part of your patch, I have already said I can be OT ;-)
Something like the patch below? (Build tested only - no hardware handy right now)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c index fa6f599..fee1d27 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -40,6 +40,8 @@ #define PRINTF(fmt,args...) #endif
+DECLARE_GLOBAL_DATA_PTR; + static int mod_mem(cmd_tbl_t *, int, int, int, char * const []);
/* Display values from last command. @@ -662,7 +664,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char if (argc > 2) end = (ulong *)simple_strtoul(argv[2], NULL, 16); else - end = (ulong *)(CONFIG_SYS_MEMTEST_END); + end = (ulong *)(gd->relocaddr -1 );
if (argc > 3) pattern = (ulong)simple_strtoul(argv[3], NULL, 16); (END)
On Sat, Apr 14, 2012 at 12:24 PM, Fabio Estevam festevam@gmail.com wrote:
Something like the patch below? (Build tested only - no hardware handy right now)
Sorry, I meant the patch below:
--- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -40,6 +40,8 @@ #define PRINTF(fmt,args...) #endif
+DECLARE_GLOBAL_DATA_PTR; + static int mod_mem(cmd_tbl_t *, int, int, int, char * const []);
/* Display values from last command. @@ -656,8 +658,10 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, cha
if (argc > 1) start = (ulong *)simple_strtoul(argv[1], NULL, 16); - else + else { start = (ulong *)CONFIG_SYS_MEMTEST_START; + end = (ulong *)(gd->relocaddr -1 ); + }
if (argc > 2) end = (ulong *)simple_strtoul(argv[2], NULL, 16);
Am 14/04/2012 17:28, schrieb Fabio Estevam:
On Sat, Apr 14, 2012 at 12:24 PM, Fabio Estevam festevam@gmail.com wrote:
Something like the patch below? (Build tested only - no hardware handy right now)
Sorry, I meant the patch below:
--- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -40,6 +40,8 @@ #define PRINTF(fmt,args...) #endif
+DECLARE_GLOBAL_DATA_PTR;
static int mod_mem(cmd_tbl_t *, int, int, int, char * const []);
/* Display values from last command. @@ -656,8 +658,10 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, cha
if (argc > 1) start = (ulong *)simple_strtoul(argv[1], NULL, 16);
else
else { start = (ulong *)CONFIG_SYS_MEMTEST_START;end = (ulong *)(gd->relocaddr -1 );
Something like this, but not exactly this. After sending my answer I remembered that the stack is *before* u-boot code, and not after as I wrote - using gd->relocaddr is wrong. We should subtract the memory reserve for stack and heap from this value.
Stefano
Dear Stefano,
In message 4F899F3B.2080103@denx.de you wrote:
Something like this, but not exactly this. After sending my answer I remembered that the stack is *before* u-boot code, and not after as I wrote - using gd->relocaddr is wrong. We should subtract the memory reserve for stack and heap from this value.
There is no builtin limit for the stack size in U-Boot. It gows downward unchecked.
Best regards,
Wolfgang Denk
Am 14/04/2012 22:15, schrieb Wolfgang Denk:
Dear Stefano,
In message 4F899F3B.2080103@denx.de you wrote:
Something like this, but not exactly this. After sending my answer I remembered that the stack is *before* u-boot code, and not after as I wrote - using gd->relocaddr is wrong. We should subtract the memory reserve for stack and heap from this value.
There is no builtin limit for the stack size in U-Boot. It gows downward unchecked.
I see, but then it seems to me that CONFIG_STACKSIZE is obsolete - right ?
Best regards, Stefano Babic
Dear Fabio Estevam,
In message CAOMZO5B8ipMR5Wvq23d8PY3TkbRktdo4cGvhW5K1VL+7t14bEA@mail.gmail.com you wrote:
Something like the patch below? (Build tested only - no hardware handy right now)
NAK
Best regards,
Wolfgang Denk
Dear Stefano,
In message 4F898CA5.8070308@denx.de you wrote:
The start address CONFIG_SYS_MEMTEST_START is the lowest address of the SDRAM that can be accessed, that is MMDC0_ARB_BASE_ADDR (0x10000000) for i.MX6.
But it _should_ be the lowest address that can _safely_ be used for such tests, i. e. the range MEMTEST_START - MEMTEST_START must neither contain the exception vectors, not U-Boot's code, stack or malloc arena.
dynamically, also the last RAM address that can be tested should be computed at run time and not at compile time with CONFIG_SYS_MEMTEST_END.
CONFIG_SYS_MEMTEST_END is NOT the end of physical RAM, but the end of the range that can be tested without crashing U-Boot...
So I will be for a patch that changes the behavior of mtest and computes automatically the last testable address if the second parameter is not given, dropping CONFIG_SYS_MEMTEST_END - I know, this is not part of your patch, I have already said I can be OT ;-)
Such a patch would be wrong.
Best regards,
Wolfgang Denk
Am 14/04/2012 22:13, schrieb Wolfgang Denk:
Dear Stefano,
In message 4F898CA5.8070308@denx.de you wrote:
The start address CONFIG_SYS_MEMTEST_START is the lowest address of the SDRAM that can be accessed, that is MMDC0_ARB_BASE_ADDR (0x10000000) for i.MX6.
But it _should_ be the lowest address that can _safely_ be used for such tests, i. e. the range MEMTEST_START - MEMTEST_START must neither contain the exception vectors, not U-Boot's code, stack or malloc arena.
dynamically, also the last RAM address that can be tested should be computed at run time and not at compile time with CONFIG_SYS_MEMTEST_END.
CONFIG_SYS_MEMTEST_END is NOT the end of physical RAM, but the end of the range that can be tested without crashing U-Boot...
Well, but why do we have to define at compile time this value, that in most cases can be wrong ? Why should "mtest" use a default value if not all parameters are passed ? IMHO it is better if mtest returns with an error if end address is not provided.
Such a patch would be wrong.
Really I think it is better to get rid completely of CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END without trying to make some (maybe wrong) assumptions, and let mtest doing its job
Best regards, Stefano Babic
Hi Fabio,
On 15.04.2012 11:02, stefano babic wrote:
Am 14/04/2012 22:13, schrieb Wolfgang Denk:
Dear Stefano,
In message 4F898CA5.8070308@denx.de you wrote:
The start address CONFIG_SYS_MEMTEST_START is the lowest address of the SDRAM that can be accessed, that is MMDC0_ARB_BASE_ADDR (0x10000000) for i.MX6.
But it _should_ be the lowest address that can _safely_ be used for such tests, i. e. the range MEMTEST_START - MEMTEST_START must neither contain the exception vectors, not U-Boot's code, stack or malloc arena.
dynamically, also the last RAM address that can be tested should be computed at run time and not at compile time with CONFIG_SYS_MEMTEST_END.
CONFIG_SYS_MEMTEST_END is NOT the end of physical RAM, but the end of the range that can be tested without crashing U-Boot...
Well, but why do we have to define at compile time this value, that in most cases can be wrong ? Why should "mtest" use a default value if not all parameters are passed ? IMHO it is better if mtest returns with an error if end address is not provided.
Such a patch would be wrong.
Really I think it is better to get rid completely of CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END without trying to make some (maybe wrong) assumptions, and let mtest doing its job
Will we get an update of this patch?
Many thanks and best regards
Dirk
Hi Dirk,
On Wed, Jul 11, 2012 at 3:23 AM, Dirk Behme dirk.behme@de.bosch.com wrote:
Will we get an update of this patch?
I plan to send an updated patch in the first week of August.
Regards,
Fabio Estevam
Dear Wolfgang Denk,
Dear Fabio Estevam,
In message 1334158122-15219-1-git-send-email-festevam@gmail.com you wrote:
Add basic support for mx6qsabresd board.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Could you please add a bit information which sort of board this is, where to find documetnation about it, etc.?
+#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " +#define CONFIG_SYS_PROMPT "MX6QSABRESD U-Boot > "
Do we really need such verbose prompts? This appears to be overkill, and is becoming more and more a nuisance. [I wonder when I will see the first board which puts the full version string in the prompt :-( ]
MX28EVK rev. D with U-Boot v2012.04-rc2 00025-g7ae6af4-dirty (Apr 12 2012 - 05:36:01) >>> # _
;-D
+#define CONFIG_SYS_MEMTEST_START 0x10000000 +#define CONFIG_SYS_MEMTEST_END 0x10010000
Does this make sense?
It probably does, it runs memtest on a small piece of memory.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
On 11/04/2012 17:28, Fabio Estevam wrote:
Add basic support for mx6qsabresd board.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Hi Fabio,
MAINTAINERS | 1 + board/freescale/mx6qsabresd/Makefile | 37 ++++++ board/freescale/mx6qsabresd/imximage.cfg | 170 +++++++++++++++++++++++++++ board/freescale/mx6qsabresd/mx6qsabresd.c | 111 ++++++++++++++++++ boards.cfg | 1 + include/configs/mx6qsabresd.h | 178 +++++++++++++++++++++++++++++ 6 files changed, 498 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx6qsabresd/Makefile create mode 100644 board/freescale/mx6qsabresd/imximage.cfg create mode 100644 board/freescale/mx6qsabresd/mx6qsabresd.c create mode 100644 include/configs/mx6qsabresd.h
A general question: in your patch it seems to me that only SD is currently supported on this board. Which is the difference between this board and the mx6qsabrelite we have already mainlined ?
+######################################################################### diff --git a/board/freescale/mx6qsabresd/imximage.cfg b/board/freescale/mx6qsabresd/imximage.cfg new file mode 100644 index 0000000..c389427 --- /dev/null +++ b/board/freescale/mx6qsabresd/imximage.cfg @@ -0,0 +1,170 @@ +# Copyright (C) 2011 Freescale Semiconductor, Inc. +# Jason Liu r64343@freescale.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. 51 Franklin Street Fifth Floor Boston, +# MA 02110-1301 USA +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage
+# image version
+IMAGE_VERSION 2
+# Boot Device : one of +# spi, sd (the board has no nand neither onenand)
+BOOT_FROM sd
+# Device Configuration Data (DCD) +# +# Each entry must have the format: +# Addr-type Address Value +# +# where: +# Addr-type register length (1,2 or 4 bytes) +# Address absolute address of the register +# value value to be stored in the register +DATA 4 0x020e05a8 0x00000030 +DATA 4 0x020e05b0 0x00000030 +DATA 4 0x020e0524 0x00000030 +DATA 4 0x020e051c 0x00000030
+DATA 4 0x020e0518 0x00000030 +DATA 4 0x020e050c 0x00000030 +DATA 4 0x020e05b8 0x00000030 +DATA 4 0x020e05c0 0x00000030
+DATA 4 0x020e05ac 0x00020030 +DATA 4 0x020e05b4 0x00020030 +DATA 4 0x020e0528 0x00020030 +DATA 4 0x020e0520 0x00020030
+DATA 4 0x020e0514 0x00020030 +DATA 4 0x020e0510 0x00020030 +DATA 4 0x020e05bc 0x00020030 +DATA 4 0x020e05c4 0x00020030
+DATA 4 0x020e056c 0x00020030 +DATA 4 0x020e0578 0x00020030 +DATA 4 0x020e0588 0x00020030 +DATA 4 0x020e0594 0x00020030
+DATA 4 0x020e057c 0x00020030 +DATA 4 0x020e0590 0x00003000 +DATA 4 0x020e0598 0x00003000 +DATA 4 0x020e058c 0x00000000
+DATA 4 0x020e059c 0x00003030 +DATA 4 0x020e05a0 0x00003030 +DATA 4 0x020e0784 0x00000030 +DATA 4 0x020e0788 0x00000030
+DATA 4 0x020e0794 0x00000030 +DATA 4 0x020e079c 0x00000030 +DATA 4 0x020e07a0 0x00000030 +DATA 4 0x020e07a4 0x00000030
+DATA 4 0x020e07a8 0x00000030 +DATA 4 0x020e0748 0x00000030 +DATA 4 0x020e074c 0x00000030 +DATA 4 0x020e0750 0x00020000
+DATA 4 0x020e0758 0x00000000 +DATA 4 0x020e0774 0x00020000 +DATA 4 0x020e078c 0x00000030 +DATA 4 0x020e0798 0x000C0000
+DATA 4 0x021b081c 0x33333333 +DATA 4 0x021b0820 0x33333333 +DATA 4 0x021b0824 0x33333333 +DATA 4 0x021b0828 0x33333333
+DATA 4 0x021b481c 0x33333333 +DATA 4 0x021b4820 0x33333333 +DATA 4 0x021b4824 0x33333333 +DATA 4 0x021b4828 0x33333333
+DATA 4 0x021b0018 0x00081740
+DATA 4 0x021b001c 0x00008000 +DATA 4 0x021b000c 0x555A7975 +DATA 4 0x021b0010 0xFF538E64 +DATA 4 0x021b0014 0x01FF00DB +DATA 4 0x021b002c 0x000026D2
+DATA 4 0x021b0030 0x005B0E21 +DATA 4 0x021b0008 0x09444040 +DATA 4 0x021b0004 0x00025576 +DATA 4 0x021b0040 0x00000027 +DATA 4 0x021b0000 0x831A0000
+DATA 4 0x021b001c 0x04088032 +DATA 4 0x021b001c 0x0408803A +DATA 4 0x021b001c 0x00008033 +DATA 4 0x021b001c 0x0000803B +DATA 4 0x021b001c 0x00428031 +DATA 4 0x021b001c 0x00428039 +DATA 4 0x021b001c 0x09408030 +DATA 4 0x021b001c 0x09408038
+DATA 4 0x021b001c 0x04008040 +DATA 4 0x021b001c 0x04008048 +DATA 4 0x021b0800 0xA1380003 +DATA 4 0x021b4800 0xA1380003 +DATA 4 0x021b0020 0x00005800 +DATA 4 0x021b0818 0x00022227 +DATA 4 0x021b4818 0x00022227
+DATA 4 0x021b083c 0x434B0350 +DATA 4 0x021b0840 0x034C0359 +DATA 4 0x021b483c 0x434B0350 +DATA 4 0x021b4840 0x03650348 +DATA 4 0x021b0848 0x4436383B +DATA 4 0x021b4848 0x39393341 +DATA 4 0x021b0850 0x35373933 +DATA 4 0x021b4850 0x48254A36
+DATA 4 0x021b080c 0x001F001F +DATA 4 0x021b0810 0x001F001F
+DATA 4 0x021b480c 0x00440044 +DATA 4 0x021b4810 0x00440044
+DATA 4 0x021b08b8 0x00000800 +DATA 4 0x021b48b8 0x00000800
+DATA 4 0x021b001c 0x00000000 +DATA 4 0x021b0404 0x00011006
+# set the default clock gate to save power +DATA 4 0x020c4068 0x00C03F3F +DATA 4 0x020c406c 0x0030FC03 +DATA 4 0x020c4070 0x0FFFC000 +DATA 4 0x020c4074 0x3FF00000 +DATA 4 0x020c4078 0x00FFF300 +DATA 4 0x020c407c 0x0F0000C3 +DATA 4 0x020c4080 0x000003FF
+# enable AXI cache for VDOA/VPU/IPU +DATA 4 0x020e0010 0xF00000FF +# set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 +DATA 4 0x020e0018 0x007F007F +DATA 4 0x020e001c 0x007F007F
This file is identical to imximage.cfg for the mx6qsabrelite board. I can imagine this is derived board. Why cannot we implement it as a variant of the original one ? We have several example in u-boot, for example the efika (MX51), or the TAM3517 (ok, I admit I know this very well because I did it...), or imx27-lite /magnesium, or....
diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c b/board/freescale/mx6qsabresd/mx6qsabresd.c new file mode 100644 index 0000000..7df2823 --- /dev/null +++ b/board/freescale/mx6qsabresd/mx6qsabresd.c @@ -0,0 +1,111 @@ +/*
- Copyright (C) 2012 Freescale Semiconductor, Inc.
- Author: Fabio Estevam fabio.estevam@freescale.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.
- */
+#include <common.h> +#include <asm/io.h> +#include <asm/arch/imx-regs.h> +#include <asm/arch/mx6x_pins.h> +#include <asm/arch/iomux-v3.h> +#include <asm/errno.h> +#include <asm/gpio.h> +#include <mmc.h> +#include <fsl_esdhc.h>
+DECLARE_GLOBAL_DATA_PTR;
+#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
- PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
- PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
- PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \
- PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
This is also identical to the sabrelite. It seems to me we can manage it only disabling some feature and introducing a way (CONFIG_) to distinguish the two boards, but without adding a new one.
+#ifdef CONFIG_FSL_ESDHC
...for this board if we undefine CONFIG_FSL_ESDHC there is no peripheral at all.
+#define CONFIG_EXTRA_ENV_SETTINGS \
- "script=boot.scr\0" \
- "uimage=uImage\0" \
- "console=ttymxc0\0" \
- "fdt_high=0xffffffff\0" \
- "initrd_high=0xffffffff\0" \
- "mmcdev=0\0" \
- "mmcpart=2\0" \
- "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
- "mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=${mmcroot}\0" \- "loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \- "bootscript=echo Running bootscript from mmc ...; " \
"source\0" \- "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
"mmcboot=echo Booting from mmc ...; " \"run mmcargs; " \"bootm\0" \- "netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs " \"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \- "netboot=echo Booting from net ...; " \
"run netargs; " \"dhcp ${uimage}; bootm\0" \
There is a "netboot", but no NET available. Not a real problem, but it tells me that the board is strictly related to the sabrelite and instead of having a separate implementation we can merge both.
Best regards, Stefano Babic
Hi Stefano,
On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babic sbabic@denx.de wrote:
This file is identical to imximage.cfg for the mx6qsabrelite board. I can imagine this is derived board. Why cannot we implement it as a variant of the original one ? We have several example in u-boot, for example the efika (MX51), or the TAM3517 (ok, I admit I know this very well because I did it...), or imx27-lite /magnesium, or....
After a long time, I am returning on adding support to mx6qsabresd.
I have been comparing mx6qsabrelite against mx6qsabresd and I have started to do as you suggested: unify the 2 boards into mx6qsabrelite.c.
What I realize is that the differences are relevant: UART1 pin muxing, SDHC ports, SDHC card detect GPIO, USB Host enable port, I2C devices, Ethernet PHY, etc.
It seems to me that the code is becoming polluted by all the ifdef's I need to place in order to handle both boards, and I am starting to think if it wouldn't be better to follow with the original approach of adding a board/freescale/mx6qsabresd directory.
After I finish mx6qsabresd, I also plan to add one more mx6q board, and this would mean even more ifdefs, which would make the code even harder to read.
Please let me know what you think.
Regards,
Fabio Estevam
Am 11/09/2012 05:56, schrieb Fabio Estevam:
Hi Stefano,
Hi Fabio,
On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babic sbabic@denx.de wrote:
This file is identical to imximage.cfg for the mx6qsabrelite board. I can imagine this is derived board. Why cannot we implement it as a variant of the original one ? We have several example in u-boot, for example the efika (MX51), or the TAM3517 (ok, I admit I know this very well because I did it...), or imx27-lite /magnesium, or....
After a long time, I am returning on adding support to mx6qsabresd.
I have been comparing mx6qsabrelite against mx6qsabresd and I have started to do as you suggested: unify the 2 boards into mx6qsabrelite.c.
What I realize is that the differences are relevant: UART1 pin muxing, SDHC ports, SDHC card detect GPIO, USB Host enable port, I2C devices, Ethernet PHY, etc.
Of course, unifying boards makes sense if the two boards are very similar.
It seems to me that the code is becoming polluted by all the ifdef's I need to place in order to handle both boards, and I am starting to think if it wouldn't be better to follow with the original approach of adding a board/freescale/mx6qsabresd directory.
After I finish mx6qsabresd, I also plan to add one more mx6q board, and this would mean even more ifdefs, which would make the code even harder to read.
Absolutely. I let you to decide if some code can be shared, but if you see such a lot of differences, go on with a separate board.
Best regards, Stefano Babic
On 11.09.2012 05:56, Fabio Estevam wrote:
Hi Stefano,
On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babic sbabic@denx.de wrote:
This file is identical to imximage.cfg for the mx6qsabrelite board. I can imagine this is derived board. Why cannot we implement it as a variant of the original one ? We have several example in u-boot, for example the efika (MX51), or the TAM3517 (ok, I admit I know this very well because I did it...), or imx27-lite /magnesium, or....
After a long time, I am returning on adding support to mx6qsabresd.
I have been comparing mx6qsabrelite against mx6qsabresd and I have started to do as you suggested: unify the 2 boards into mx6qsabrelite.c.
What I realize is that the differences are relevant: UART1 pin muxing, SDHC ports, SDHC card detect GPIO, USB Host enable port, I2C devices, Ethernet PHY, etc.
It seems to me that the code is becoming polluted by all the ifdef's I need to place in order to handle both boards, and I am starting to think if it wouldn't be better to follow with the original approach of adding a board/freescale/mx6qsabresd directory.
After I finish mx6qsabresd, I also plan to add one more mx6q board, and this would mean even more ifdefs, which would make the code even harder to read.
Please let me know what you think.
I don't know all the boards close enough, but if we could somehow find an unique identifier to be able to auto-detect the board type at runtime and read this early in the boot phase, we could try to have one U-Boot binary for different boards which configures itself correctly at runtime.
Just an idea ...
Best regards
Dirk
On 09/10/2012 08:56 PM, Fabio Estevam wrote:
Hi Stefano,
On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babicsbabic@denx.de wrote:
This file is identical to imximage.cfg for the mx6qsabrelite board. I can imagine this is derived board. Why cannot we implement it as a variant of the original one ? We have several example in u-boot, for example the efika (MX51), or the TAM3517 (ok, I admit I know this very well because I did it...), or imx27-lite /magnesium, or....
After a long time, I am returning on adding support to mx6qsabresd.
I have been comparing mx6qsabrelite against mx6qsabresd and I have started to do as you suggested: unify the 2 boards into mx6qsabrelite.c.
What I realize is that the differences are relevant: UART1 pin muxing, SDHC ports, SDHC card detect GPIO, USB Host enable port, I2C devices, Ethernet PHY, etc.
It seems to me that the code is becoming polluted by all the ifdef's I need to place in order to handle both boards, and I am starting to think if it wouldn't be better to follow with the original approach of adding a board/freescale/mx6qsabresd directory.
After I finish mx6qsabresd, I also plan to add one more mx6q board, and this would mean even more ifdefs, which would make the code even harder to read.
Please let me know what you think.
Hi Fabio and Stefano,
We also need to add support for a board (our Nitrogen6x) which is a slight variation on Sabre Lite.
We have been patching the board/freescale/mx6qsabrelite, and our needs can in general be handled without ifdefs, but it seems that this approach doesn't scale well.
When other vendors produce boards which are also slight variations, where do we draw the line, and more importantly, how do we track and test the needs of each?
Our thinking is that if it's a different board, it should have a different directory, and common code should be clearly separated.
Regards,
Eric
On Tue, Sep 11, 2012 at 11:43 AM, Eric Nelson eric.nelson@boundarydevices.com wrote:
On 09/10/2012 08:56 PM, Fabio Estevam wrote: We also need to add support for a board (our Nitrogen6x) which is a slight variation on Sabre Lite.
We have been patching the board/freescale/mx6qsabrelite, and our needs can in general be handled without ifdefs, but it seems that this approach doesn't scale well.
When other vendors produce boards which are also slight variations, where do we draw the line, and more importantly, how do we track and test the needs of each?
Our thinking is that if it's a different board, it should have a different directory, and common code should be clearly separated.
It is not my call but I think I share your view; even it is a small variation it is better to have it clear also because it is more developer-friendly or developer needs to be careful all the time to not mess with other boards settings.
Am 11/09/2012 16:43, schrieb Eric Nelson:
On 09/10/2012 08:56 PM, Fabio Estevam wrote:
Hi Stefano,
On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babicsbabic@denx.de wrote:
This file is identical to imximage.cfg for the mx6qsabrelite board. I can imagine this is derived board. Why cannot we implement it as a variant of the original one ? We have several example in u-boot, for example the efika (MX51), or the TAM3517 (ok, I admit I know this very well because I did it...), or imx27-lite /magnesium, or....
After a long time, I am returning on adding support to mx6qsabresd.
I have been comparing mx6qsabrelite against mx6qsabresd and I have started to do as you suggested: unify the 2 boards into mx6qsabrelite.c.
What I realize is that the differences are relevant: UART1 pin muxing, SDHC ports, SDHC card detect GPIO, USB Host enable port, I2C devices, Ethernet PHY, etc.
It seems to me that the code is becoming polluted by all the ifdef's I need to place in order to handle both boards, and I am starting to think if it wouldn't be better to follow with the original approach of adding a board/freescale/mx6qsabresd directory.
After I finish mx6qsabresd, I also plan to add one more mx6q board, and this would mean even more ifdefs, which would make the code even harder to read.
Please let me know what you think.
Hi Fabio and Stefano,
Hi Eric,
We also need to add support for a board (our Nitrogen6x) which is a slight variation on Sabre Lite.
We have been patching the board/freescale/mx6qsabrelite, and our needs can in general be handled without ifdefs, but it seems that this approach doesn't scale well.
It seems you want also to put the board with your vendor name, and then goes into a separate directory.
When other vendors produce boards which are also slight variations, where do we draw the line, and more importantly, how do we track and test the needs of each?
There is no strict rule. And of course, if the code is in the same directory, any change should be tested on all boards belonging to this directory. In your case, I understand you prefer to have your board identified with your vendor name and not mixed up with Freescale's boards.
Our thinking is that if it's a different board, it should have a different directory, and common code should be clearly separated.
I like this approach. If we can identify common code, it is better to put it in a common place and make available to all boards, and each board has still its own identity.
Best regards, Stefano
participants (9)
-
Dirk Behme -
Dirk Behme -
Eric Nelson -
Fabio Estevam -
Marek Vasut -
Otavio Salvador -
Stefano Babic -
stefano babic
-
Wolfgang Denk