Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com [...] diff --git a/board/freescale/mvf600twr/mvf600twr.c b/board/freescale/mvf600twr/mvf600twr.c new file mode 100644 index 000..71ee12b --- /dev/null +++ b/board/freescale/mvf600twr/mvf600twr.c @@ -0,0 +1,413 @@ +/* + * Copyright 2013 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. + * + * 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 asm/io.h +#include asm/arch/imx-regs.h +#include asm/arch/mvf_pins.h +#include asm/arch/crm_regs.h +#include asm/arch/clock.h +#include mmc.h +#include fsl_esdhc.h +#include miiphy.h +#include netdev.h + +DECLARE_GLOBAL_DATA_PTR; + +#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ + PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE) + +#define ESDHC_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | \ + PAD_CTL_OBE_IBE_ENABLE) With the changes that I have suggested in my review of your IOMUX patch, ESDHC_PAD_CTRL could be simplified by removing PAD_CTL_PUE. And without those changes, UART_PAD_CTRL and ENET_PAD_CTRL in your current code set pull values that are actually unused (unless the corresponding PKE/PUE bits do not exist and default to pull in the pad control registers used with these definitions). [Alison Wang] Agree. + +#define ENET_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \ + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE) + +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm MUX_PAD_CTRL() could be added to the 4 pad control definitions above in order to avoid repeating it everywhere below. But using MUX_PAD_CTRL() relies on the fact that the pad control values in mvf_pins.h are all 0 (which is the case, but this is dangerous if this is changed later), so a better approach could be to use NEW_PAD_CTRL(), e.g.: NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL), instead of: MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL), + [Alison Wang] I have a question about using NEW_PAD_CTRL(). If NEW_PAD_CTRL() is used, should the pad control values for MVF600_PAD_DDR_A15__DDR_A_15 in mvf_pins.h be the same as DDR_PAD_CTRL? I saw you didn't use the same value on other platforms, how do you define it? Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison, On Wednesday, May 22, 2013 5:17:41 AM, Wang Huan-B18965 wrote: Hi, Benoit, -Original Message- From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com] Sent: Wednesday, May 22, 2013 1:29 AM To: Wang Huan-B18965 Cc: sba...@denx.de; u-boot@lists.denx.de; TsiChung Liew; Jin Zhengxiong- R64188; Estevam Fabio-R49496 Subject: Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board Hi Alison, On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com [...] diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h new file mode 100644 index 000..1cfb9f6 --- /dev/null +++ b/include/configs/mvf600twr.h @@ -0,0 +1,140 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * Configuration settings for the Freescale Vybrid mvf600twr 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. + * + * 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/arch/imx-regs.h +#include config_cmd_default.h + +#define CONFIG_MVF600 + [...] +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPE RMII +#define CONFIG_ETHPRIME FEC You don't need to define this one with only 1 Ethernet interface defined. But isn't the MVF600 a dual-Ethernet SoC? [Alison Wang] Yes, MVF600 is a dual-Ethernet SoC. I will change it to FEC0. Thanks. CONFIG_ETHPRIME should just be removed if you are not going to enable the 2nd FEC in U-Boot. But if you plan to enable the 2nd FEC, which will have to be done now or later for a dual-Ethernet SoC, then you have to: - remove CONFIG_FEC_MXC_PHYADDR and IMX_FEC_BASE, - define CONFIG_ETHPRIME to FEC0, - call fecmxc_initialize_multi() once for each FEC instead of calling fecmxc_initialize() from cpu_eth_init() in generic.c (you can define ENET1_BASE_ADDR and ENET2_BASE_ADDR instead of ENET_BASE_ADDR in imx-regs.h, and CONFIG_FEC1_MXC_PHYADDR and CONFIG_FEC2_MXC_PHYADDR instead of CONFIG_FEC_MXC_PHYADDR in mvf600twr.h, then pass them to fecmxc_initialize_multi() from cpu_eth_init(), with 0 and 1 as the IDs), - add support for the 2nd FEC in imx_get_mac_from_fuse(), - update doc/README.mvf600 to say which fuses are used for the MAC address of the 2nd FEC. [...] Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison, On Wednesday, May 22, 2013 10:23:12 AM, Wang Huan-B18965 wrote: [...] + +#define ENET_PAD_CTRL(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \ + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE) + +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm MUX_PAD_CTRL() could be added to the 4 pad control definitions above in order to avoid repeating it everywhere below. But using MUX_PAD_CTRL() relies on the fact that the pad control values in mvf_pins.h are all 0 (which is the case, but this is dangerous if this is changed later), so a better approach could be to use NEW_PAD_CTRL(), e.g.: NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL), instead of: MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL), + [Alison Wang] I have a question about using NEW_PAD_CTRL(). If NEW_PAD_CTRL() is used, should the pad control values for MVF600_PAD_DDR_A15__DDR_A_15 in mvf_pins.h be the same as DDR_PAD_CTRL? I saw you didn't use the same value on other platforms, how do you define it? No, you don't have to change mvf_pins.h. That's what NEW_PAD_CTRL() is useful for: You can have any pad control value defined in mvf_pins.h, and a board can override the pad control values when using definitions from mvf_pins.h, without having to modify mvf_pins.h. E.g.: --- mvf_pins.h: MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, PAD_CTRL1), mvf600twr.c: NEW_PAD_CTRL(MVF600_PAD_PTA6__RMII0_CLKIN, PAD_CTRL2), --- would have the same effect as a theoretical: --- mvf_pins.h: MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, PAD_CTRL2), mvf600twr.c: MVF600_PAD_PTA6__RMII0_CLKIN, --- But if you think that the pad control values that you have defined in mvf600twr.c are not specific to this board and should be used as the default pad control values for all boards based on the MVF600, then you should move those definitions to mvf_pins.h, and use them there, which means that you will no longer need MUX_PAD_CTRL() or NEW_PAD_CTRL() in mvf600twr.c: --- mvf_pins.h: #define MVF600_DDR_PAD_CTRL PAD_CTL_DSE_25ohm ... MVF600_PAD_DDR_A15__DDR_A_15 = IOMUX_PAD(0x0220, 0x0220, 0, 0x, 0, MVF600_DDR_PAD_CTRL), mvf600twr.c: MVF600_PAD_DDR_A15__DDR_A_15, --- Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, On Wednesday, May 22, 2013 5:17:41 AM, Wang Huan-B18965 wrote: Hi, Benoit, -Original Message- From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com] Sent: Wednesday, May 22, 2013 1:29 AM To: Wang Huan-B18965 Cc: sba...@denx.de; u-boot@lists.denx.de; TsiChung Liew; Jin Zhengxiong- R64188; Estevam Fabio-R49496 Subject: Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board Hi Alison, On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com [...] diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h new file mode 100644 index 000..1cfb9f6 --- /dev/null +++ b/include/configs/mvf600twr.h @@ -0,0 +1,140 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * Configuration settings for the Freescale Vybrid mvf600twr 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. + * + * 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/arch/imx-regs.h +#include config_cmd_default.h + +#define CONFIG_MVF600 + [...] +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPERMII +#define CONFIG_ETHPRIMEFEC You don't need to define this one with only 1 Ethernet interface defined. But isn't the MVF600 a dual-Ethernet SoC? [Alison Wang] Yes, MVF600 is a dual-Ethernet SoC. I will change it to FEC0. Thanks. CONFIG_ETHPRIME should just be removed if you are not going to enable the 2nd FEC in U-Boot. But if you plan to enable the 2nd FEC, which will have to be done now or later for a dual-Ethernet SoC, then you have to: - remove CONFIG_FEC_MXC_PHYADDR and IMX_FEC_BASE, - define CONFIG_ETHPRIME to FEC0, - call fecmxc_initialize_multi() once for each FEC instead of calling fecmxc_initialize() from cpu_eth_init() in generic.c (you can define ENET1_BASE_ADDR and ENET2_BASE_ADDR instead of ENET_BASE_ADDR in imx-regs.h, and CONFIG_FEC1_MXC_PHYADDR and CONFIG_FEC2_MXC_PHYADDR instead of CONFIG_FEC_MXC_PHYADDR in mvf600twr.h, then pass them to fecmxc_initialize_multi() from cpu_eth_init(), with 0 and 1 as the IDs), - add support for the 2nd FEC in imx_get_mac_from_fuse(), - update doc/README.mvf600 to say which fuses are used for the MAC address of the 2nd FEC. [Alison Wang] Agree. Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, On Wednesday, May 22, 2013 10:23:12 AM, Wang Huan-B18965 wrote: [...] + +#define ENET_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \ + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE) + +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm MUX_PAD_CTRL() could be added to the 4 pad control definitions above in order to avoid repeating it everywhere below. But using MUX_PAD_CTRL() relies on the fact that the pad control values in mvf_pins.h are all 0 (which is the case, but this is dangerous if this is changed later), so a better approach could be to use NEW_PAD_CTRL(), e.g.: NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL), instead of: MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL), + [Alison Wang] I have a question about using NEW_PAD_CTRL(). If NEW_PAD_CTRL() is used, should the pad control values for MVF600_PAD_DDR_A15__DDR_A_15 in mvf_pins.h be the same as DDR_PAD_CTRL? I saw you didn't use the same value on other platforms, how do you define it? No, you don't have to change mvf_pins.h. That's what NEW_PAD_CTRL() is useful for: You can have any pad control value defined in mvf_pins.h, and a board can override the pad control values when using definitions from mvf_pins.h, without having to modify mvf_pins.h. E.g.: --- mvf_pins.h: MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, PAD_CTRL1), mvf600twr.c: NEW_PAD_CTRL(MVF600_PAD_PTA6__RMII0_CLKIN, PAD_CTRL2), --- would have the same effect as a theoretical: --- mvf_pins.h: MVF600_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x0, 0x0, 2, 0x0, 0, PAD_CTRL2), mvf600twr.c: MVF600_PAD_PTA6__RMII0_CLKIN, --- But if you think that the pad control values that you have defined in mvf600twr.c are not specific to this board and should be used as the default pad control values for all boards based on the MVF600, then you should move those definitions to mvf_pins.h, and use them there, which means that you will no longer need MUX_PAD_CTRL() or NEW_PAD_CTRL() in mvf600twr.c: --- mvf_pins.h: #define MVF600_DDR_PAD_CTRL PAD_CTL_DSE_25ohm ... MVF600_PAD_DDR_A15__DDR_A_15 = IOMUX_PAD(0x0220, 0x0220, 0, 0x, 0, MVF600_DDR_PAD_CTRL), mvf600twr.c: MVF600_PAD_DDR_A15__DDR_A_15, [Alison Wang] I see. Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison, On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com [...] diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h new file mode 100644 index 000..1cfb9f6 --- /dev/null +++ b/include/configs/mvf600twr.h @@ -0,0 +1,140 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * Configuration settings for the Freescale Vybrid mvf600twr 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. + * + * 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/arch/imx-regs.h +#include config_cmd_default.h + +#define CONFIG_MVF600 + [...] +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPE RMII +#define CONFIG_ETHPRIME FEC You don't need to define this one with only 1 Ethernet interface defined. But isn't the MVF600 a dual-Ethernet SoC? +#define CONFIG_FEC_MXC_PHYADDR 0 +#define CONFIG_PHYLIB +#define CONFIG_PHY_MICREL + +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP /* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ +#define CONFIG_SYS_PROMPT_HUSH_PS2 +#define CONFIG_SYS_PROMPTVybrid U-Boot +#undef CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE\ + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +#define CONFIG_SYS_MEMTEST_START 0x8001 +#define CONFIG_SYS_MEMTEST_END 0x87C0 You now have to #define CONFIG_CMD_MEMTEST for those to be useful. + +#define CONFIG_SYS_LOAD_ADDR 0x8001 + +#define CONFIG_SYS_HZ1000 + +/* + * Stack sizes + * The stack sizes are set up in start.S using the settings below + */ +#define CONFIG_STACKSIZE (128 * 1024)/* regular stack */ + +/* Physical memory map */ +#define CONFIG_NR_DRAM_BANKS 1 +#define PHYS_SDRAM (0x8000) +#define PHYS_SDRAM_SIZE (128 * 1024 * 1024) + +#define CONFIG_SYS_SDRAM_BASEPHYS_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 + +#define CONFIG_ENV_OFFSET(12 * 64 * 1024) +#define CONFIG_SYS_MMC_ENV_DEV 0 + +#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ + +#endif -- 1.8.0 Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison,
On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote:
MVF600TWR is a board based on Vybrid MVF600 SoC.
This patch adds basic support for Vybrid MVF600TWR board.
Signed-off-by: Alison Wang b18...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
Signed-off-by: TsiChung Liew tsicl...@gmail.com
[...]
diff --git a/board/freescale/mvf600twr/mvf600twr.c
b/board/freescale/mvf600twr/mvf600twr.c
new file mode 100644
index 000..71ee12b
--- /dev/null
+++ b/board/freescale/mvf600twr/mvf600twr.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright 2013 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.
+ *
+ * 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 asm/io.h
+#include asm/arch/imx-regs.h
+#include asm/arch/mvf_pins.h
+#include asm/arch/crm_regs.h
+#include asm/arch/clock.h
+#include mmc.h
+#include fsl_esdhc.h
+#include miiphy.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define UART_PAD_CTRL(PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
+
+#define ESDHC_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | \
+ PAD_CTL_OBE_IBE_ENABLE)
With the changes that I have suggested in my review of your IOMUX patch,
ESDHC_PAD_CTRL could be simplified by removing PAD_CTL_PUE.
And without those changes, UART_PAD_CTRL and ENET_PAD_CTRL in your current code
set pull values that are actually unused (unless the corresponding PKE/PUE bits
do not exist and default to pull in the pad control registers used with these
definitions).
+
+#define ENET_PAD_CTRL(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
+ PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
+
+#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm
MUX_PAD_CTRL() could be added to the 4 pad control definitions above in order to
avoid repeating it everywhere below. But using MUX_PAD_CTRL() relies on the fact
that the pad control values in mvf_pins.h are all 0 (which is the case, but this
is dangerous if this is changed later), so a better approach could be to use
NEW_PAD_CTRL(), e.g.:
NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL),
instead of:
MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+
+iomux_v3_cfg_t const ddr_pads[] = {
+ MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A14__DDR_A_14 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A13__DDR_A_13 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A12__DDR_A_12 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A11__DDR_A_11 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A10__DDR_A_10 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A9__DDR_A_9 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A8__DDR_A_8 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A7__DDR_A_7 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A6__DDR_A_6 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A5__DDR_A_5 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A4__DDR_A_4 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A3__DDR_A_3 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A2__DDR_A_2 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_A1__DDR_A_1 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_BA2__DDR_BA_2 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_BA1__DDR_BA_1 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_BA0__DDR_BA_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_CAS__DDR_CAS_B | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_CKE__DDR_CKE_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_CLK__DDR_CLK_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_CS__DDR_CS_B_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D15__DDR_D_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D14__DDR_D_14 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D13__DDR_D_13 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D12__DDR_D_12 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D11__DDR_D_11 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D10__DDR_D_10 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+ MVF600_PAD_DDR_D9__DDR_D_9 | MUX_PAD_CTRL(DDR_PAD_CTRL),
+
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi, Benoit, On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com [...] diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h new file mode 100644 index 000..1cfb9f6 --- /dev/null +++ b/include/configs/mvf600twr.h @@ -0,0 +1,140 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * Configuration settings for the Freescale Vybrid mvf600twr 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. + * + * 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/arch/imx-regs.h +#include config_cmd_default.h + +#define CONFIG_MVF600 + [...] +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPE RMII +#define CONFIG_ETHPRIME FEC You don't need to define this one with only 1 Ethernet interface defined. But isn't the MVF600 a dual-Ethernet SoC? [Alison Wang] Yes, MVF600 is a dual-Ethernet SoC. I will change it to FEC0. +#define CONFIG_FEC_MXC_PHYADDR 0 +#define CONFIG_PHYLIB +#define CONFIG_PHY_MICREL + +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP /* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ +#define CONFIG_SYS_PROMPT_HUSH_PS2 +#define CONFIG_SYS_PROMPTVybrid U-Boot +#undef CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE\ + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +#define CONFIG_SYS_MEMTEST_START 0x8001 +#define CONFIG_SYS_MEMTEST_END 0x87C0 You now have to #define CONFIG_CMD_MEMTEST for those to be useful. [Alison Wang] OK. Thanks. + +#define CONFIG_SYS_LOAD_ADDR 0x8001 + +#define CONFIG_SYS_HZ1000 + +/* + * Stack sizes + * The stack sizes are set up in start.S using the settings below + */ +#define CONFIG_STACKSIZE (128 * 1024)/* regular stack */ + +/* Physical memory map */ +#define CONFIG_NR_DRAM_BANKS 1 +#define PHYS_SDRAM (0x8000) +#define PHYS_SDRAM_SIZE (128 * 1024 * 1024) + +#define CONFIG_SYS_SDRAM_BASEPHYS_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 + +#define CONFIG_ENV_OFFSET(12 * 64 * 1024) +#define CONFIG_SYS_MMC_ENV_DEV 0 + +#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ + +#endif -- 1.8.0 Best regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
