Re: [U-Boot] [RFC] PPC: post_word_{load/store} - eliminate redundant code
On Thu, Apr 22, 2010 at 12:40 AM, Wolfgang Denk w...@denx.de wrote: Looking at the code I wonder why we need post_word_store() and post_word_load() functions at all. All implementations I have found translate into a single ioread32() resp. iowrite32() call. Probably, due to big and little endians that the PPC code should support. On other hand, AFAIK, no one is really using a little endian notation on PPC platforms in u-boot. I am not sure however, is this a good enough reason to omit such support? Or am I missing something? Yes, I have seen them also. I actually thought to clean up them but do it in two phases - first make the post_word accessors to be common per arch and define them as weak so it will not break existing code. Afterwords - eliminate an existing redundant code. Thanks for the tips. Please let me know how do you want me to proceed with the patch? I think we should perform this cleanup in the following steps: 1) Move bootcount_store() and bootcount_load() to architecture specific generic locations; this includes both the PowerPC and ARM implementations 2) Move arch/blackfin/lib/post.c to post/ 3) Eliminate post_word_store() and post_word_load() and use ioread32() resp. iowrite32() (or equivalents) directly. Thanks Wolfgang, it looks like I can cope with this task, of course if no one has any objections. Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] PPC: post_word_{load/store} - eliminate redundant code
Dear Michael Zaidman, In message i2o660c0f821004212341w74ed641aw94cd8738f1b9c...@mail.gmail.com you wrote: Looking at the code I wonder why we need post_word_store() and post_word_load() functions at all. All implementations I have found translate into a single ioread32() resp. iowrite32() call. Probably, due to big and little endians that the PPC code should support. On other hand, AFAIK, no one is really using a little endian notation on PPC platforms in u-boot. I am not sure however, is this a good enough reason to omit such support? Or am I missing something? We don;t indterface to any specific device register here, so the actual byte order used when writing and reading the data does not matter at all (as long as writer and reader agree). I see no reason why we should not simply use the respective accessor macro for this architecture. Thanks Wolfgang, it looks like I can cope with this task, of course if no one has any objections. Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God grant me the senility to accept the things I cannot change, The frustration to try to change things I cannot affect, and the wisdom to tell the difference. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Davinci: Move config of MAC address to board setup
Hi Ben, Please read the documentation. This is not how it's done. Ok, thanks for the info. After reading doc/README.enetaddr I think I understand how it's done right. I already have reworked my patch that way. I'll wait with re-submitting until things have settled. Regards, Andreas. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5 v3] nios2: fix no flash, add nand and mmc init in board.c
This patch fixes error when CONFIG_SYS_NO_FLASH. And adds nand flash and mmc initialization, which should go before env initialization. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v3 include mmc.h and nand.h. v2 arch dir reorganized. arch/nios2/lib/board.c | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/nios2/lib/board.c b/arch/nios2/lib/board.c index 8ec66a3..f83e691 100644 --- a/arch/nios2/lib/board.c +++ b/arch/nios2/lib/board.c @@ -28,6 +28,7 @@ #include stdio_dev.h #include watchdog.h #include malloc.h +#include mmc.h #include net.h #ifdef CONFIG_STATUS_LED #include status_led.h @@ -35,6 +36,9 @@ #if defined(CONFIG_SYS_NIOS_EPCSBASE) #include nios2-epcs.h #endif +#ifdef CONFIG_CMD_NAND +#include nand.h /* cannot even include nand.h if it isnt configured */ +#endif DECLARE_GLOBAL_DATA_PTR; @@ -100,7 +104,9 @@ void board_init (void) bd = gd-bd; bd-bi_memstart = CONFIG_SYS_SDRAM_BASE; bd-bi_memsize = CONFIG_SYS_SDRAM_SIZE; +#ifndef CONFIG_SYS_NO_FLASH bd-bi_flashstart = CONFIG_SYS_FLASH_BASE; +#endif #ifdefined(CONFIG_SYS_SRAM_BASE) defined(CONFIG_SYS_SRAM_SIZE) bd-bi_sramstart= CONFIG_SYS_SRAM_BASE; bd-bi_sramsize = CONFIG_SYS_SRAM_SIZE; @@ -119,8 +125,20 @@ void board_init (void) /* The Malloc area is immediately below the monitor copy in RAM */ mem_malloc_init(CONFIG_SYS_MALLOC_BASE, CONFIG_SYS_MALLOC_LEN); +#ifndef CONFIG_SYS_NO_FLASH WATCHDOG_RESET (); bd-bi_flashsize = flash_init(); +#endif + +#ifdef CONFIG_CMD_NAND + puts(NAND: ); + nand_init(); +#endif + +#ifdef CONFIG_GENERIC_MMC + puts(MMC: ); + mmc_initialize(bd); +#endif WATCHDOG_RESET (); env_relocate(); -- 1.6.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] PPC: post_word_{load/store} - eliminate redundant code
On Thu, Apr 22, 2010 at 12:03 PM, Wolfgang Denk w...@denx.de wrote: Looking at the code I wonder why we need post_word_store() and post_word_load() functions at all. All implementations I have found translate into a single ioread32() resp. iowrite32() call. Probably, due to big and little endians that the PPC code should support. On other hand, AFAIK, no one is really using a little endian notation on PPC platforms in u-boot. I am not sure however, is this a good enough reason to omit such support? Or am I missing something? We don;t indterface to any specific device register here, so the actual byte order used when writing and reading the data does not matter at all (as long as writer and reader agree). I see no reason why we should not simply use the respective accessor macro for this architecture. Ah, of course, that's correct. Thanks, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Add support for MB86R0x SoCs
This patchset adds support for MB86R0x SoC familiy from Fujitsu, its built in lcd controller and a first board using the MB86R01. Matthias Weisser (3): arm: Add support for MB86R0x SoCs video: add support for display controller in MB86R0x SoCs arm: Add support for jadecpu board based on MB86R01 SoC MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 47 + arch/arm/cpu/arm926ejs/mb86r0x/reset.c | 37 arch/arm/cpu/arm926ejs/mb86r0x/timer.c | 129 arch/arm/include/asm/arch-mb86r0x/hardware.h | 31 +++ arch/arm/include/asm/arch-mb86r0x/mb86r0x.h | 170 board/syteco/jadecpu/Makefile| 55 + board/syteco/jadecpu/config.mk |1 + board/syteco/jadecpu/jadecpu.c | 198 ++ board/syteco/jadecpu/lowlevel_init.S | 279 ++ common/serial.c |3 +- drivers/video/Makefile |1 + drivers/video/cfb_console.c |8 + drivers/video/mb86r0xgdc.c | 194 ++ include/configs/jadecpu.h| 189 + include/serial.h |3 +- tools/Makefile |3 + tools/logos/syteco.bmp | Bin 0 - 11414 bytes 20 files changed, 1354 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/Makefile create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/reset.c create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/timer.c create mode 100644 arch/arm/include/asm/arch-mb86r0x/hardware.h create mode 100644 arch/arm/include/asm/arch-mb86r0x/mb86r0x.h create mode 100644 board/syteco/jadecpu/Makefile create mode 100644 board/syteco/jadecpu/config.mk create mode 100644 board/syteco/jadecpu/jadecpu.c create mode 100644 board/syteco/jadecpu/lowlevel_init.S create mode 100644 drivers/video/mb86r0xgdc.c create mode 100644 include/configs/jadecpu.h create mode 100644 tools/logos/syteco.bmp ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm: Add support for MB86R0x SoCs
This patch adds support for MB86R0x SoCs from Fujitsu
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 47 +++
arch/arm/cpu/arm926ejs/mb86r0x/reset.c | 37 ++
arch/arm/cpu/arm926ejs/mb86r0x/timer.c | 129 +++
arch/arm/include/asm/arch-mb86r0x/hardware.h | 31 +
arch/arm/include/asm/arch-mb86r0x/mb86r0x.h | 170 ++
5 files changed, 414 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/Makefile
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/reset.c
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/timer.c
create mode 100644 arch/arm/include/asm/arch-mb86r0x/hardware.h
create mode 100644 arch/arm/include/asm/arch-mb86r0x/mb86r0x.h
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
b/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
new file mode 100644
index 000..360f046
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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$(SOC).a
+
+COBJS = timer.o reset.o
+SOBJS =
+
+SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+START := $(addprefix $(obj),$(START))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
b/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
new file mode 100644
index 000..6acb5bb
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
@@ -0,0 +1,37 @@
+/*
+ * (C) Copyright 2010
+ * Matthias Weisser weiss...@arcor.de
+ *
+ * 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 asm/io.h
+#include asm/arch/hardware.h
+
+/*
+ * Reset the cpu by setting software reset request bit
+ */
+void reset_cpu(ulong ignored)
+{
+ writel(0x0002, MB86R0x_CRG_PHYS_BASE + CRG_CRSR);
+ while (1)
+ /* NOP */;
+ /* Never reached */
+}
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/timer.c
b/arch/arm/cpu/arm926ejs/mb86r0x/timer.c
new file mode 100644
index 000..640b80e
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/timer.c
@@ -0,0 +1,129 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop stelian@leadtechdesign.com
+ * Lead Tech Design www.leadtechdesign.com
+ *
+ * (C) Copyright 2010
+ * Matthias Weisser weiss...@arcor.de
+ *
+ * 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
[U-Boot] [PATCH 2/3] video: add support for display controller in MB86R0x SoCs
This patch adds support for the display controller in
the MB86R0x SoCs.
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
drivers/video/Makefile |1 +
drivers/video/cfb_console.c |8 ++
drivers/video/mb86r0xgdc.c | 194 +++
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mb86r0xgdc.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index a5e339a..1a60ec6 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_VIDEO_AMBA) += amba.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
+COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o
COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
COBJS-$(CONFIG_SED156X) += sed156x.o
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index d1f47c9..4769cdb 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -153,6 +153,14 @@ CONFIG_VIDEO_HW_CURSOR: - Uses the hardware cursor
capability of the
#endif
/*/
+/* Defines for the MB86R0xGDC driver*/
+/*/
+#ifdef CONFIG_VIDEO_MB86R0xGDC
+
+#define VIDEO_FB_16BPP_WORD_SWAP
+#endif
+
+/*/
/* Include video_fb.h after definitions of VIDEO_HW_RECTFILL etc*/
/*/
#include video_fb.h
diff --git a/drivers/video/mb86r0xgdc.c b/drivers/video/mb86r0xgdc.c
new file mode 100644
index 000..9022730
--- /dev/null
+++ b/drivers/video/mb86r0xgdc.c
@@ -0,0 +1,194 @@
+/*
+ * (C) Copyright 2010
+ * Matthias Weisser weiss...@arcor.de
+ *
+ * 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
+ */
+
+/*
+ * mb86r0x.c - Graphic interface for Fujitsu MB86R0x integrated graphic
+ * controller. Derived from mb862xx.c
+ */
+
+#include common.h
+
+#include malloc.h
+#include mb862xx.h
+#include asm/io.h
+#include asm/arch/hardware.h
+#include video_fb.h
+#include videomodes.h
+
+/*
+ * 4MB (at the end of system RAM)
+ */
+#define VIDEO_MEM_SIZE 0x40
+
+/*
+ * Graphic Device
+ */
+static GraphicDevice mb86r0x;
+
+void *video_hw_init(void)
+{
+ GraphicDevice *pGD = mb86r0x;
+ struct ctfb_res_modes var_mode[2];
+ unsigned long *vid;
+ unsigned long div;
+ unsigned long dspBase[2];
+ char *penv;
+ int bpp;
+ int i, j;
+
+ memset(pGD, 0, sizeof(GraphicDevice));
+
+ dspBase[0] = MB86R0x_GDC_DISP0_PHYS_BASE;
+ dspBase[1] = MB86R0x_GDC_DISP1_PHYS_BASE;
+
+ pGD-frameAdrs = MB86R0x_GDC_PHYS_BASE;
+ pGD-gdfIndex = GDF_15BIT_555RGB;
+ pGD-gdfBytesPP = 2;
+
+ pGD-memSize = VIDEO_MEM_SIZE;
+ pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;
+ vid = (unsigned long *)pGD-frameAdrs;
+
+ for (i = 0; i 2; i++) {
+ char varName[32];
+ u32 dcm1, dcm2, dcm3;
+ u16 htp, hdp, hdb, hsp, vtr, vsp, vdp;
+ u8 hsw, vsw;
+ u32 l2m, l2em, l2oa0, l2da0, l2oa1, l2da1;
+ u16 l2dx, l2dy, l2wx, l2wy, l2ww, l2wh;
+
+ sprintf(varName, gs_dsp_%d_param, i);
+
+ penv = getenv(varName);
+ if (penv == NULL) {
+ penv = getenv(videomode);
+ if ((i == 1) || (penv == NULL))
+ continue;
+ }
+
+ bpp = 0;
+ bpp = video_get_params(var_mode[i], penv);
+
+ if (bpp == 0) {
+ var_mode[i].xres = 640;
+ var_mode[i].yres = 480;
+ var_mode[i].pixclock = 39721; /* 25MHz */
+ var_mode[i].left_margin = 48;
+ var_mode[i].right_margin = 16;
+ var_mode[i].upper_margin = 33;
+
[U-Boot] [PATCH 3/3] arm: Add support for jadecpu board based on MB86R01 SoC
This patch adds support for the jadecpu board using the MB86R01 'Jade' SoC from Fujitsu. Signed-off-by: Matthias Weisser weiss...@arcor.de --- MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/syteco/jadecpu/Makefile| 55 +++ board/syteco/jadecpu/config.mk |1 + board/syteco/jadecpu/jadecpu.c | 198 board/syteco/jadecpu/lowlevel_init.S | 279 ++ common/serial.c |3 +- include/configs/jadecpu.h| 189 +++ include/serial.h |3 +- tools/Makefile |3 + tools/logos/syteco.bmp | Bin 0 - 11414 bytes 12 files changed, 737 insertions(+), 2 deletions(-) create mode 100644 board/syteco/jadecpu/Makefile create mode 100644 board/syteco/jadecpu/config.mk create mode 100644 board/syteco/jadecpu/jadecpu.c create mode 100644 board/syteco/jadecpu/lowlevel_init.S create mode 100644 include/configs/jadecpu.h create mode 100644 tools/logos/syteco.bmp diff --git a/MAINTAINERS b/MAINTAINERS index 04c8730..ac0ed62 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -776,6 +776,10 @@ Prafulla Wadaskar prafu...@marvell.com rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) +Matthias Weisser matthias.weis...@graf-syteco.de + + jadecpu ARM926EJS (MB86R01 SoC) + Richard Woodruff r-woodru...@ti.com omap2420h4 ARM1136EJS diff --git a/MAKEALL b/MAKEALL index fb1f7a3..5ee9678 100755 --- a/MAKEALL +++ b/MAKEALL @@ -561,6 +561,7 @@ LIST_ARM9= \ edb9315 \ edb9315a\ imx27lite \ + jadecpu \ lpd7a400\ mv88f6281gtw_ge \ mx1ads \ diff --git a/Makefile b/Makefile index 0381c81..4fdd216 100644 --- a/Makefile +++ b/Makefile @@ -2834,6 +2834,9 @@ CPU9260_config: unconfig @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91 +jadecpu_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs jadecpu syteco mb86r0x + meesc_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 diff --git a/board/syteco/jadecpu/Makefile b/board/syteco/jadecpu/Makefile new file mode 100644 index 000..87d2234 --- /dev/null +++ b/board/syteco/jadecpu/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y+= jadecpu.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(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/syteco/jadecpu/config.mk b/board/syteco/jadecpu/config.mk new file mode 100644 index 000..c661f0b --- /dev/null +++ b/board/syteco/jadecpu/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x4600 diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c new file mode 100644 index 000..ecc6742 --- /dev/null +++ b/board/syteco/jadecpu/jadecpu.c @@ -0,0 +1,198 @@ +/* + * (c) 2010 Graf-Syteco, Matthias Weisser + * weiss...@arcor.de + * + * (C) Copyright 2007, mycable GmbH + * Carsten Schneider c...@mycable.de, Alexander Bigga a...@mycable.de + * + * This program is free software; you can redistribute it
[U-Boot] compiling u-boot failed for TI Davinci DM355 EVM (davinci_dm355evm_config)
Hi all, I tried to compile the u-boot-2009.11 and u-boot-2010.03 for TI Davinci DM355 EVM (davinci_dm355evm_config) board but it ended up with the following error. could some one please help me in finding where exaclty the problem is. the log is as below for u-boot-2009.11 -- Best Regards, Mohamed Thalib H make[1]: Leaving directory `/home/thalib/src/u-boot-2009.11/board/davinci/dm355evm' make -C /home/thalib/src/u-boot-2009.11/cpu/arm926ejs/ u-boot.lds make[1]: Entering directory `/home/thalib/src/u-boot-2009.11/cpu/arm926ejs' make[1]: Nothing to be done for `u-boot.lds'. make[1]: Leaving directory `/home/thalib/src/u-boot-2009.11/cpu/arm926ejs' /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc -E -g -Os -fno-common -ffixed-r8 -msoft-float -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x8108 -I/home/thalib/src/u-boot-2009.11/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5tl-montavista-linuxeabi/3.4.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm-mabi=apcs-gnu -mno-thumb-interwork -march=armv5te -march=armv5te -include /home/thalib/src/u-boot-2009.11/include/u-boot/u-boot.lds.h -DLD_MAJOR=2 -DLD_MINOR=15 -ansi -D__ASSEMBLY__ -P - /home/thalib/src/u-boot-2009.11/cpu/arm926ejs/u-boot.lds u-boot.lds UNDEF_SYM=`/opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-objdump -x board/davinci/dm355evm/libdm355evm.a lib_generic/libgeneric.a lib_generic/lzma/liblzma.a lib_generic/lzo/liblzo.a board/davinci/common/libdavinci.a cpu/arm926ejs/libarm926ejs.a cpu/arm926ejs/davinci/libdavinci.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a fs/yaffs2/libyaffs2.a fs/ubifs/libubifs.a net/libnet.a disk/libdisk.a drivers/bios_emulator/libatibiosemu.a drivers/block/libblock.a drivers/dma/libdma.a drivers/fpga/libfpga.a drivers/gpio/libgpio.a drivers/hwmon/libhwmon.a drivers/i2c/libi2c.a drivers/input/libinput.a drivers/misc/libmisc.a drivers/mmc/libmmc.a drivers/mtd/libmtd.a drivers/mtd/nand/libnand.a drivers/mtd/onenand/libonenand.a drivers/mtd/ubi/libubi.a drivers/mtd/spi/libspi_flash.a drivers/net/libnet.a drivers/net/phy/libphy.a drivers/net/sk98lin/libsk98lin.a drivers/pci/libpci.a drivers/pcmcia/libpcmcia.a drivers/power/libpower.a drivers/spi/libspi.a drivers/rtc/librtc.a drivers/serial/libserial.a drivers/twserial/libtws.a drivers/usb/gadget/libusb_gadget.a drivers/usb/host/libusb_host.a drivers/usb/musb/libusb_musb.a drivers/video/libvideo.a drivers/watchdog/libwatchdog.a common/libcommon.a libfdt/libfdt.a api/libapi.a post/libpost.a | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/thalib/src/u-boot-2009.11 /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ld -Bstatic -T u-boot.lds -Ttext 0x8108 $UNDEF_SYM cpu/arm926ejs/start.o --start-group lib_generic/libgeneric.a lib_generic/lzma/liblzma.a lib_generic/lzo/liblzo.a board/davinci/common/libdavinci.a cpu/arm926ejs/libarm926ejs.a cpu/arm926ejs/davinci/libdavinci.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a fs/yaffs2/libyaffs2.a fs/ubifs/libubifs.a net/libnet.a disk/libdisk.a drivers/bios_emulator/libatibiosemu.a drivers/block/libblock.a drivers/dma/libdma.a drivers/fpga/libfpga.a drivers/gpio/libgpio.a drivers/hwmon/libhwmon.a drivers/i2c/libi2c.a drivers/input/libinput.a drivers/misc/libmisc.a drivers/mmc/libmmc.a drivers/mtd/libmtd.a drivers/mtd/nand/libnand.a drivers/mtd/onenand/libonenand.a drivers/mtd/ubi/libubi.a drivers/mtd/spi/libspi_flash.a drivers/net/libnet.a drivers/net/phy/libphy.a drivers/net/sk98lin/libsk98lin.a drivers/pci/libpci.a drivers/pcmcia/libpcmcia.a drivers/power/libpower.a drivers/spi/libspi.a drivers/rtc/librtc.a drivers/serial/libserial.a drivers/twserial/libtws.a drivers/usb/gadget/libusb_gadget.a drivers/usb/host/libusb_host.a drivers/usb/musb/libusb_musb.a drivers/video/libvideo.a drivers/watchdog/libwatchdog.a common/libcommon.a libfdt/libfdt.a api/libapi.a post/libpost.a board/davinci/dm355evm/libdm355evm.a --end-group -L /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5tl-montavista-linuxeabi/3.4.3 -lgcc -Map u-boot.map -o u-boot /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ld: /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5tl-montavista-linuxeabi/3.4.3/libgcc.a(_udivsi3.oS): warning: duplicate section `.note.gnu.arm.ident' has different contents /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ld: /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5tl-montavista-linuxeabi/3.4.3/libgcc.a(_divsi3.oS): warning: duplicate section `.note.gnu.arm.ident' has different contents
Re: [U-Boot] [PATCH 1/4] keymile: rework headerfiles for keymile boards
Dear Heiko Schocher,
sorry for the late review.
In message 4bc2ccba.9090...@denx.de you wrote:
- This patch reworks all headerfiles for keymile boards (coge, supx4,
eter1, suen3).
Furthermore, a refactoring on the whole environment variables has been
acomplished.
- introduces the variable initial_boot_bank to the default
environment. The actual_bank is set to this value on first
startup.
It is normally set to 0. So the behaviour is as before.
If set to != 0, the first actual_bank is set to this
value as well. Thus a bootpackage can define a boot
bank other than 0.
Please define what a boot bank or a bootpackage is. I have no clue
what you might mean.
+/* protected RAM */
+#define CONFIG_PRAM 0 /* enable PRAM */
This makes little sense to me. If you enable the feature, you probably
also want to define a non-zero amount of PRAM reserved, or why do you
enable this at all?
+/* pseudo-non volatile RAM [hex] */
+#define CONFIG_KM_PNVRAM 0x8
+/* physical RAM MTD size [hex] */
+#define CONFIG_KM_PHRAM 0x10
+/* resereved pram area at the end of memroy [hex] */
+#define CONFIG_KM_RESERVED_PRAM 0x0
What's this? PRAM support is a standard feature, with well-defined
behaviour, including the location of the PRAM area.
...
+/* resereved pram area at the end of memroy [hex] */
[typo!]
+/* 8Mbytes for switch + 4Kbytes for bootcount */
+#define CONFIG_KM_RESERVED_PRAM 0x801000
???
+#define CONFIG_KM_DEF_ENV_CPU
\
+ addbootcount= \
+ setexpr bootcountaddr ${memsize} - ${reservedpram} \
Argh...
...
+...@end_of_ram: denotes the RAM size found in variable 'memsize'
+...@reserved: reserved pram for special purpose (switch, bootcount, ...)
+ reserved space: 'reservedpram'
...
+This addresses are computed when running one of the boot targets:
+ - 'release': for a standalone systemkernel/rootfs from flash
+ - 'develop': for developmentkernel(tftp)/rootfs(NFS)
+ - 'ramfs': rootfilesystem in RAMkernel(tftp)/rootfs(RAM)
+The variable 'pram' is set accordingly.
???
+ addmem= \
+ setexpr value ${pram} * 0x400 \
+ setexpr value ${memsize} - 0x${value} \
+ setenv bootargs ${bootargs} mem=0x${value}\0 \
...
NAK.
I think this code is based on a serious misconception about how PRAM
is supposed to work.
Please re-read section Protected RAM in the README. None of what you
are doing here should be needed, as this is inherent functionality of
the PRAM feature. It seems to me that you are trying to use this on a
ARM system, where PRAM support seems to be missing. If so, it should
be implemented in a clean and generic way (similar to how it's done
for PowerPC, and according to the documentation in the REAME).
Manually computing this and that in a board-specific way is not
acceptable.
Other remarks:
--- a/include/configs/keymile-common.h
+++ b/include/configs/keymile-common.h
This is suposed to be a common file for Keymile boards, right?
+#ifndef CONFIG_MACH_SUEN3
...
+#else
...
+#endif
Then this has no place here. The SUEN3 specific code should be moved
to the SUEN3 board config file.
+/**/
+/*** COMMON
***/
+/**/
Incorrect multiline comment style. And hey, why do we need this? I
think all of this is common stuff?
+...@end_of_ram: denotes the RAM size found in variable 'memsize'
This should not be needed either.
...
+ * - 'falshargs': defaults arguments for flash base boot
This looks fals[c]h to me :-)
+/*
+ * compute_addr
+ * - compute addresses and sizes
+ * - addresses are calculated form the end of memory 'memsize'
+ *
+ * - 'setpnvramaddr': compute PNVRAM address
+ * - 'setpram': compute PRAM size for develop/release target
+ * - 'setramfspram': compute PRAM size for ramfs target
+ * - 'setrootfsaddr': compute rootfilesystem address for phram
+ * - 'setvaraddr': compute /var address for phram
Please clean up after fixing PRAM support.
In general, I fail to see what the purpose of this refactoring is.
The statistics are pretty clear:
include/configs/keymile-common.h | 577
++
include/configs/km8xx.h | 35 ++--
include/configs/km_arm.h |2 -
include/configs/kmeter1.h| 40 ++--
include/configs/mgcoge.h | 35 ++--
5 files changed, 512 insertions(+), 177 deletions(-)
For each line you delete you have to insert 3 new lines. In general,
this is not an
Re: [U-Boot] [PATCH 2/4] mpc832x: add support for the mpc8321 based suvd3 board
Dear Heiko Schocher,
In message 4bc2ccbe.6060...@denx.de you wrote:
- serial console on UART1
- Ethernet RMII over UCC4
- PHY SMSC LAN8700
- 64MB Flash
- 128 MB DDR2 RAM
- I2C
- bootcount
This board is similiar to the kmeter1 (8360) board,
so common config options are extracted into the
include/configs/km83xx-common.h file.
--- a/board/keymile/kmeter1/kmeter1.c
+++ b/board/keymile/km83xx/km83xx.c
@@ -11,6 +11,9 @@
* (C) Copyright 2008
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
*
+ * (C) Copyright 2009
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
Please use a single entry and use 2008-2009 instead. Please fix
globally.
Or is this 2010 actually?
+#if defined(CONFIG_SUVD3)
+const uint upma_table[] =
+{ 0x1ffedc00, 0x0ffcdc80, 0x0ffcdc80, 0x0ffcdc04, //Words 0 to 3
+ 0x0ffcdc00, 0xcc00, 0xcc01, 0xfc01, //Words 4 to 7
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 8 to 11
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 12 to 15
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 16 to 19
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 20 to 23
+ 0x9cfffc00, 0x00fffc80, 0x00fffc80, 0x00fffc00, //Words 24 to 27
+ 0xec04, 0xec01, 0xfc01, 0xfc01, //Words 28 to 31
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 32 to 35
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 36 to 39
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 40 to 43
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 44 to 47
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 48 to 51
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 52 to 55
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 56 to 59
+ 0xfc01, 0xfc01, 0xfc01, 0xfc01 //Words 60 to 63
+};
+#endif
No C++ comments, please. Please fix globally.
int checkboard (void)
{
- puts (Board: Keymile kmeter1);
+ puts (Board: Keymile );
+ puts(CONFIG_KM_BOARD_NAME);
Please write:
puts(Board: Keymile CONFIG_KM_BOARD_NAME);
--- a/cpu/mpc83xx/cpu.c
+++ b/cpu/mpc83xx/cpu.c
@@ -305,7 +305,7 @@ int cpu_mmc_init(bd_t *bis)
#ifdef CONFIG_BOOTCOUNT_LIMIT
-#if !defined(CONFIG_MPC8360)
+#if !defined(CONFIG_MPC8360) !defined(CONFIG_MPC832x)
#error CONFIG_BOOTCOUNT_LIMIT only for MPC8360 implemented
Code and comments don't agree.
And please keep list sorted (832x 8360). Please fix globally.
...
+#undef CONFIG_DDR_ECC
+
+/*
+ * DDRCDR - DDR Control Driver Register
+ */
+
+#undef CONFIG_SPD_EEPROM /* Do not use SPD EEPROM for DDR setup */
No need to undefine what is not defined anyway.
+/*
+ * Manually set up DDR parameters
+ */
+#define CONFIG_DDR_II
+#define CONFIG_SYS_DDR_SIZE 2048 /* MB */
Do you use get_ram_size() for auto-sizing?
+#if (CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE)
+#define CONFIG_SYS_RAMBOOT
+#else
+#undef CONFIG_SYS_RAMBOOT
+#endif
Please do not #undef what is not defined - please fix globally.
+/*
+ * Initial RAM Base Address Setup
+ */
+#define CONFIG_SYS_INIT_RAM_LOCK 1
+#define CONFIG_SYS_INIT_RAM_ADDR 0xE600 /* Initial RAM address */
+#define CONFIG_SYS_INIT_RAM_END 0x1000 /* End of used area in RAM */
+#define CONFIG_SYS_GBL_DATA_SIZE 0x100 /* num bytes initial data */
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END -
CONFIG_SYS_GBL_DATA_SIZE)
Line too long. please fix globally.
...
+#ifndef CONFIG_SYS_RAMBOOT
...
+#else /* CFG_RAMBOOT */
...
+#endif /* CFG_RAMBOOT */
CFG_RAMBOOT ??? Seems this needs cleanup.
+#if defined(CFG_RAMBOOT)
+#undef CONFIG_CMD_SAVEENV
+#undef CONFIG_CMD_LOADS
Why?
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ CONFIG_KM_DEF_ENV \
+ CONFIG_KM_DEF_ROOTPATH
\
+ dtt_bus=pca9547:70:a\0\
+ EEprom_ivm=pca9547:70:9\0 \
+ newenv= \
+ prot off 0xF00C +0x4\
+ era 0xF00C +0x4\0 \
+ unlock=yes\0 \
+
Indentation by TAB only. Please fix globally.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Nobody goes to that restaurant anymore. It's too crowded.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] keymile: rework headerfiles for keymile boards
Dear Kim, In message 20100415172711.a7cd388a.kim.phill...@freescale.com you wrote: since 3 of these 4 patches are in the mpc83xx domain, I went ahead and applied 1-4/4 and pushed to u-boot-mpc83xx.git. Sorry for being slow with the review. I'm afraid I have to ask you to undo this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I object to intellect without discipline; I object to power without constructive purpose. -- Spock, The Squire of Gothos, stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] compiling u-boot failed for TI Davinci DM355 EVM (davinci_dm355evm_config)
Dear Mohamed Thalib H, In message 4bd028a9.2020...@e-consystems.com you wrote: I tried to compile the u-boot-2009.11 and u-boot-2010.03 for TI Davinci DM355 EVM (davinci_dm355evm_config) board but it ended up with the following error. could some one please help me in finding where exaclty the problem is. the log is as below for u-boot-2009.11 ... /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ld: /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5tl-montavista-linuxeabi/3.4.3/libgcc.a(_udivsi3.oS): warning: duplicate section `.note.gnu.arm.ident' has different contents Looks like a problem with MV's tool chain to me. Please contact MontaVista technical support and ask them for help. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: remove EP1C20, EP1S10, EP1S40 boards
Hi Thomas, Thomas Chou wrote: The example configuration files of nios2-generic board can generated binary to run on the EP1C20, EP1S10, and EP1S40 boards. So the three boards can be removed. With nios2-generic approach, the fpga parameter header file can be generated from hardware designs using tools. Porting u-boot for What tools are you referring to? nios2 boards is simplified. Vendors can supply their fpga parameter file or patches to add a new nios2-generic board instance. There is Support for several Altera nios2 boards has been available in u-boot for at least four years. To date, this vendor has offered no support whatsoever, either through patches, files, consultation or otherwise. Is there any reason you believe this is likely to change? no need to include other boards support for nios2 in the u-boot mainline. I'm not convinced that this is true. Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] video: add support for display controller in MB86R0x SoCs
Dear Matthias Weisser,
In message 1271932257-14618-3-git-send-email-weiss...@arcor.de you wrote:
This patch adds support for the display controller in
the MB86R0x SoCs.
Signed-off-by: Matthias Weisser weiss...@arcor.de
...
+ pGD-memSize = VIDEO_MEM_SIZE;
+ pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;
Please pay attention to the global memory map requirements. PRAM might
go first.
+ writel(dcm1, dspBase[i] + GC_DCM1);
+ writel(dcm2, dspBase[i] + GC_DCM2);
+ writel(dcm3, dspBase[i] + GC_DCM3);
+
+ writew(htp, dspBase[i] + GC_HTP);
+ writew(hdp, dspBase[i] + GC_HDP);
+ writew(hdb, dspBase[i] + GC_HDB);
+ writew(hsp, dspBase[i] + GC_HSP);
+ writeb(hsw, dspBase[i] + GC_HSW);
+
+ writeb(vsw, dspBase[i] + GC_VSW);
+ writew(vtr, dspBase[i] + GC_VTR);
+ writew(vsp, dspBase[i] + GC_VSP);
+ writew(vdp, dspBase[i] + GC_VDP);
+
+ writel(l2m, dspBase[i] + GC_L2M);
+ writel(l2em, dspBase[i] + GC_L2EM);
+ writel(l2oa0, dspBase[i] + GC_L2OA0);
+ writel(l2da0, dspBase[i] + GC_L2DA0);
+ writel(l2oa1, dspBase[i] + GC_L2OA1);
+ writel(l2da1, dspBase[i] + GC_L2DA1);
+ writew(l2dx, dspBase[i] + GC_L2DX);
+ writew(l2dy, dspBase[i] + GC_L2DY);
+ writew(l2wx, dspBase[i] + GC_L2WX);
+ writew(l2wy, dspBase[i] + GC_L2WY);
+ writew(l2ww, dspBase[i] + GC_L2WW);
+ writew(l2wh, dspBase[i] + GC_L2WH);
+
+ writel(dcm1 | (1 18) | (1 31), dspBase[i] + GC_DCM1);
Please use a C struct instead.
+/*
+ * Set a RGB color in the LUT
+ */
+void video_set_lut(unsigned int index, unsigned char r,
+ unsigned char g, unsigned char b)
+{
+
+}
Code seems to be missing?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The more we disagree, the more chance there is that at least one of
us is right.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: Add support for jadecpu board based on MB86R01 SoC
Dear Matthias Weisser, In message 1271932257-14618-4-git-send-email-weiss...@arcor.de you wrote: This patch adds support for the jadecpu board using the MB86R01 'Jade' SoC from Fujitsu. Signed-off-by: Matthias Weisser weiss...@arcor.de --- MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/syteco/jadecpu/Makefile| 55 +++ board/syteco/jadecpu/config.mk |1 + board/syteco/jadecpu/jadecpu.c | 198 board/syteco/jadecpu/lowlevel_init.S | 279 ++ common/serial.c |3 +- include/configs/jadecpu.h| 189 +++ include/serial.h |3 +- tools/Makefile |3 + tools/logos/syteco.bmp | Bin 0 - 11414 bytes 12 files changed, 737 insertions(+), 2 deletions(-) create mode 100644 board/syteco/jadecpu/Makefile create mode 100644 board/syteco/jadecpu/config.mk create mode 100644 board/syteco/jadecpu/jadecpu.c create mode 100644 board/syteco/jadecpu/lowlevel_init.S create mode 100644 include/configs/jadecpu.h create mode 100644 tools/logos/syteco.bmp diff --git a/MAINTAINERS b/MAINTAINERS index 04c8730..ac0ed62 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -776,6 +776,10 @@ Prafulla Wadaskar prafu...@marvell.com rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) +Matthias Weisser matthias.weis...@graf-syteco.de + + jadecpu ARM926EJS (MB86R01 SoC) + Richard Woodruff r-woodru...@ti.com omap2420h4 ARM1136EJS diff --git a/MAKEALL b/MAKEALL index fb1f7a3..5ee9678 100755 --- a/MAKEALL +++ b/MAKEALL @@ -561,6 +561,7 @@ LIST_ARM9= \ edb9315 \ edb9315a\ imx27lite \ + jadecpu \ lpd7a400\ mv88f6281gtw_ge \ mx1ads \ diff --git a/Makefile b/Makefile index 0381c81..4fdd216 100644 --- a/Makefile +++ b/Makefile @@ -2834,6 +2834,9 @@ CPU9260_config : unconfig @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91 +jadecpu_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs jadecpu syteco mb86r0x + meesc_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 diff --git a/board/syteco/jadecpu/Makefile b/board/syteco/jadecpu/Makefile new file mode 100644 index 000..87d2234 --- /dev/null +++ b/board/syteco/jadecpu/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.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 $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS-y += jadecpu.o +SOBJS:= lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(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/syteco/jadecpu/config.mk b/board/syteco/jadecpu/config.mk new file mode 100644 index 000..c661f0b --- /dev/null +++ b/board/syteco/jadecpu/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x4600 diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c new file mode 100644 index 000..ecc6742 --- /dev/null +++ b/board/syteco/jadecpu/jadecpu.c @@ -0,0 +1,198 @@ +/* + * (c) 2010 Graf-Syteco,
Re: [U-Boot] [PATCH 2/3] video: add support for display controller in MB86R0x SoCs
Am 22.04.2010 14:41, schrieb Wolfgang Denk:
Dear Matthias Weisser,
In message1271932257-14618-3-git-send-email-weiss...@arcor.de you wrote:
This patch adds support for the display controller in
the MB86R0x SoCs.
Signed-off-by: Matthias Weisserweiss...@arcor.de
...
+pGD-memSize = VIDEO_MEM_SIZE;
+pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;
Please pay attention to the global memory map requirements. PRAM might
go first.
+writel(dcm1, dspBase[i] + GC_DCM1);
+writel(dcm2, dspBase[i] + GC_DCM2);
+writel(dcm3, dspBase[i] + GC_DCM3);
+
+writew(htp, dspBase[i] + GC_HTP);
+writew(hdp, dspBase[i] + GC_HDP);
+writew(hdb, dspBase[i] + GC_HDB);
+writew(hsp, dspBase[i] + GC_HSP);
+writeb(hsw, dspBase[i] + GC_HSW);
+
+writeb(vsw, dspBase[i] + GC_VSW);
+writew(vtr, dspBase[i] + GC_VTR);
+writew(vsp, dspBase[i] + GC_VSP);
+writew(vdp, dspBase[i] + GC_VDP);
+
+writel(l2m, dspBase[i] + GC_L2M);
+writel(l2em, dspBase[i] + GC_L2EM);
+writel(l2oa0, dspBase[i] + GC_L2OA0);
+writel(l2da0, dspBase[i] + GC_L2DA0);
+writel(l2oa1, dspBase[i] + GC_L2OA1);
+writel(l2da1, dspBase[i] + GC_L2DA1);
+writew(l2dx, dspBase[i] + GC_L2DX);
+writew(l2dy, dspBase[i] + GC_L2DY);
+writew(l2wx, dspBase[i] + GC_L2WX);
+writew(l2wy, dspBase[i] + GC_L2WY);
+writew(l2ww, dspBase[i] + GC_L2WW);
+writew(l2wh, dspBase[i] + GC_L2WH);
+
+writel(dcm1 | (1 18) | (1 31), dspBase[i] + GC_DCM1);
Please use a C struct instead.
This driver is mainly copied from mb862xx (sharing the header as offsets
are the same) and that was the approach used there. I will add the
structures and use them.
+/*
+ * Set a RGB color in the LUT
+ */
+void video_set_lut(unsigned int index, unsigned char r,
+unsigned char g, unsigned char b)
+{
+
+}
Code seems to be missing?
The driver doesn't support palletized color format at the moment but
removing this function leads to a linker error.
Maybe we should add a config option to disable palletized color format
or add a weak function somewhere. Maybe Anatolij can comment on this
issue also.
Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: Add support for jadecpu board based on MB86R01 SoC
Am 22.04.2010 14:51, schrieb Wolfgang Denk:
+if ((in_word 0xC0) == 0xC0) {
+setenv(stdin, serial);
+setenv(stdout, serial);
+setenv(stderr, serial);
+setenv(bootdelay, 10);
+} else if ((in_word 0xC0) != 0) {
+setenv(stdout, vga);
+setenv(bootcmd, mw.l 0x4000 0 1024; usb start;
+fatls usb 0; fatload usb 0 0x4000 mcq5resq.bin;
+bootelf 0x4000; bootelf 0x1008);
+setenv(bootdelay, 5);
I consider such mandatory settings of behaviour-critical variables as
bootcmd and bootdelay bad style. I recommend to use oither
variables instead, and to use these as defaults, so the user still has
a choice to define his own bootcmd which does not get overwritten at
each boot.
OK. I think this will be the approach you mentioned:
setenv bootcmd '${gs_bootcmd}'
setenv gs_bootcmd bootelf 0x...
Is the redirection of the console OK as it is done in the above code?
Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: Add support for jadecpu board based on MB86R01 SoC
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
In message 4bd04c64.20...@arcor.de you wrote:
Am 22.04.2010 14:51, schrieb Wolfgang Denk:
+ if ((in_word 0xC0) == 0xC0) {
+ setenv(stdin, serial);
+ setenv(stdout, serial);
+ setenv(stderr, serial);
+ setenv(bootdelay, 10);
+ } else if ((in_word 0xC0) != 0) {
+ setenv(stdout, vga);
+ setenv(bootcmd, mw.l 0x4000 0 1024; usb start;
+ fatls usb 0; fatload usb 0 0x4000 mcq5resq.bin;
+ bootelf 0x4000; bootelf 0x1008);
+ setenv(bootdelay, 5);
I consider such mandatory settings of behaviour-critical variables as
bootcmd and bootdelay bad style. I recommend to use oither
variables instead, and to use these as defaults, so the user still has
a choice to define his own bootcmd which does not get overwritten at
each boot.
OK. I think this will be the approach you mentioned:
setenv bootcmd '${gs_bootcmd}'
setenv gs_bootcmd bootelf 0x...
Right.
Is the redirection of the console OK as it is done in the above code?
I have to admit that I don't exactly like it (because you will never
know which exact state the system is in, especially if it's not
working - I prefer static states and manual, permanent switching),
but I will not object here.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An organization dries up if you don't challenge it with growth.
- Mark Shepherd, former President and CEO of Texas Instruments
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] SPEAr : Configuring FSMC driver for NAND interface
Vipin KUMAR wrote: On 4/21/2010 10:32 PM, Scott Wood wrote: On Wed, Apr 21, 2010 at 01:24:37PM +0530, Vipin KUMAR wrote: diff --git a/board/spear/spear310/spear310.c b/board/spear/spear310/spear310.c index 1207709..3ac62d1 100644 --- a/board/spear/spear310/spear310.c +++ b/board/spear/spear310/spear310.c @@ -29,7 +29,8 @@ #include asm/arch/hardware.h #include asm/arch/spr_defs.h #include asm/arch/spr_misc.h -#include asm/arch/spr_nand.h + +int fsmc_nand_init(struct nand_chip *nand); Put it in a header file. Should I put it in a platform specific header file. That's where I was confused Put it in fsmc_nand.h, and move that file to an include directory. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/17] SPEAr : FSMC driver support added
Vipin KUMAR wrote:
On 4/21/2010 10:32 PM, Scott Wood wrote:
On Wed, Apr 21, 2010 at 01:24:36PM +0530, Vipin KUMAR wrote:
+#if defined(CONFIG_BOARD_NAND_LP)
CONFIG_SYS_FSMC_NAND_LP, CONFIG_SYS_FSMC_NAND_16BIT, etc.
Incomplete comment :)
Are these deprecated
CONFIG symbols that are hardware parameters rather than user-tweakable
config go in the CONFIG_SYS namespace (see Software Configuration in
README).
I think it should also be an FSMC-specific parameter, not something that
looks universal.
+#ifndef __FSMC_NAND_H__
+#define __FSMC_NAND_H__
+
+struct fsmc_regs {
+ u8 reserved_1[0x40];
+ u32 genmemctrl_pc; /* 0x40 */
+ u32 genmemctrl_sts; /* 0x44 */
+ u32 genmemctrl_comm;/* 0x48 */
+ u32 genmemctrl_attrib; /* 0x4c */
+ u32 genmemctrl_ioata; /* 0x50 */
+ u32 genmemctrl_ecc1;/* 0x54 */
+ u32 genmemctrl_ecc2;/* 0x58 */
+ u32 genmemctrl_ecc3;/* 0x5c */
+ u8 reserved_2[0xfe0 - 0x60];
+ u32 genmemctrl_peripid0;/* 0xfe0 */
+ u32 genmemctrl_peripid1;/* 0xfe4 */
+ u32 genmemctrl_peripid2;/* 0xfe8 */
+ u32 genmemctrl_peripid3;/* 0xfec */
+ u32 genmemctrl_pcellid0;/* 0xff0 */
+ u32 genmemctrl_pcellid1;/* 0xff4 */
+ u32 genmemctrl_pcellid2;/* 0xff8 */
+ u32 genmemctrl_pcellid3;/* 0xffc */
+};
Is the genmemctrl_ prefix really needed?
The peripheral's registers are named like these so I kept it.
The struct name takes that role here; hardware documentation doesn't
have the benefit of that.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] keymile: rework headerfiles for keymile boards
On Thu, 22 Apr 2010 13:21:18 +0200 Wolfgang Denk w...@denx.de wrote: Dear Kim, In message 20100415172711.a7cd388a.kim.phill...@freescale.com you wrote: since 3 of these 4 patches are in the mpc83xx domain, I went ahead and applied 1-4/4 and pushed to u-boot-mpc83xx.git. Sorry for being slow with the review. I'm afraid I have to ask you to undo this. no worries, Wolfgang - thanks for the thorough review. I'll rebase and wait for Heiko's repost. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x driver frame alignment patch
21.04.2010 23:52, Mike Frysinger wrote: Wrong alignment in smc911x driver when reading a frame from fifo. Neither smc911x chip nor U-Boot doesn't use IP-alignment, so we don't need to add anything here. I know you use this driver a lot. Please comment on this patch. i really havent a clue what this change is doing, and the changelog doesnt make much sense to me. too many negatives perhaps ... SMSC911x chips has alignment function to allow frame payload data (which comes after 14-bytes ethernet header) to be aligned at some boundary when reading it from fifo (usually - 4 bytes boundary). This is done by inserting fake zeros bytes BEFORE actual frame data when reading from SMSC's fifo. This function controlled by RX_CFG register. There are bits that represents amount of fake bytes to be inserted. Linux uses alignment of 4 bytes. Ethernet frame header is 14 bytes long, so we need to add 2 fake bytes to get payload data aligned at 4-bytes boundary. Linux driver does this by adding IP_ALIGNMENT constant (defined at skb.h) when calculating fifo data length. But all network subsystem of Linux uses this constant too when calculating different offsets. But u-boot does not use any packet data alignment, so we don't need to add anything when calculating fifo data length. Moreover, driver zeros the RX_CFG register just one line up, so chip does not insert any fake data. After calculating data length we always got 1 more word to read. So, at almost every packet read we get an underflow condition at fifo and possible corruption of data. Especially at continuous transfers, such as tftp. Just after removing this magic addition, I've got tftp transfer speed as it aught to be at 100Mbps. It was really slow before. Sorry for my english, I'm just a bad russian boy %) -- WBR, Valentin CJSC NII STT, Russia, Smolensk http://www.niistt.ru smime.p7s Description: S/MIME Cryptographic Signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x driver frame alignment patch
On Thursday 22 April 2010 15:12:19 Valentin Yakovenkov wrote: 21.04.2010 23:52, Mike Frysinger wrote: Wrong alignment in smc911x driver when reading a frame from fifo. Neither smc911x chip nor U-Boot doesn't use IP-alignment, so we don't need to add anything here. I know you use this driver a lot. Please comment on this patch. i really havent a clue what this change is doing, and the changelog doesnt make much sense to me. too many negatives perhaps ... SMSC911x chips has alignment function to allow frame payload data (which comes after 14-bytes ethernet header) to be aligned at some boundary when reading it from fifo (usually - 4 bytes boundary). This is done by inserting fake zeros bytes BEFORE actual frame data when reading from SMSC's fifo. This function controlled by RX_CFG register. There are bits that represents amount of fake bytes to be inserted. Linux uses alignment of 4 bytes. Ethernet frame header is 14 bytes long, so we need to add 2 fake bytes to get payload data aligned at 4-bytes boundary. Linux driver does this by adding IP_ALIGNMENT constant (defined at skb.h) when calculating fifo data length. But all network subsystem of Linux uses this constant too when calculating different offsets. But u-boot does not use any packet data alignment, so we don't need to add anything when calculating fifo data length. Moreover, driver zeros the RX_CFG register just one line up, so chip does not insert any fake data. After calculating data length we always got 1 more word to read. So, at almost every packet read we get an underflow condition at fifo and possible corruption of data. Especially at continuous transfers, such as tftp. Just after removing this magic addition, I've got tftp transfer speed as it aught to be at 100Mbps. It was really slow before. i would send the patch again with this info in the changelog. however, at least on my board, i see no speed difference with this patch. i get about 2.8MiB/s on my bf548-ezkit with and without your change. so, it doesnt break anything that i can see, nor have i been experiencing any problems before, so i dont have a problem with the patch being merged (once a better changelog is added). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x driver frame alignment patch
22.04.2010 23:43, Mike Frysinger wrote: i would send the patch again with this info in the changelog. however, at least on my board, i see no speed difference with this patch. i get about 2.8MiB/s on my bf548-ezkit with and without your change. so, it doesnt break anything that i can see, nor have i been experiencing any problems before, so i dont have a problem with the patch being merged (once a better changelog is added). I think it's because of we're using Byte Packing enabled and 32-bit reads, but smsc9221 bus is 16-bit wide. bf548-ezkit config defines CONFIG_SMC911X_16_BIT, but ours - CONFIG_SMC911X_32_BIT. This is the only difference i've found. -- WBR, Valentin CJSC NII STT, Russia, Smolensk http://www.niistt.ru smime.p7s Description: S/MIME Cryptographic Signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/6] MX: RTC13783 uses general function to access PMIC
Hi On 04/19/2010 11:04 PM, Stefano Babic wrote: The RTC is part of the Freescale's PMIC controller. Use general function to access to PMIC internal registers. Signed-off-by: Stefano Babic sba...@denx.de --- Changes since last version: configuration of the RTC must be updated for the boards that are using it. I've compiled and tested this on i.MX31 Litekit and it seems to work. I suspect it works on the PDK board as well but I haven't actually tried that yet. Regards, Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x driver frame alignment patch
Valentin, On Thu, Apr 22, 2010 at 12:53 PM, Valentin Yakovenkov yakoven...@niistt.ruwrote: 22.04.2010 23:43, Mike Frysinger wrote: i would send the patch again with this info in the changelog. however, at least on my board, i see no speed difference with this patch. i get about 2.8MiB/s on my bf548-ezkit with and without your change. so, it doesnt break anything that i can see, nor have i been experiencing any problems before, so i dont have a problem with the patch being merged (once a better changelog is added). I think it's because of we're using Byte Packing enabled and 32-bit reads, but smsc9221 bus is 16-bit wide. bf548-ezkit config defines CONFIG_SMC911X_16_BIT, but ours - CONFIG_SMC911X_32_BIT. This is the only difference i've found. Thanks for the explanation and test results. Please re-submit with this info in the changelog and I'll pull it in. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] mpc83xx: use A nomenclature only on mpc834x and mpc836x families
On Thu, 15 Apr 2010 17:36:02 -0500 Kim Phillips kim.phill...@freescale.com wrote: marketing didn't extend their postpend-with-an-A naming strategy on rev.2's and higher beyond the first two 83xx families. This patch stops us from misreporting we're running e.g., on an MPC8313EA, when such a name doesn't exist. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- applied 1-2/3, and v2 of the 3rd patch to (the newly rebased) u-boot-mpc83xx. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: allow link script overriding from boards
Applied. Thanks. --Scott Thomas Chou wrote: This patch allow boards to override the default link script. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- arch/nios2/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/nios2/config.mk b/arch/nios2/config.mk index f455982..8e5d6ef 100644 --- a/arch/nios2/config.mk +++ b/arch/nios2/config.mk @@ -29,4 +29,4 @@ STANDALONE_LOAD_ADDR = 0x0200 -L $(gcclibdir) PLATFORM_CPPFLAGS += -DCONFIG_NIOS2 -D__NIOS2__ PLATFORM_CPPFLAGS += -ffixed-r15 -G0 -LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds +LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] nios2: add altera cf reset
Applied. Thanks.
--Scott
Thomas Chou wrote:
This patch toggles power to reset the cf card.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
more checkpatch.pl fixes
board/altera/common/cfide.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644 board/altera/common/cfide.c
diff --git a/board/altera/common/cfide.c b/board/altera/common/cfide.c
new file mode 100644
index 000..40d6a12
--- /dev/null
+++ b/board/altera/common/cfide.c
@@ -0,0 +1,33 @@
+/*
+ * Altera CF drvier
+ *
+ * (C) Copyright 2010, Thomas Chou tho...@wytron.com.tw
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include common.h
+#include asm/io.h
+
+#if defined(CONFIG_IDE_RESET) defined(CONFIG_SYS_CF_CTL_BASE)
+/* ide_set_reset for Altera CF interface */
+#define ALTERA_CF_CTL_STATUS 0
+#define ALTERA_CF_IDE_CTL4
+#define ALTERA_CF_CTL_STATUS_PRESENT_MSK (0x1)
+#define ALTERA_CF_CTL_STATUS_POWER_MSK (0x2)
+#define ALTERA_CF_CTL_STATUS_RESET_MSK (0x4)
+#define ALTERA_CF_CTL_STATUS_IRQ_EN_MSK (0x8)
+#define ALTERA_CF_IDE_CTL_IRQ_EN_MSK (0x1)
+
+void ide_set_reset(int idereset)
+{
+ int i;
+ writel(idereset ? ALTERA_CF_CTL_STATUS_RESET_MSK :
+ALTERA_CF_CTL_STATUS_POWER_MSK,
+CONFIG_SYS_CF_CTL_BASE + ALTERA_CF_CTL_STATUS);
+ /* wait 500 ms for power to stabilize */
+ for (i = 0; i 500; i++)
+ udelay(1000);
+}
+#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] nios2: add dma_alloc_coherent
Applied. Thanks.
--Scott
Thomas Chou wrote:
This function return cache-line aligned allocation which is mapped
to uncached io region.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
arch dir reorganized.
arch/nios2/include/asm/dma-mapping.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 arch/nios2/include/asm/dma-mapping.h
diff --git a/arch/nios2/include/asm/dma-mapping.h
b/arch/nios2/include/asm/dma-mapping.h
new file mode 100644
index 000..1350e3b
--- /dev/null
+++ b/arch/nios2/include/asm/dma-mapping.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_NIOS2_DMA_MAPPING_H
+#define __ASM_NIOS2_DMA_MAPPING_H
+
+/* dma_alloc_coherent() return cache-line aligned allocation which is mapped
+ * to uncached io region.
+ *
+ * IO_REGION_BASE should be defined in board config header file
+ * 0x8000 for nommu, 0xe000 for mmu
+ */
+
+static inline void *dma_alloc_coherent(size_t len, unsigned long *handle)
+{
+ void *addr = malloc(len + CONFIG_SYS_DCACHELINE_SIZE);
+ if (!addr)
+ return 0;
+ flush_dcache((unsigned long)addr, len + CONFIG_SYS_DCACHELINE_SIZE);
+ *handle = ((unsigned long)addr +
+(CONFIG_SYS_DCACHELINE_SIZE - 1))
+ ~(CONFIG_SYS_DCACHELINE_SIZE - 1) ~(IO_REGION_BASE);
+ return (void *)(*handle | IO_REGION_BASE);
+}
+
+#endif /* __ASM_NIOS2_DMA_MAPPING_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios] Pull Request
Wolfgang Denk wrote: Um... Scott, I have a few other NIOS2 related patches in my queue that seem to be pending, could you please have a look at these? 03/25 Thomas Chou [PATCH v2] nios2: add dma_alloc_coherent with asm-nios2/dma-mapping.h Applied resubmission: 04/16 Thomas Chou [PATCH v3] nios2: add dma_alloc_coherent 03/27 Thomas Chou [PATCH] nios2: add 64 bits swab support in asm-nios2/byteorder.h Applied resubmission: 04/17 Thomas Chou[PATCH v2] nios2: add 64 bits swab support 03/27 Thomas Chou [PATCH] nios2: add gpio based status led driver Resubmitted as a misc patch: 04/20 Thomas Chou [PATCH v2] misc: add gpio based status led driver 03/31 Thomas Chou [PATCH v5] nios2: add altera cf reset Applied. 04/17 Thomas Chou [PATCH] nios2: allow link script overriding from boards Applied. 04/17 Thomas Chou [PATCH 1/5 v3] nios2: add nios2-generic board Pending. Resubmitted as: 04/20 Thomas Chou [PATCH 1/5 v4] nios2: add nios2-generic board Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91sam9g45ekes SDHC/MMC
Hi Henry U-Boot Community, I've been experiencing the same errors and frustration you have. So I've been looking at this code and these patch sets for a day or two now. I've done that in conjunction with reading the SD card spec: http://www.sdcard.org/developers/tech/sdcard/pls/ I've come to the conclusion that this code as it stands will not work with any card that conforms to the SD Physical Layer Simplified Specification Version 2.0. This includes all SDHC cards and some non-HC cards that conform to version 2.0. I have a few 1GB cards that work just fine with the atmel_mci.c code on a 'G45 as it was in rev 95c44ec485b46ffb43dbdaa299f1491a500fdadf . If your SD card is newer, you'll see in the for loop in sd_init_card in atmel_mci.c time out. In the 2.0 spec, you need to perform a CMD8 (SEND_IF_COND) first to see if your card is a 2.0 card. In CMD8 you tell the card the voltages you support and if you support HC cards. Once you send it the right data there, then ACMD41 will not have its BUSY bit set. That's all well and good, but additionally the CSD register is in a new format and that needs updating before any of this will work. In another post, I will be more talk of the mmc/sd code and taking it forward. Rob On Mon, Apr 12, 2010 at 6:55 AM, Henry Súcart henry.suc...@gmail.com wrote: Hi Ulf, Thanks for the reply. I applied your patches but I still can't get it to read the SD card Without the SD card: U-Boot mmc init 0 mmc: command 55 failed (status: 0x0c100025) mmc: command 1 failed (status: 0x0c100025) No MMC card found With the SD card: U-Boot mmc init 0 mmc: command 1 failed (status: 0x0c100025) No MMC card found I'm not sure what's going on. On Tue, Apr 6, 2010 at 5:57 AM, Ulf Samuelsson ulf.samuels...@atmel.comwrote: Henry Súcart skrev: Hi, I've been trying to get an SD card working with an at91sam9g45ek-es board. I read a couple of threads in the archive and ended up doing this: I have booted the AT91SAM9G45EKES (Actually the AT91SAM9M10EKES, but it is almost the same) from SD-Card for the last month. The patchset for 2009.11 is available for testing in my private git branch on www.openembedded.org: origin/ulf/linux-2.6.30-20100317 I came to the conclusion that the atmel MCI driver (written for the big endian AVR32) has significant byte sex problems. BR Ulf Samuelsson. I applied these patches: http://lists.denx.de/pipermail/u-boot/2009-August/059595.html http://lists.denx.de/pipermail/u-boot/2009-September/060053.html http://lists.denx.de/pipermail/u-boot/2009-September/060243.html Added these #define's to include/configs/at91sam9m10g45ek.h: #define CONFIG_CMD_EXT2 1 #define CONFIG_CMD_FAT 1 #define CONFIG_CMD_MMC 1 #define CONFIG_MMC 1 #define CONFIG_ATMEL_MCI 1 Finally, I added this to the board init function: #ifdef CONFIG_ATMEL_MCI at91_mci0_hw_init(0, 4); #endif When I try it out this is what I get: U-Boot mmc init 0 mmc: clock 15 too low; setting CLKDIV to 255 mmc: command 1 failed (status: 0x0c100025) No MMC card found Am I doing something wrong? Any help is appreciated, Henry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Atmel SD/MMC Support (including SDHC)
Greetings, I was wondering if there is anyone working on porting the mmc.c library to the Atmel AT91 (or AVR32) platforms? As it stands now the atmel_mci.c has its own initialization and structures. It is largely legacy code and there is no support for the SD Physical Layer Specification version 2.00. If anyone is working on it I'm happy to help. If no one is working on it, I start coding tomorrow, does anyone want to help? Cheers, Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] altera_jtag_uart: bypass when no jtag connection
Applied. Thanks.
--Scott
Thomas Chou wrote:
This patch adds an option to bypass output waiting when there
is no jtag connection. This allows the jtag uart work similar
to a serial uart, ie, boot even without connection.
This option is enabled with,
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
follow the Fix outx/writex parameter order in io.h patch from Scott.
drivers/serial/altera_jtag_uart.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/altera_jtag_uart.c
b/drivers/serial/altera_jtag_uart.c
index fb28aa9..2980e4d 100644
--- a/drivers/serial/altera_jtag_uart.c
+++ b/drivers/serial/altera_jtag_uart.c
@@ -38,8 +38,16 @@ int serial_init( void ) { return(0);}
void serial_putc (char c)
{
- while (NIOS_JTAG_WSPACE ( readl (jtag-control)) == 0)
- WATCHDOG_RESET ();
+ while (1) {
+ unsigned st = readl(jtag-control);
+ if (NIOS_JTAG_WSPACE(st))
+ break;
+#ifdef CONFIG_ALTERA_JTAG_UART_BYPASS
+ if (!(st NIOS_JTAG_AC)) /* no connection */
+ return;
+#endif
+ WATCHDOG_RESET();
+ }
writel ((unsigned char)c, jtag-data);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] support for spansion s29gl-p flash?
Hello folks, Does the latest u-boot include support for these flash families: - Spansion S29GL-P MirrorBit flash family or - Numonyx Axcell M29EW Appreciate your help. thanks, aditya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: consolidate reset initialization
Applied. Thanks. --Scott Thomas Chou wrote: Global interrupt should be disabled from the beginning. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- arch/nios2/cpu/start.S |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S index 31cd5b0..d1016ea 100644 --- a/arch/nios2/cpu/start.S +++ b/arch/nios2/cpu/start.S @@ -34,6 +34,7 @@ .global _start _start: + wrctl status, r0 /* Disable interrupts */ /* ICACHE INIT -- only the icache line at the reset address * is invalidated at reset. So the init must stay within * the cache line size (8 words). If GERMS is used, we'll @@ -43,10 +44,9 @@ _start: ori r4, r0, %lo(CONFIG_SYS_ICACHELINE_SIZE) movhi r5, %hi(CONFIG_SYS_ICACHE_SIZE) ori r5, r5, %lo(CONFIG_SYS_ICACHE_SIZE) - mov r6, r0 -0: initi r6 - add r6, r6, r4 - bltur6, r5, 0b +0: initi r5 + sub r5, r5, r4 + bgt r5, r0, 0b br _except_end /* Skip the tramp */ /* EXCEPTION TRAMPOLINE -- the following gets copied @@ -62,7 +62,6 @@ _except_end: /* INTERRUPTS -- for now, all interrupts masked and globally * disabled. */ - wrctl status, r0 /* Disable interrupts */ wrctl ienable, r0 /* All disabled */ /* DCACHE INIT -- if dcache not implemented, initd behaves as ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5 v3] nios2: fix no flash, add nand and mmc init in board.c
Applied. Thanks. --Scott Thomas Chou wrote: This patch fixes error when CONFIG_SYS_NO_FLASH. And adds nand flash and mmc initialization, which should go before env initialization. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v3 include mmc.h and nand.h. v2 arch dir reorganized. arch/nios2/lib/board.c | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/nios2/lib/board.c b/arch/nios2/lib/board.c index 8ec66a3..f83e691 100644 --- a/arch/nios2/lib/board.c +++ b/arch/nios2/lib/board.c @@ -28,6 +28,7 @@ #include stdio_dev.h #include watchdog.h #include malloc.h +#include mmc.h #include net.h #ifdef CONFIG_STATUS_LED #include status_led.h @@ -35,6 +36,9 @@ #if defined(CONFIG_SYS_NIOS_EPCSBASE) #include nios2-epcs.h #endif +#ifdef CONFIG_CMD_NAND +#include nand.h/* cannot even include nand.h if it isnt configured */ +#endif DECLARE_GLOBAL_DATA_PTR; @@ -100,7 +104,9 @@ void board_init (void) bd = gd-bd; bd-bi_memstart = CONFIG_SYS_SDRAM_BASE; bd-bi_memsize = CONFIG_SYS_SDRAM_SIZE; +#ifndef CONFIG_SYS_NO_FLASH bd-bi_flashstart = CONFIG_SYS_FLASH_BASE; +#endif #if defined(CONFIG_SYS_SRAM_BASE) defined(CONFIG_SYS_SRAM_SIZE) bd-bi_sramstart= CONFIG_SYS_SRAM_BASE; bd-bi_sramsize = CONFIG_SYS_SRAM_SIZE; @@ -119,8 +125,20 @@ void board_init (void) /* The Malloc area is immediately below the monitor copy in RAM */ mem_malloc_init(CONFIG_SYS_MALLOC_BASE, CONFIG_SYS_MALLOC_LEN); +#ifndef CONFIG_SYS_NO_FLASH WATCHDOG_RESET (); bd-bi_flashsize = flash_init(); +#endif + +#ifdef CONFIG_CMD_NAND + puts(NAND: ); + nand_init(); +#endif + +#ifdef CONFIG_GENERIC_MMC + puts(MMC: ); + mmc_initialize(bd); +#endif WATCHDOG_RESET (); env_relocate(); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: add generic mmc spi driver
This patch supports mmc/sd card with spi interface.
I have tested with sd and mmc cards. But there is still ocr issue
with SDHC.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
drivers/mmc/Makefile |1 +
drivers/mmc/mmc_spi.c | 252 +
2 files changed, 253 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/mmc_spi.c
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 1b8f5bd..d03eb47 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -31,6 +31,7 @@ LIB := $(obj)libmmc.a
COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
COBJS-$(CONFIG_ATMEL_MCI) += atmel_mci.o
COBJS-$(CONFIG_BFIN_SDH) += bfin_sdh.o
+COBJS-$(CONFIG_MMC_SPI) += mmc_spi.o
COBJS-$(CONFIG_OMAP3_MMC) += omap3_mmc.o
COBJS-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
COBJS-$(CONFIG_MXC_MMC) += mxcmmc.o
diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
new file mode 100644
index 000..76c5977
--- /dev/null
+++ b/drivers/mmc/mmc_spi.c
@@ -0,0 +1,252 @@
+/*
+ * generic mmc spi driver
+ *
+ * Copyright (C) 2010 Thomas Chou tho...@wytron.com.tw
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include malloc.h
+#include part.h
+#include mmc.h
+#include spi.h
+#include asm/errno.h
+
+#define CTOUT 0x10
+#define RTOUT 0x1
+#define WTOUT 0x1
+
+static uint mmc_spi_sendcmd(struct mmc *mmc, u8 cmdidx, u32 cmdarg)
+{
+ u8 cmdo[6];
+ u8 r1;
+ int i;
+ cmdo[0] = 0x40 + cmdidx;
+ cmdo[1] = cmdarg 24;
+ cmdo[2] = cmdarg 16;
+ cmdo[3] = cmdarg 8;
+ cmdo[4] = cmdarg;
+ cmdo[5] = 0x95; /* crc valid only for cmd00 */
+ spi_xfer(mmc-priv, 6 * 8, cmdo, NULL, SPI_XFER_BEGIN);
+ for (i = 0; i CTOUT; i++) {
+ spi_xfer(mmc-priv, 1 * 8, NULL, r1, 0);
+ if ((r1 0x80) == 0)
+ break;
+ }
+ debug(%s:cmd%d resp%d %x\n, __func__, cmdidx, i, r1);
+ return r1;
+}
+
+static uint mmc_spi_readdata(struct mmc *mmc, char *buf,
+ u32 bcnt, u32 bsize)
+{
+ u8 r1;
+ u8 crc[2];
+ int i;
+ while (bcnt--) {
+ for (i = 0; i RTOUT; i++) {
+ spi_xfer(mmc-priv, 1 * 8, NULL, r1, 0);
+ if (r1 != 0xff)
+ break;
+ }
+ debug(%s:tok%d %x\n, __func__, i, r1);
+ if (r1 == 0xfe) {
+ spi_xfer(mmc-priv, bsize * 8, NULL, buf, 0);
+ buf += bsize;
+ spi_xfer(mmc-priv, 2 * 8, NULL, crc, 0);
+ r1 = 0;
+ } else
+ break;
+ }
+ return r1;
+}
+
+static uint mmc_spi_writedata(struct mmc *mmc, const char *buf,
+ u32 bcnt, u32 bsize)
+{
+ u8 r1;
+ u8 tok[2] = { 0xff, 0xfe };
+ u8 crc[2];
+ int i;
+ while (bcnt--) {
+ spi_xfer(mmc-priv, 2 * 8, tok, NULL, 0);
+ spi_xfer(mmc-priv, bsize * 8, buf, NULL, 0);
+ buf += bsize;
+ spi_xfer(mmc-priv, 2 * 8, crc, NULL, 0);
+ spi_xfer(mmc-priv, 1 * 8, NULL, r1, 0);
+ if (r1 == 0x05) {
+ for (i = 0; i WTOUT; i++) {
+ spi_xfer(mmc-priv, 1 * 8, NULL, r1, 0);
+ if (r1 == 0xff) {
+ r1 = 0;
+ break;
+ }
+ }
+ if (i == WTOUT) {
+ debug(%s:wtout %x\n, __func__, r1);
+ r1 = 0x04;
+ break;
+ }
+ } else
+ break;
+ }
+ return r1;
+}
+
+static uint mmc_spi_writeblock(struct mmc *mmc, const char *buf,
+ u32 bcnt, u32 bsize)
+{
+ u8 r1;
+ u8 tok[2] = { 0xff, 0xfc };
+ u8 stop[2] = { 0xff, 0xfd };
+ u8 crc[2];
+ int i;
+ while (bcnt--) {
+ spi_xfer(mmc-priv, 2 * 8, tok, NULL, 0);
+ spi_xfer(mmc-priv, bsize * 8, buf, NULL, 0);
+ buf += bsize;
+ spi_xfer(mmc-priv, 2 * 8, crc, NULL, 0);
+ spi_xfer(mmc-priv, 1 * 8, NULL, r1, 0);
+ if (r1 == 0x05) {
+ for (i = 0; i WTOUT; i++) {
+ spi_xfer(mmc-priv, 1 * 8, NULL, r1, 0);
+ if (r1 == 0xff) {
+ r1 = 0;
+ break;
+ }
+ }
+ if (i == WTOUT) {
+ debug(%s:wtout %x\n, __func__, r1);
+ r1 = 0x04;
+
Re: [U-Boot] [PATCH] spi_mmc: set default spi bus
On Thursday 22 April 2010 01:16:34 Thomas Chou wrote: - slave = spi_setup_slave(0, CONFIG_SPI_MMC_DEFAULT_CS, + slave = spi_setup_slave( + CONFIG_SPI_MMC_DEFAULT_BUS, CONFIG_SPI_MMC_DEFAULT_CS, CONFIG_SPI_MMC_DEFAULT_SPEED, CONFIG_SPI_MMC_DEFAULT_MODE); seems this is an older version of the patch. ive merged your suggestion and i'll post the latest to the list again. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: new legacy MMC/SPI driver
From: Hans Eklund h...@rubico.se
Needs converting to generic MMC framework.
Signed-off-by: Hans Eklund h...@rubico.se
Signed-off-by: Cliff Cai cliff@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
drivers/mmc/Makefile |3 +
drivers/mmc/spi_mmc.c | 1119 +
2 files changed, 1122 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/spi_mmc.c
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 6fa04b8..1b8f5bd 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -23,6 +23,9 @@
include $(TOPDIR)/config.mk
+# stick it up here to avoid conflicts
+COBJS-$(CONFIG_SPI_MMC) += spi_mmc.o
+
LIB:= $(obj)libmmc.a
COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
diff --git a/drivers/mmc/spi_mmc.c b/drivers/mmc/spi_mmc.c
new file mode 100644
index 000..7ce9ce1
--- /dev/null
+++ b/drivers/mmc/spi_mmc.c
@@ -0,0 +1,1119 @@
+/*
+ * SPI-MMC/SD Protocol.
+ *
+ * Copyright (C) 2005-2007, Rubico AB (www.rubico.se)
+ *
+ * Developed as a part the CDT project C4 (www.cdt.ltu.se).
+ *
+ * Robert Selberg, rob...@rubico.se
+ * Hans Eklund, h...@rubico.se
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+/*
+ * TODO: Correct Multiple block read and write functions. Didnt have time
+ * to make them all failsafe. Will be done soon.
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include mmc.h
+
+enum {
+ MMC_INIT_TIMEOUT= 3,
+ MMC_COMMAND_TIMEOUT = 5000,
+ MMC_PROG_TIMEOUT= 50,
+ BUSY_BLOCK_LEN = 1,
+ BUSY_BLOCK_LEN_SHORT= 16,
+ MMC_SECTOR_SIZE = 512,
+ SD_PRE_CMD_ZEROS= 4,
+ SD_CLK_CNTRL= 2,
+ LOG_LEN = 16,
+ WRB_LEN = 256,
+
+/* Card command classes */
+
+/* Internal error codes */
+ ERR_SPI_TIMEOUT = 0xF1,
+ ERR_MMC_TIMEOUT = 0xF2,
+ ERR_MMC_PROG_TIMEOUT= 0xF3,
+ ERR_UNKNOWN_TOK = 0xF4,
+
+/* return values from functions */
+ RVAL_OK = 0,
+ RVAL_ERROR = 1,
+ RVAL_CRITICAL = 2,
+
+/* Format R1(b) response tokens (1 byte long) */
+ BUSY_TOKEN = 0x00,
+ R1_OK = 0x00,
+ R1_IDLE_STATE = 0x01,
+ R1_ERASE_STATE = 0x02,
+ R1_ILLEGAL_CMD = 0x04,
+ R1_COM_CRC_ERROR= 0x08,
+ R1_ERASE_SEQ_ERROR = 0x10,
+ R1_ADDRESS_ERROR= 0x20,
+ R1_PARAMETER_ERROR = 0x40,
+
+/* Format R2 response tokens (2 bytes long, first is same as R1 responses) */
+ R2_OK = 0x00,
+ R2_CARD_LOCKED = 0x01,
+ R2_WP_ERASE_SKIP= 0x02,
+ R2_LOCK_UNLOCK_CMD_FAIL = 0x02,
+ R2_ERROR= 0x04,
+ R2_CC_ERROR = 0x08,
+ R2_CARD_ECC_FAILED = 0x10,
+ R2_WP_VIOLATION = 0x20,
+ R2_ERASE_PARAM = 0x40,
+ R2_OUT_OF_RANGE = 0x80,
+ R2_CSD_OVERWRITE= 0x80,
+/* TODO: Format R3 response tokens */
+
+/* Data response tokens */
+ DR_MASK = 0x0F,
+ DR_ACCEPTED = 0x05,
+ DR_CRC_ERROR= 0x0B,
+ DR_WRITE_ERROR = 0x0D,
+
+/*
+ Data tokens (4 bytes to (N+3) bytes long), N is data block len
+ format of the Start Data Block Token
+*/
+ SBT_S_BLOCK_READ= 0xFE,
+ SBT_M_BLOCK_READ= 0xFE,
+ SBT_S_BLOCK_WRITE = 0xFE,
+ SBT_M_BLOCK_WRITE = 0xFC,
+ STT_M_BLOCK_WRITE = 0xFD,
+
+/* Data error tokens (1 byte long) */
+ DE_ERROR= 0x01,
+ DE_CC_ERROR = 0x02,
+ DE_CARD_ECC_FAILED = 0x04,
+ DE_OUT_OF_RANGE = 0x08,
+ DE_CARD_IS_LOCKED = 0x10,
+
+/* MMC/SD SPI mode commands */
+ GO_IDLE_STATE = 0,
+ SEND_OP_COND= 1,
+ SEND_CSD= 9,
+ SEND_CID= 10,
+ STOP_TRANSMISSION = 12,
+ SEND_STATUS = 13,
+ SET_BLOCKLEN= 16,
+ READ_SINGLE_BLOCK = 17,
+ READ_MULTIPLE_BLOCK = 18,
+ WRITE_BLOCK = 24,
+ WRITE_MULTIPLE_BLOCK= 25,
+ SD_SEND_OP_COND = 41,
+ APP_CMD = 55,
+};
+
+/* minimal local versions of CSD/CID structures,
+ somewhat ripped from linux MMC layer, the entire
+ CSD struct is larger and is not completley parsed
+*/
+struct cid_str {
+ unsigned intmanfid;
+ charprod_name[8];
+ unsigned intserial;
+ unsigned short oemid;
+ unsigned short year;
+ unsigned char hwrev;
+ unsigned char fwrev;
+ unsigned char month;
+};
+
+struct csd_str { /* __csd field
Re: [U-Boot] [PATCH] mmc: add generic mmc spi driver
On Thursday 22 April 2010 22:53:34 Thomas Chou wrote: This patch supports mmc/sd card with spi interface. I have tested with sd and mmc cards. But there is still ocr issue with SDHC. now the semi-obvious question ... how does this differ from the old spi_mmc.c driver ? i see this doesnt rely on the legacy mmc framework, but what about device/commandset support parity ? it's too bad the new framework doesnt allow for dynamic probing like the spi layer. makes it a pain to work with a SPI/MMC card that can have the CS changed on the fly. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: remove EP1C20, EP1S10, EP1S40 boards
Hi Scott, On 04/22/2010 08:36 PM, Scott McNutt wrote: With nios2-generic approach, the fpga parameter header file can be generated from hardware designs using tools. Porting u-boot for What tools are you referring to? There are two tools. 1. sopc-create-header-files It is included in altera design suite v8.0 or later. I used this in the initial version of nios2-generic board. 2. sopc-create-config-files The script is available at http://sopc.et.ntust.edu.tw/?p=toolchain-build.git; a=blob_plain;f=tools/sopc-create-config-files;hb=HEAD I wrote this to generate unified u-boot header files, while I was discussing with Michal Simek. He liked this approach and I got his Acked-by of this patch. Support for several Altera nios2 boards has been available in u-boot for at least four years. To date, this vendor has offered no support whatsoever, either through patches, files, consultation or otherwise. Is there any reason you believe this is likely to change? We really appreciate your work. But these boards are getting obsolete, and there are more new boards unsupported. We cannot add every board, and a generic approach should be taken as Michal suggested. We, (you, I , the community and Altera), should work together to offer a better solution. The binary generated with the nios2-generic target should work on these three boards. I tested on EP1C20 and I believe it will work on the other two. These boards are still supported, just under a different name. no need to include other boards support for nios2 in the u-boot mainline. I'm not convinced that this is true. Michal's work on microblaze-generic already proved this. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Adding new architecture (nds32) support to u-boot
Hi Wolfgang, I’m working for Andestech, which is a RISC IP (NDS32) company in Taiwan. This company has been started for 5 years. In recent , we are planning to release source code such as Linux Kernel and GNU toolchain back to communities. We also plan to commit code to u-boot. I’ve read some materials on u-boot wiki. It seems other architectures will maintain their own u-boot git, and you will merge their code into your mainline trunk. If we want to init a new u-boot git repository for our architecture, should we just follow the instructions wrote in http://www.denx.de/wiki/U-Boot/CustodianGitTrees “? Since our toolchain haven’t been commit to GNU, could we commit code to u-boot before GNU accept our toolchain support? Is there anything special that we must provide to you? Thanks for your replying. Best regards, Macpaul Lin Mobile: +886-919380156 Software Engineer (Andes Tech.) 2F, No.1, Li-Hsin First Road, Science-Based Industrial Park, Hsinchu 300, Taiwan, R.O.C. Tel: +886-3-6668300 #379 Fax: +886-3-6668322 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: add generic mmc spi driver
On 04/23/2010 11:35 AM, Mike Frysinger wrote: On Thursday 22 April 2010 22:53:34 Thomas Chou wrote: This patch supports mmc/sd card with spi interface. I have tested with sd and mmc cards. But there is still ocr issue with SDHC. now the semi-obvious question ... how does this differ from the old spi_mmc.c driver ? i see this doesnt rely on the legacy mmc framework, but what about device/commandset support parity ? Hi Mike, Right after playing your spi_mmc.c, I started this one based on generic mmc framework last night. I tried hard to recall my memory about mmc/sd, and hoped to catch up the merge window. Do you mean parity as crc? Crc is not supported, but can be added. I make some command set translation when spi doesn't support. it's too bad the new framework doesnt allow for dynamic probing like the spi layer. makes it a pain to work with a SPI/MMC card that can have the CS changed on the fly. -mike Maybe we can move spi_setup_slave to the mmc-init() and do probing. Or shall we add a subcommand? Cheers, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: remove EP1C20, EP1S10, EP1S40 boards
Hi Thomas, Thomas Chou wrote: With nios2-generic approach, the fpga parameter header file can be generated from hardware designs using tools. Porting u-boot for What tools are you referring to? 2. sopc-create-config-files The script is available at http://sopc.et.ntust.edu.tw/?p=toolchain-build.git; a=blob_plain;f=tools/sopc-create-config-files;hb=HEAD Ok ... GPL ... very nice! This addresses several of my big concerns. We cannot add every board, and a generic approach should be taken as Michal suggested. We, (you, I , the community and Altera), should work together to offer a better solution. Agreed. And please realize that I think the generic approach is a great way to proceed. I listed my concerns in an earlier response to Dalon. The availability of your GPL-ed script addresses most of them. The binary generated with the nios2-generic target should work on these three boards. I tested on EP1C20 and I believe it will work on the other two. These boards are still supported, just under a different name. I tested on the 1c20 this evening as well ... works fine. I will test on the 2c35 board tomorrow. I'd like to get a positive confirmation WRT the 1S10 and 1S40 before applying this patch. no need to include other boards support for nios2 in the u-boot mainline. I'm not convinced that this is true. Michal's work on microblaze-generic already proved this. Michal proved the concept ... and the microblaze implementation (many thanks for your contributions Michal). I'd like to _know_ that nothing is broken before we remove existing code -- I don't want to leave anyone high and dry. I've been in such situations ... it's no fun. I'll apply the generic board patch to the nios 'next' branch, but I'd like to hold off on blowing away those other board trees until we get a chance to test the generic board on the actual targets. Fair enough? Thanks for your efforts. Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: remove EP1C20, EP1S10, EP1S40 boards
On 04/23/2010 12:21 PM, Scott McNutt wrote: I tested on the 1c20 this evening as well ... works fine. I will test on the 2c35 board tomorrow. I'd like to get a positive confirmation WRT the 1S10 and 1S40 before applying this patch. Great! Please also check epcs/spi flash on EP1C20. 1. apply this patch, [PATCH] spi_flash: support old STMicro parts with RES 2. add the following to board/altera/nios2-generic/custom_fpga.h /* epcs_controller.epcs_control_port is a altera_avalon_epcs_flash_controller */ #define CONFIG_SYS_SPI_BASE 0x82100200 #define CONFIG_ALTERA_SPI #define CONFIG_CMD_SPI #define CONFIG_CMD_SF #define CONFIG_SF_DEFAULT_SPEED 3000 #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_STMICRO 3. sf probe 0 sf read/write I'll apply the generic board patch to the nios 'next' branch, but I'd like to hold off on blowing away those other board trees until we get a chance to test the generic board on the actual targets. Fair enough? OK. Cheers, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] support for spansion s29gl-p flash?
Hi Aditya, On Friday 23 April 2010 03:35:59 Aditya Ojha (adojha) wrote: Does the latest u-boot include support for these flash families: - Spansion S29GL-P MirrorBit flash family or - Numonyx Axcell M29EW The common CFI driver (drivers/mtd/cfi_flash.c) should be able to support all CFI compliant FLASH types. The Spansion ones are definitely supported. I suggest you take a look at the Numonyx datasheets to see if they are CFI compliant. If yes, this driver should support them as well. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot Porting for MIPS32 (Au1350)
Hi All, we are porting U-boot 1.2.0 to MIPS32 Au1350 Processor. i am using ELDK 4.1 for MIPS32. Thanks wolfgang now am able to compile toolchain for mips after using ELDK for MIPS. Now while porting U-boot to Au1350 MIPS32 we are facing following problems mentioned below. We have a MIPS CPU which has reset address 0xBFC0 , this is mapped to NOR flash with XIP in place. The boot block ( ie 0xBFC0) is in the top block of the NOR flash and its of 16KB. U-Boot shall be put from address 0xBFC0 in the NOR flash for CPU boot up , since it is the last block (16KB only) we cannot put complete U-Boot , some part of the U-Boot should go to lower blocks . To do this u-boot need to be divided into blocks and we shall provide a jump from the top block to other blocks of NOR flash. We have BDI3000 debugger for flashing the NOR flash and bdiGDB for MIPS. Is there any NOR flash drivers available which can support the below chip? NOR Flash chip : M29W160ET -- AM29BX16 NOR Flash chip size is 0x0020 -- 2MB MIPS CPU Clock is 660MHz System Bus is 330MHz SDRAM bus clock is 165MHz please let me know if am going wrong anywhere or missing out something. With Regards, Gurumurthy Gowdar KPIT Cummins Infosystems Ltd ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] smc911x driver frame alignment patch
SMSC911x chips have alignment function to allow frame payload data (which comes after 14-bytes ethernet header) to be aligned at some boundary when reading it from fifo (usually - 4 bytes boundary). This is done by inserting fake zeros bytes BEFORE actual frame data when reading from SMSC's fifo. This function controlled by RX_CFG register. There are bits that represents amount of fake bytes to be inserted. Linux uses alignment of 4 bytes. Ethernet frame header is 14 bytes long, so we need to add 2 fake bytes to get payload data aligned at 4-bytes boundary. Linux driver does this by adding IP_ALIGNMENT constant (defined at skb.h) when calculating fifo data length. All network subsystem of Linux uses this constant too when calculating different offsets. But u-boot does not use any packet data alignment, so we don't need to add anything when calculating fifo data length. Moreover, driver zeros the RX_CFG register just one line up, so chip does not insert any fake data at the beginig. So calculated data length is always bigger by 1 word. It seems that at almost every packet read we get an underflow condition at fifo and possible corruption of data. Especially at continuous transfers, such as tftp. Just after removing this magic addition, I've got tftp transfer speed as it aught to be at 100Mbps. It was really slow before. It seems that fifo underflow occurs only when using byte packing on 32-bit blackfin bus (may be because of very small delay between reads). Signed-off-by: Valentin Yakovenkov yakoven...@niistt.ru diff -r 7dc8ff189175 a/drivers/net/smc911x.c --- a/drivers/net/smc911x.c Mon Mar 29 11:08:55 2010 +0400 +++ b/drivers/net/smc911x.c Mon Apr 19 10:46:02 2010 +0400 @@ -220,7 +220,7 @@ smc911x_reg_write(dev, RX_CFG, 0); - tmplen = (pktlen + 2+ 3) / 4; + tmplen = (pktlen + 3) / 4; while (tmplen--) *data++ = pkt_data_pull(dev, RX_DATA_FIFO); -- WBR, Valentin CJSC NII STT, Russia, Smolensk http://www.niistt.ru smime.p7s Description: S/MIME Cryptographic Signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: add generic mmc spi driver
On 04/23/2010 12:04 PM, Thomas Chou wrote:
it's too bad the new framework doesnt allow for dynamic probing like
the spi
layer. makes it a pain to work with a SPI/MMC card that can have the CS
changed on the fly.
-mike
Second thought.
With generic mmc framework, we can instance multiple mmc devices. Then
we can probe one of them when we want.
#ifdef CONFIG_GENERIC_MMC
int board_mmc_init(bd_t *bis)
{
int rc = 0;
#ifdef CONFIG_MMC_SPI
extern int mmc_spi_init(uint bus, uint cs, uint speed, uint mode);
mmc_spi_init(CONFIG_MMC_SPI_BUS,
CONFIG_MMC_SPI_CS_0,
CONFIG_MMC_SPI_SPEED,
CONFIG_MMC_SPI_MODE);
mmc_spi_init(CONFIG_MMC_SPI_BUS,
CONFIG_MMC_SPI_CS_1,
CONFIG_MMC_SPI_SPEED,
CONFIG_MMC_SPI_MODE);
#endif
return rc;
}
#endif
Cheers,
Thomas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
