Re: [U-Boot] [PATCH v5 1/1] imximage: Add MX53 boot image support
Hi, Wolfgang, 2011/1/20 Jason Liu : > This patch add the MX53 boot image support. > > This patch has been tested on Freescale MX53EVK board > and MX51EVK board. > > Signed-off-by: Jason Liu > > --- > Changes for v2: > - Address the following comments from Stefano, > - Get rid of #ifdef in the imximage.h and .c file and use > the runtime check for imximage version > - Document the IMXIMAGE_VERSION definiton in doc/README.imximage > - Move mx53evk/config.mk and mx53evk/imximage.cfg to MX53EVK board > support patch. > > Changes for v3: > - Address the following comments from Stefano, > - Not change the mx51evk file. The code should take VERSION=1 as default, > and we do not need to change the actual boards. > - add a note in the documentation and raise an error in code if the > VERSION command is read after any other suitable commands. > - Change command IMXIMAGE_VERSION simply to IMAGE_VERSION > - Need recognize the version directly from its structure and not storing the > version into the header when do header verify and print. > - Use function pointer to simpliy the code when the version of header is > recognized > Changes for v4: > - Address the following comments from Wolfgang, > - Keep the imximage_cmds table sorted, > - Add braces for (expx) && (expy) gloably, > - Return failure to upper call if met errors for function > - Add comments for function set_dcd_rst_v1 alike, > - Re-orgnize code to avoid deep nesting, > Changes for v5: > - Remove the blank line before the only one line statement and > not using braces for the one line statment for the sake of the > same coding style of this file. For example, > if (!exp) > return ret; > --- > doc/README.imximage | 12 +- > tools/imximage.c | 525 > +-- > tools/imximage.h | 110 +-- > 3 files changed, 487 insertions(+), 160 deletions(-) > Any feedback about this patch? > > ___ > 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] min/max macros are broken in common.h
The min and max macros break if x is 32-bit and y is 64-bit. y will always get truncated to 32-bit and it will fail. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Kumar Gala, In message <356989c7-fa92-46d5-9fb6-5f9332ecb...@kernel.crashing.org> you wrote: > > The issue is that the code under post/lib_powerpc/fpu/* is compiled with: > > CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//) > CFLAGS += -mhard-float -fkeep-inline-functions > > We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir > if CONFIG_POST_FPU isn't set in CONFIG_POST. This might solve the warning in most cases - but what abut these where CONFIG_POST_FPU is defined? I mean, it is inherent that these tests need to execute FP instructions. 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 Every little picofarad has a nanohenry all its own. - Don Vonada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Added Bluewater Systems Snapper 9260 and 9G20 module config to top-level Makefile
Dear Ryan Mallon, > Signed-off-by: Ryan Mallon > --- > Makefile | 13 + > 1 files changed, 13 insertions(+), 0 deletions(-) New boards must be added to boards.cfg. See how it is done for the at91sam9260ek boards in the rework branch. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Add support for Bluewater Systems Snapper 9260 and 9G20 modules
Dear Ryan Mallon,
> Signed-off-by: Ryan Mallon
> ---
> board/bluewater/snapper9260/Makefile | 55 +
> board/bluewater/snapper9260/config.mk |1 +
See comment in your patch 0/3.
> board/bluewater/snapper9260/snapper9260.c | 177
> +
> 3 files changed, 233 insertions(+), 0 deletions(-)
> create mode 100644 board/bluewater/snapper9260/Makefile
> create mode 100644 board/bluewater/snapper9260/config.mk
> create mode 100644 board/bluewater/snapper9260/snapper9260.c
>
> diff --git a/board/bluewater/snapper9260/Makefile
> b/board/bluewater/snapper9260/Makefile
> new file mode 100644
> index 000..20d2406
> --- /dev/null
> +++ b/board/bluewater/snapper9260/Makefile
> @@ -0,0 +1,55 @@
> +#
> +# (C) Copyright 2003-2008
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +#
> +# (C) Copyright 2011 Bluewater Systems
> +#
> +# 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).o
> +
> +COBJS-y += snapper9260.o
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB): $(OBJS) $(SOBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
This is old code. Libraries are not built anymore.
Has this even been built on current top of tree u-boot?
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean: clean
> + rm -f $(LIB) core *.bak .depend
> +
> +.depend: Makefile $(SOBJS:.o=.S) $(OBJS:.o=.c)
> + $(CC) -M $(CPPFLAGS) $(SOBJS:.o=.S) $(OBJS:.o=.c)> $@
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/bluewater/snapper9260/config.mk
> b/board/bluewater/snapper9260/config.mk
> new file mode 100644
> index 000..e554a45
> --- /dev/null
> +++ b/board/bluewater/snapper9260/config.mk
> @@ -0,0 +1 @@
> +CONFIG_SYS_TEXT_BASE = 0x23f0
> diff --git a/board/bluewater/snapper9260/snapper9260.c
> b/board/bluewater/snapper9260/snapper9260.c
> new file mode 100644
> index 000..04cb0a8
> --- /dev/null
> +++ b/board/bluewater/snapper9260/snapper9260.c
> @@ -0,0 +1,177 @@
> +/*
> + * Bluewater Systems Snapper 9260/9G20 modules
> + *
> + * (C) Copyright 2011 Bluewater Systems
> + * Author: Andre Renaud
> + * Author: Ryan Mallon
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* The mach-type is the same for both Snapper 9260 and 9G20 */
> +#define SNAPPER9260_MACH_TYPE1987
Nope. This is not acceptable. ARM mach types are exclusively defined in
mach-types.h. Its already there:
#define MACH_TYPE_SNAPPER_9260 1987
> +
> +#define IO_EXP_ETH_RESET (0<< 1)
> +#define IO_EXP_ETH_POWER (1<< 1)
> +
> +static void macb_hw_init(void)
> +{
> + unsigned long rstc;
> +
> + /* Enable clock */
> + at91_sys_write(AT91_PMC_PCER, 1<< AT91SAM9260_ID_EMAC);
> +
> + /* Disable pull-ups to prevent PHY going into test mode */
> + writel(pin_to_mask(AT91_PIN_PA14) |
> +pin_to_mask(AT91_PIN_PA15) |
>
Re: [U-Boot] [PATCH 1/3] Add AT91SAM9G20 to list of AT91 processors in soft_i2c driver.
Dear Ryan Mallon, > Signed-off-by: Ryan Mallon > --- > drivers/i2c/soft_i2c.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c > index 1a1809a..0a21d02 100644 > --- a/drivers/i2c/soft_i2c.c > +++ b/drivers/i2c/soft_i2c.c > @@ -32,7 +32,7 @@ > #endif > #if defined(CONFIG_AT91RM9200) || \ > defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ > - defined(CONFIG_AT91SAM9263) > + defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) Please replace those individual AT91SAM9* SoC names by a simple #if defined(CONFIG_AT91FAMILY) || defined(CONFIG_AT91RM9200) Sorry that this list has escaped detection so far. *RM9200 is still needed extra, because it has not yet become a member of AT91FAMILY. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Add support for Bluewater System Snapper 9260 and 9G20 modules
Dear Ryan Mallon, > Add support for Bluewater Systems Snapper9260/9G20 modules. The > modules are based on the AT91SAM9260 and AT91SAM9G20 processors > respectively and support NAND flash and Ethernet. > > Ryan Mallon (3): >Add AT91SAM9G20 to list of AT91 processors in soft_i2c driver. >Add support for Bluewater Systems Snapper 9260 and 9G20 modules >Added Bluewater Systems Snapper 9260 and 9G20 module config to > top-level Makefile > > Makefile | 13 ++ No additions to Makefile. New board defines go into boards.cfg > board/bluewater/snapper9260/Makefile | 55 + > board/bluewater/snapper9260/config.mk |1 + This file is not required. CONFIG_SYS_TEXT_BASE belongs into your board configuration file in include/configs/. By the way, where is this file? > board/bluewater/snapper9260/snapper9260.c | 177 > + Seems to be based on very old Code. See comments there. > drivers/i2c/soft_i2c.c|2 +- #if defined(CONFIG_AT91FAMILY) should be used for all AT91, individual AT91 SoCs don't need to be checked anymore. See comment there. > 5 files changed, 247 insertions(+), 1 deletions(-) > create mode 100644 board/bluewater/snapper9260/Makefile > create mode 100644 board/bluewater/snapper9260/config.mk > create mode 100644 board/bluewater/snapper9260/snapper9260.c MAINTAINERS entry missing. > Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6 5/5] Pantheon: Add Board Support for Marvell dkb board
DKB is a Development Board for PANTHEON TD/TTC(pxa920/pxa910) with
* Processor upto 806Mhz
* LPDDR1/2
* x8/x16 SLC/MLC NAND
* Footprints for eMMC & MMC x8 card
With Peripherals:
* Parallel LCD I/F
* Audio codecs (88PM8607)
* MIPI CSI-2 camera
* Marvell 88W8787 802.11n/BT module
* Marvell 2G/3G RF
* Dual analog mics & speakers, headset jack, LED, ambient
* USB2.0 HS host, OTG (mini AB)
* GPIO, GPIO expander with DIP switches for easier selection
* UART serial over USB, CIR
This patch adds basic board support with DRAM and UART functionality
Signed-off-by: Lei Wen
---
V2:
V3:
Fix copyright claim year.
V4:
Add change log to each patch.
V5:
Remove additional CONFIG_SYS_NS16550_COM1 definition in dkb.h
V6:
Rebase patch on latest u-boot-marvell.git.
And fix a build warning.
MAINTAINERS|4 +++
board/Marvell/dkb/Makefile | 51
board/Marvell/dkb/dkb.c| 54 ++
boards.cfg |1 +
include/configs/dkb.h | 62
5 files changed, 172 insertions(+), 0 deletions(-)
create mode 100644 board/Marvell/dkb/Makefile
create mode 100644 board/Marvell/dkb/dkb.c
create mode 100644 include/configs/dkb.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d92ff8d..36e2516 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -850,6 +850,10 @@ Prafulla Wadaskar
rd6281a ARM926EJS (Kirkwood SoC)
sheevaplug ARM926EJS (Kirkwood SoC)
+Lei Wen
+
+ dkb ARM926EJS (PANTHEON 88AP920 SOC)
+
Matthias Weisser
jadecpu ARM926EJS (MB86R01 SoC)
diff --git a/board/Marvell/dkb/Makefile b/board/Marvell/dkb/Makefile
new file mode 100644
index 000..8835f8e
--- /dev/null
+++ b/board/Marvell/dkb/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2010
+# Marvell Semiconductor
+# Written-by: Lei Wen
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS := dkb.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+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 .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/Marvell/dkb/dkb.c b/board/Marvell/dkb/dkb.c
new file mode 100644
index 000..95a3982
--- /dev/null
+++ b/board/Marvell/dkb/dkb.c
@@ -0,0 +1,54 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor
+ * Written-by: Lei Wen
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_f(void)
+{
+ u32 mfp_cfg[] = {
+ /* Enable Console on UART2 */
+ MFP47_UART2_RXD,
+ MFP48_UART2_TXD,
+
+ MFP_EOC /*End of configureation*/
+ };
+ /* configure MFP's */
+ mfp_config(mfp_cfg);
+
+ return 0;
+}
+
+int board_init(void)
+{
+ /* arch number of Board */
+ gd->bd->bi_arch_number = MACH_TYPE_TTC_DKB;
+ /* adress of boot parameters */
+ gd->
[U-Boot] [PATCH V6 4/5] mvmfp: add MFP configuration support for PANTHEON
This patch adds the support MFP support for Marvell PANTHEON SoCs Signed-off-by: Lei Wen --- V2: V3: Fix copyright claim year. V4: Add change log to each patch. V5: coding style fix. V6: Rebase patch on latest u-boot-marvell.git. arch/arm/include/asm/arch-pantheon/mfp.h | 41 ++ drivers/gpio/mvmfp.c |2 + 2 files changed, 43 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-pantheon/mfp.h diff --git a/arch/arm/include/asm/arch-pantheon/mfp.h b/arch/arm/include/asm/arch-pantheon/mfp.h new file mode 100644 index 000..ce3aca1 --- /dev/null +++ b/arch/arm/include/asm/arch-pantheon/mfp.h @@ -0,0 +1,41 @@ +/* + * Based on arch/arm/include/asm/arch-armada100/mfp.h + * (C) Copyright 2010 + * Marvell Semiconductor + * Written-by: Lei Wen + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#ifndef __PANTHEON_MFP_H +#define __PANTHEON_MFP_H + +/* + * Frequently used MFP Configuration macros for all PANTHEON family of SoCs + * + * offset, pull,pF, drv,dF, edge,eF ,afn,aF + */ +/* UART2 */ +#define MFP47_UART2_RXDMFP_REG(0x198) | MFP_AF6 | MFP_DRIVE_MEDIUM +#define MFP48_UART2_TXDMFP_REG(0x19c) | MFP_AF6 | MFP_DRIVE_MEDIUM + +/* More macros can be defined here... */ + +#define MFP_PIN_MAX117 +#endif diff --git a/drivers/gpio/mvmfp.c b/drivers/gpio/mvmfp.c index 5646ed4..e7830c6 100644 --- a/drivers/gpio/mvmfp.c +++ b/drivers/gpio/mvmfp.c @@ -28,6 +28,8 @@ #include #ifdef CONFIG_ARMADA100 #include +#elif defined(CONFIG_PANTHEON) +#include #else #error Unsupported SoC... #endif -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6 3/5] serial: add pantheon soc support
Signed-off-by: Lei Wen --- V2: V3: Fix copyright claim year. V4: Add change log to each patch. V5: V6: Rebase patch on latest u-boot-marvell.git. drivers/serial/serial.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c index cd3439e..4032dfd 100644 --- a/drivers/serial/serial.c +++ b/drivers/serial/serial.c @@ -33,6 +33,8 @@ #include #elif defined(CONFIG_ARMADA100) #include +#elif defined(CONFIG_PANTHEON) +#include #endif #if defined (CONFIG_SERIAL_MULTI) -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6 2/5] ARM: Add Support for Marvell Pantheon Familiy SoCs
Pantheon Family processors are highly integrated SoCs
based on Sheeva_88SV331x-v5 PJ1 cpu core.
Ref:
http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf
SoC versions Supported:
1) PANTHEON920 (TD)
2) PANTHEON910 (TTC)
Signed-off-by: Lei Wen
---
V2:
V3:
Fix copyright claim year.
V4:
Add change log to each patch.
V5:
coding style fix.
V6:
Rebase patch on latest u-boot-marvell.git.
arch/arm/cpu/arm926ejs/pantheon/Makefile | 46 ++
arch/arm/cpu/arm926ejs/pantheon/cpu.c | 78 +
arch/arm/cpu/arm926ejs/pantheon/dram.c| 132
arch/arm/cpu/arm926ejs/pantheon/timer.c | 207 +
arch/arm/include/asm/arch-pantheon/config.h | 44 ++
arch/arm/include/asm/arch-pantheon/cpu.h | 79 ++
arch/arm/include/asm/arch-pantheon/pantheon.h | 54 +++
7 files changed, 640 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/pantheon/Makefile
create mode 100644 arch/arm/cpu/arm926ejs/pantheon/cpu.c
create mode 100644 arch/arm/cpu/arm926ejs/pantheon/dram.c
create mode 100644 arch/arm/cpu/arm926ejs/pantheon/timer.c
create mode 100644 arch/arm/include/asm/arch-pantheon/config.h
create mode 100644 arch/arm/include/asm/arch-pantheon/cpu.h
create mode 100644 arch/arm/include/asm/arch-pantheon/pantheon.h
diff --git a/arch/arm/cpu/arm926ejs/pantheon/Makefile
b/arch/arm/cpu/arm926ejs/pantheon/Makefile
new file mode 100644
index 000..73644c7
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/pantheon/Makefile
@@ -0,0 +1,46 @@
+#
+# (C) Copyright 2010
+# Marvell Semiconductor
+# Written-by: Lei Wen
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+COBJS-y= cpu.o timer.o dram.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
+
+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/pantheon/cpu.c
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
new file mode 100644
index 000..fd006af
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor
+ * Written-by: Lei Wen
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#define UARTCLK14745KHZ(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1))
+#define SET_MRVL_ID(1<<8)
+#define L2C_RAM_SEL(1<<4)
+
+int arch_cpu_init(void)
+{
+ u32 val;
+ struct panthcpu_registers *cpuregs =
+ (struct panthcpu_registers*) PANTHEON_CPU_BASE;
+
+ struct panthapb_registers *apbclkres =
+ (struct panthapb_registers*) PANTHEON_APBC_BASE;
+
+ struct panthmpmu_registers *mpmu =
+ (struct panthmpmu_registers*) PANTHEON_MPMU_BASE;
+
+ /* set SEL_MRVL_ID bit in PANTHEON_CPU_CONF register */
+ val = readl(&cpuregs->cpu_conf);
+ val = val | SET_MRVL_ID;
+ writel(val, &cpuregs->cpu_conf);
+
+ /* Turn on clock gating (PMUM_CCGR) */
+ writel(0x, &mpmu->ccgr);
+
+ /* Turn on clock gating (
[U-Boot] [PATCH V6 1/5] mv: seperate kirkwood and armada from common setting
Since there are lots of difference between kirkwood and armada series, it is better to seperate them but still keep the most common file shared by all marvell platform in the mv-common configure file. This patch move the kirkwood only driver definitoin in mv-common to the /config.h. This patch is tested with compilation for armada100 and guruplug. Signed-off-by: Lei Wen --- V2: This patch seris update the seperate mv_common part as suggested. V3: Fix config.h include place and copyright claim year. V4: Add change log to each patch. V5: Add CONFIG_SYS_MVFS doc in README. V6: Rebase patch on latest u-boot-marvell.git. README |5 + arch/arm/include/asm/arch-armada100/config.h | 50 + arch/arm/include/asm/arch-kirkwood/config.h | 145 + include/configs/aspenite.h |1 + include/configs/mv-common.h | 147 -- 5 files changed, 222 insertions(+), 126 deletions(-) create mode 100644 arch/arm/include/asm/arch-armada100/config.h create mode 100644 arch/arm/include/asm/arch-kirkwood/config.h diff --git a/README b/README index 755d17c..e0341b5 100644 --- a/README +++ b/README @@ -319,6 +319,11 @@ The following options need to be configured: CONFIG_SYS_PQ2FADS - PQ2FADS-ZU or PQ2FADS-VR CONFIG_SYS_8272ADS - MPC8272ADS +- Marvell Family Member + CONFIG_SYS_MVFS - define it if you want to enable + multiply fs option at one time + for marvell soc family + - MPC824X Family Member (if CONFIG_MPC824X is defined) Define exactly one of CONFIG_MPC8240, CONFIG_MPC8245 diff --git a/arch/arm/include/asm/arch-armada100/config.h b/arch/arm/include/asm/arch-armada100/config.h new file mode 100644 index 000..9995b1a --- /dev/null +++ b/arch/arm/include/asm/arch-armada100/config.h @@ -0,0 +1,50 @@ +/* + * (C) Copyright 2010 + * Marvell Semiconductor + * Written-by: Lei Wen + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +/* + * This file should be included in board config header file. + * + * It supports common definitions for Armada100 platform + */ + +#ifndef _ARMD1_CONFIG_H +#define _ARMD1_CONFIG_H + +#define CONFIG_ARM926EJS 1 /* Basic Architecture */ + +#define CONFIG_SYS_TCLK(14745600) /* NS16550 clk config */ +#define CONFIG_SYS_HZ_CLOCK(325) /* Timer Freq. 3.25MHZ */ +#define CONFIG_MARVELL_MFP /* Enable mvmfp driver */ +#define MV_MFPR_BASE ARMD1_MFPR_BASE +#define MV_UART_CONSOLE_BASE ARMD1_UART1_BASE +#define CONFIG_SYS_NS16550_IER (1 << 6)/* Bit 6 in UART_IER register + represents UART Unit Enable */ +/* + * There is no internal RAM in ARMADA100, using DRAM + * TBD: dcache to be used for this + */ +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE - 0x0020) +#define CONFIG_NR_DRAM_BANKS_MAX 2 + +#endif /* _ARMD1_CONFIG_H */ diff --git a/arch/arm/include/asm/arch-kirkwood/config.h b/arch/arm/include/asm/arch-kirkwood/config.h new file mode 100644 index 000..7c6d63b --- /dev/null +++ b/arch/arm/include/asm/arch-kirkwood/config.h @@ -0,0 +1,145 @@ +/* + * (C) Copyright 2010 + * Marvell Semiconductor + * Written-by: Lei Wen + * + * 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 + * Founda
[U-Boot] [PATCH V6 0/5] Add Pantheon soc and dkb board support
This patch set add the Pantheon soc and dkb board support. V2: This patch seris update the seperate mv_common part as suggested. V3: Fix config.h include place and copyright claim year. V4: Add change log to each patch. V5: Add doc in Readme for new CONFIG_SYS_MVFS. code style fix. V6: Rebase patch on latest u-boot-marvell.git. And fix a build warning. Lei Wen (5): mv: seperate kirkwood and armada from common setting ARM: Add Support for Marvell Pantheon Familiy SoCs serial: add pantheon soc support mvmfp: add MFP configuration support for PANTHEON Pantheon: Add Board Support for Marvell dkb board MAINTAINERS |4 + README|5 + arch/arm/cpu/arm926ejs/pantheon/Makefile | 46 ++ arch/arm/cpu/arm926ejs/pantheon/cpu.c | 78 + arch/arm/cpu/arm926ejs/pantheon/dram.c| 132 arch/arm/cpu/arm926ejs/pantheon/timer.c | 207 + arch/arm/include/asm/arch-armada100/config.h | 50 ++ arch/arm/include/asm/arch-kirkwood/config.h | 145 + arch/arm/include/asm/arch-pantheon/config.h | 44 ++ arch/arm/include/asm/arch-pantheon/cpu.h | 79 ++ arch/arm/include/asm/arch-pantheon/mfp.h | 41 + arch/arm/include/asm/arch-pantheon/pantheon.h | 54 +++ board/Marvell/dkb/Makefile| 51 ++ board/Marvell/dkb/dkb.c | 54 +++ boards.cfg|1 + drivers/gpio/mvmfp.c |2 + drivers/serial/serial.c |2 + include/configs/aspenite.h|1 + include/configs/dkb.h | 62 include/configs/mv-common.h | 147 +++--- 20 files changed, 1079 insertions(+), 126 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/pantheon/Makefile create mode 100644 arch/arm/cpu/arm926ejs/pantheon/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/pantheon/dram.c create mode 100644 arch/arm/cpu/arm926ejs/pantheon/timer.c create mode 100644 arch/arm/include/asm/arch-armada100/config.h create mode 100644 arch/arm/include/asm/arch-kirkwood/config.h create mode 100644 arch/arm/include/asm/arch-pantheon/config.h create mode 100644 arch/arm/include/asm/arch-pantheon/cpu.h create mode 100644 arch/arm/include/asm/arch-pantheon/mfp.h create mode 100644 arch/arm/include/asm/arch-pantheon/pantheon.h create mode 100644 board/Marvell/dkb/Makefile create mode 100644 board/Marvell/dkb/dkb.c create mode 100644 include/configs/dkb.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Pantheon: Add Board Support for Marvell dkb board
Hi Prafulla, On Tue, Jan 25, 2011 at 6:16 AM, Prafulla Wadaskar wrote: > > >> -Original Message- >> From: Lei Wen [mailto:lei...@marvell.com] >> Sent: Wednesday, January 19, 2011 12:13 AM >> To: Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Yu Tang; >> Ashish Karkare; Prabhanjan Sarnaik; Lei Wen >> Subject: [PATCH 5/5] Pantheon: Add Board Support for Marvell dkb board >> >> DKB is a Development Board for PANTHEON TD/TTC(pxa920/pxa910) with >> * Processor upto 806Mhz >> * LPDDR1/2 >> * x8/x16 SLC/MLC NAND >> * Footprints for eMMC & MMC x8 card >> >> With Peripherals: >> * Parallel LCD I/F >> * Audio codecs (88PM8607) >> * MIPI CSI-2 camera >> * Marvell 88W8787 802.11n/BT module >> * Marvell 2G/3G RF >> * Dual analog mics & speakers, headset jack, LED, ambient >> * USB2.0 HS host, OTG (mini AB) >> * GPIO, GPIO expander with DIP switches for easier selection >> * UART serial over USB, CIR >> >> This patch adds basic board support with DRAM and UART functionality >> >> Signed-off-by: Lei Wen >> --- >> V2: >> >> V3: >> Fix copyright claim year. >> >> V4: >> Add change log to each patch. >> >> V5: >> Remove additional CONFIG_SYS_NS16550_COM1 definition in dkb.h > > Hi Lei > This patch cannot be cleanly applied, please pull u-boot-marvell.git first > Also please resolve below warnings. > > [prafulla@pe-dt061 u-boot-marvell.git]$ cat warn.txt > dkb.c: In function board_init: > dkb.c:51: warning: implicit declaration of function panth_sdram_base > I would post another patch set rebase on the latest u-boot-marvell to fix that... Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Invitation to connect on LinkedIn
LinkedIn Jason Liu requested to add you as a connection on LinkedIn: -- Srinath, I'd like to add you to my professional network on LinkedIn. - Jason Accept invitation from Jason Liu http://www.linkedin.com/e/fds2np-gjc5t69w-7/YhLefj14Y3m-0E8v1ZCDgtixJP5Kn9_7/blk/I2576461669_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnPASdz4Sd3oTdj99bSZoql5ch55cbP0NczwScjgMcz8LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Jason Liu http://www.linkedin.com/e/fds2np-gjc5t69w-7/YhLefj14Y3m-0E8v1ZCDgtixJP5Kn9_7/blk/I2576461669_2/39vejoScjoQdzsRcAALqnpPbOYWrSlI/svi/ -- DID YOU KNOW LinkedIn can help you find the right service providers using recommendations from your trusted network? Using LinkedIn Services, you can take the risky guesswork out of selecting service providers by reading the recommendations of credible, trustworthy members of your network. http://www.linkedin.com/e/fds2np-gjc5t69w-7/svp/inv-25/ -- (c) 2010, LinkedIn Corporation___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] Add support for Bluewater Systems Snapper 9260 and 9G20 modules
Signed-off-by: Ryan Mallon
---
board/bluewater/snapper9260/Makefile | 55 +
board/bluewater/snapper9260/config.mk |1 +
board/bluewater/snapper9260/snapper9260.c | 177 +
3 files changed, 233 insertions(+), 0 deletions(-)
create mode 100644 board/bluewater/snapper9260/Makefile
create mode 100644 board/bluewater/snapper9260/config.mk
create mode 100644 board/bluewater/snapper9260/snapper9260.c
diff --git a/board/bluewater/snapper9260/Makefile
b/board/bluewater/snapper9260/Makefile
new file mode 100644
index 000..20d2406
--- /dev/null
+++ b/board/bluewater/snapper9260/Makefile
@@ -0,0 +1,55 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2011 Bluewater Systems
+#
+# 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).o
+
+COBJS-y+= snapper9260.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB): $(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+.depend: Makefile $(SOBJS:.o=.S) $(OBJS:.o=.c)
+ $(CC) -M $(CPPFLAGS) $(SOBJS:.o=.S) $(OBJS:.o=.c) > $@
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/bluewater/snapper9260/config.mk
b/board/bluewater/snapper9260/config.mk
new file mode 100644
index 000..e554a45
--- /dev/null
+++ b/board/bluewater/snapper9260/config.mk
@@ -0,0 +1 @@
+CONFIG_SYS_TEXT_BASE = 0x23f0
diff --git a/board/bluewater/snapper9260/snapper9260.c
b/board/bluewater/snapper9260/snapper9260.c
new file mode 100644
index 000..04cb0a8
--- /dev/null
+++ b/board/bluewater/snapper9260/snapper9260.c
@@ -0,0 +1,177 @@
+/*
+ * Bluewater Systems Snapper 9260/9G20 modules
+ *
+ * (C) Copyright 2011 Bluewater Systems
+ * Author: Andre Renaud
+ * Author: Ryan Mallon
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* The mach-type is the same for both Snapper 9260 and 9G20 */
+#define SNAPPER9260_MACH_TYPE 1987
+
+#define IO_EXP_ETH_RESET (0 << 1)
+#define IO_EXP_ETH_POWER (1 << 1)
+
+static void macb_hw_init(void)
+{
+ unsigned long rstc;
+
+ /* Enable clock */
+ at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_EMAC);
+
+ /* Disable pull-ups to prevent PHY going into test mode */
+ writel(pin_to_mask(AT91_PIN_PA14) |
+ pin_to_mask(AT91_PIN_PA15) |
+ pin_to_mask(AT91_PIN_PA18),
+ pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
+
+ /* Power down ethernet */
+ pca953x_set_dir(0x28, IO_EXP_ETH_POWER, PCA953X_DIR_OUT);
+ pca953x_set_val(0x28, IO_EXP_ETH_POWER, 1);
+
+ /* Hold ethernet in reset */
+ pca953x_set_dir(0x28, IO_EXP_ETH_RESET, PCA953X_DIR_OUT);
+ pca953x_set_val(0x28, IO_EXP_ETH_RESET, 0);
+
+ /* Enable ethernet power */
+ pca953x_set_val(0x28, IO_EXP_ETH_POWER, 0);
+
+ rstc = at91_sys_read(AT91_RSTC_MR) & AT91_RSTC_ERSTL;
+
+
[U-Boot] [PATCH 1/3] Add AT91SAM9G20 to list of AT91 processors in soft_i2c driver.
Signed-off-by: Ryan Mallon --- drivers/i2c/soft_i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c index 1a1809a..0a21d02 100644 --- a/drivers/i2c/soft_i2c.c +++ b/drivers/i2c/soft_i2c.c @@ -32,7 +32,7 @@ #endif #if defined(CONFIG_AT91RM9200) || \ defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ - defined(CONFIG_AT91SAM9263) + defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) #include #include #include -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Added Bluewater Systems Snapper 9260 and 9G20 module config to top-level Makefile
Signed-off-by: Ryan Mallon --- Makefile | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index fd21ef3..7d4ba28 100644 --- a/Makefile +++ b/Makefile @@ -901,6 +901,19 @@ TNY_A9260_config : unconfig @$(MKCONFIG) -n $@ -a tny_a9260 arm arm926ejs tny_a9260 calao at91 +## Bluewater Systems Boards + +snapper9260_config \ +snapper9g20_config: unconfig + @mkdir -p $(obj)include + @if [ "$(findstring 9260, $@)" ]; then \ + echo "#define CONFIG_SNAPPER9260 1" >> $(obj)include/config.h ; \ + else \ + echo "#define CONFIG_SNAPPER9G20 1" >> $(obj)include/config.h ; \ + fi; + @$(MKCONFIG) -a snapper9260 arm arm926ejs snapper9260 bluewater at91 + + ## ARM Integrator boards - see doc/README-integrator for more info. integratorap_config\ ap_config \ -- 1.7.0.4 ___ 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 Bluewater System Snapper 9260 and 9G20 modules
Add support for Bluewater Systems Snapper9260/9G20 modules. The modules are based on the AT91SAM9260 and AT91SAM9G20 processors respectively and support NAND flash and Ethernet. Ryan Mallon (3): Add AT91SAM9G20 to list of AT91 processors in soft_i2c driver. Add support for Bluewater Systems Snapper 9260 and 9G20 modules Added Bluewater Systems Snapper 9260 and 9G20 module config to top-level Makefile Makefile | 13 ++ board/bluewater/snapper9260/Makefile | 55 + board/bluewater/snapper9260/config.mk |1 + board/bluewater/snapper9260/snapper9260.c | 177 + drivers/i2c/soft_i2c.c|2 +- 5 files changed, 247 insertions(+), 1 deletions(-) create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/config.mk create mode 100644 board/bluewater/snapper9260/snapper9260.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: add support for sh7757lcr board
Hi, 2011/1/19 Wolfgang Denk : > Dear Yoshihiro Shimoda, > > In message <4d33c15c.9030...@renesas.com> you wrote: >> The R0P7757LC0030RL board has SH7757, 256MB DDR3-SDRAM, SPI ROM, >> Ethernet, and more. >> >> This patch supports the following functions: >> - 256MB DDR3-SDRAM >> - SPI ROM >> - Ethernet >> >> Signed-off-by: Yoshihiro Shimoda >> --- >> arch/sh/include/asm/cpu_sh4.h | 2 + >> arch/sh/include/asm/cpu_sh7757.h | 263 +++ >> board/renesas/sh7757lcr/Makefile | 42 +++ >> board/renesas/sh7757lcr/config.mk | 28 ++ >> board/renesas/sh7757lcr/lowlevel_init.S | 558 >> +++ >> board/renesas/sh7757lcr/sh7757lcr.c | 436 >> board/renesas/sh7757lcr/spi-boot.c | 111 ++ >> board/renesas/sh7757lcr/u-boot.lds | 101 ++ >> boards.cfg | 1 + >> doc/README.sh7757lcr | 64 >> include/configs/sh7757lcr.h | 143 >> 11 files changed, 1749 insertions(+), 0 deletions(-) >> create mode 100644 arch/sh/include/asm/cpu_sh7757.h >> create mode 100644 board/renesas/sh7757lcr/Makefile >> create mode 100644 board/renesas/sh7757lcr/config.mk >> create mode 100644 board/renesas/sh7757lcr/lowlevel_init.S >> create mode 100644 board/renesas/sh7757lcr/sh7757lcr.c >> create mode 100644 board/renesas/sh7757lcr/spi-boot.c >> create mode 100644 board/renesas/sh7757lcr/u-boot.lds >> create mode 100644 doc/README.sh7757lcr >> create mode 100644 include/configs/sh7757lcr.h > > Entry to MAINTAINERS missing. > > ... >> +/* TMU0 */ >> +#define TSTR 0xFE430004 >> +#define TOCR 0xFE43 >> +#define TSTR0 0xFE430004 >> +#define TCOR0 0xFE430008 >> +#define TCNT0 0xFE43000C >> +#define TCR0 0xFE430010 >> +#define TCOR1 0xFE430014 >> +#define TCNT1 0xFE430018 >> +#define TCR1 0xFE43001C >> +#define TCOR2 0xFE430020 >> +#define TCNT2 0xFE430024 >> +#define TCR2 0xFE430028 >> +#define TCPR2 0xFE43002C > > Please use C structs to describe hardware registers. Some IP of SH is different every CPU. When we made structure to summarize these in, time suffers from a test and thinks that it is it for the cause of the bug. I recommend a method using address it, and to read/write of register. > > ... >> +/* DDR3IF */ >> +#define DDR3IF_BASE 0xfe80 >> +#define DBSTATE0 (DDR3IF_BASE + 0x0008) >> +#define DBSTATE1 (DDR3IF_BASE + 0x000c) >> +#define DBACEN (DDR3IF_BASE + 0x0010) >> +#define DBRFEN (DDR3IF_BASE + 0x0014) >> +#define DBCMD (DDR3IF_BASE + 0x0018) >> +#define DBWAIT (DDR3IF_BASE + 0x001c) >> +#define DBKIND (DDR3IF_BASE + 0x0020) >> +#define DBCONF (DDR3IF_BASE + 0x0024) >> +#define DBTR0 (DDR3IF_BASE + 0x0040) >> +#define DBTR1 (DDR3IF_BASE + 0x0044) >> +#define DBTR2 (DDR3IF_BASE + 0x0048) >> +#define DBTR3 (DDR3IF_BASE + 0x0050) >> +#define DBTR4 (DDR3IF_BASE + 0x0054) >> +#define DBTR5 (DDR3IF_BASE + 0x0058) >> +#define DBTR6 (DDR3IF_BASE + 0x005c) >> +#define DBTR7 (DDR3IF_BASE + 0x0060) >> +#define DBTR8 (DDR3IF_BASE + 0x0064) >> +#define DBTR9 (DDR3IF_BASE + 0x0068) >> +#define DBTR10 (DDR3IF_BASE + 0x006c) >> +#define DBTR11 (DDR3IF_BASE + 0x0070) >> +#define DBTR12 (DDR3IF_BASE + 0x0074) >> +#define DBTR13 (DDR3IF_BASE + 0x0078) >> +#define DBTR14 (DDR3IF_BASE + 0x007c) >> +#define DBTR15 (DDR3IF_BASE + 0x0080) >> +#define DBTR16 (DDR3IF_BASE + 0x0084) >> +#define DBTR17 (DDR3IF_BASE + 0x0088) >> +#define DBTR18 (DDR3IF_BASE + 0x008c) >> +#define DBTR19 (DDR3IF_BASE + 0x0090) >> +#define DBADJ0 (DDR3IF_BASE + 0x00c0) >> +#define DBADJ1 (DDR3IF_BASE + 0x00c4) >> +#define DBADJ2 (DDR3IF_BASE + 0x00c8) >> +#define DBADJ3 (DDR3IF_BASE + 0x00cc) >> +#define DBRFCNF0 (DDR3IF_BASE + 0x00e0) >> +#define DBRFCNF1 (DDR3IF_BASE + 0x00e4) >> +#define DBRFCNF2 (DDR3IF_BASE + 0x00e8) >> +#define DBCALCNF (DDR3IF_BASE + 0x00f4) >> +#define DBRNK0 (DDR3IF_BASE + 0x0100) >> +#define DBPDCNT0 (DDR3IF_BASE + 0x0200) >> +#define DBPDCNT1 (DDR3IF_BASE + 0x0204) >> +#define DBPDCNT2 (DDR3IF_BASE + 0x0208) >> +#define DBPDCNT3 (DDR3IF_BASE + 0x020c) >> +#define DBPDLCK (DDR3IF_BASE + 0x0280) >> +#define DBPDRGA (DDR3IF_BASE + 0x0290) >> +#define DBPDRGD (DDR3IF_BASE + 0x02a0) >> +#define DBBS0CNT0 (DDR3IF_BASE + 0x03
[U-Boot] [PATCH v2] add checking the CONFIG_ENV_IS_IN_SPI_FLASH in Enbedded env
Fix the problem which cannot build the U-boot, if we only set the CONFIG_ENV_IS_IN_SPI_FLASH. Signed-off-by: Yoshihiro Shimoda --- about V2: - list sorted include/environment.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/include/environment.h b/include/environment.h index 082b3e1..53d92df 100644 --- a/include/environment.h +++ b/include/environment.h @@ -107,7 +107,8 @@ extern unsigned long nand_env_oob_offset; #ifdef CONFIG_ENV_IS_EMBEDDED # if !defined(CONFIG_ENV_IS_IN_FLASH) && \ !defined(CONFIG_ENV_IS_IN_NAND) && \ - !defined(CONFIG_ENV_IS_IN_ONENAND) + !defined(CONFIG_ENV_IS_IN_ONENAND) && \ + !defined(CONFIG_ENV_IS_IN_SPI_FLASH) # error "CONFIG_ENV_IS_EMBEDDED not supported for your flash type" # endif #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Jan 24, 2011, at 2:54 PM, Timur Tabi wrote: > On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier > wrote: >> NOTE: This does not include the actual patch as it is too large for the >> mailing list (418 kB). >> >> Before this commit, weak symbols were not overridden by non-weak symbols >> found in archive libraries >> when linking with recent versions of binutils. As stated in the System V >> ABI, "the link editor does >> not extract archive members to resolve undefined weak symbols". >> >> This commit changes all Makefiles to use partial linking (ld -r) instead of >> creating library archives, >> which forces all symbols to participate in linking, allowing non-weak >> symbols to override weak symbols >> as intended. This approach is also used by Linux, from which the gmake >> function cmd_link_o_target >> (added at the end of config.mk and used in all Makefiles) is inspired. >> >> The name of each former library archive is preserved except for extensions >> which change from ".a" to >> ".o". This commit updates references accordingly where needed, in >> particular in some linker scripts. >> >> This commit reveals board configurations that exclude some module but not >> all of its dependencies; for >> example, disabling CMD_NET but not CMD_NFS results in undefined symbols at >> link time. >> >> Signed-off-by: Sebastien Carlier > > git-bisect tells me that your patch (or whatever version of it was > actually applied) causes this linker warning: > > powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o > uses hard float, libpost.o uses soft float > > See this thread for details: > http://lists.denx.de/pipermail/u-boot/2011-January/085811.html > > I have no idea how to fix this. The issue is that the code under post/lib_powerpc/fpu/* is compiled with: CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//) CFLAGS += -mhard-float -fkeep-inline-functions We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 24 Jan 2011 23:29:45 +0100
Wolfgang Denk wrote:
> Dear Haiying Wang,
>
> In message <1295907459.2051.158.camel@haiying-laptop> you wrote:
> >
> > > It's not the name. But you use it ina few places here, buth then hard
> > > encode "tpl" in a number of other paces there. Which means that you
> > > cannot change TPL_BOOT to any other value, or building would break.
> > > So why do we need this variable?
> > It follows the same usage of NAND_SPL.
>
> Ah. I see. Well, so NAND_SPL needs fixing as well :-(
Agreed, it seems like just hardcoding the target name would work fine,
be clearer, and avoid relying on unportable make behavior.
> > > Sorry, I cannot follow - which reset? which semicolon?
> >
> > Sorry, :%s/reset/rest/. The semicolon is the same one in your previous
> > comments. I meant the part:
> > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend
> > $(MAKE) -C tpl/board/$(BOARDDIR) all
>
> Ah, I see what you mean. But that's a colon (':') - a semicolon if a
> ';'.
You called it a semicolon first. :-)
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
---
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
---
you could create a file named uEnv.txt and use that instead of boot.scr:
---
dvimode=1024x768-16@60
uenvcmd=run loaduimage; run mmcboot
---
The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
was loaded. If uenvcmd doesn't exist the default boot sequence will be started,
therefore you could just use
---
dvimode=1024x768-16@60
---
as uEnv.txt because loaduimage and mmcboot is part of the default boot sequence.
For backwards compatibility the use of boot.scr is still supported.
Signed-off-by: Alexander Holler
---
include/configs/omap3_beagle.h | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 5cfa4cb..0214c7f 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -218,6 +218,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t $loadaddr $filesize\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
@@ -229,12 +232,24 @@
#define CONFIG_BOOTCOMMAND \
"if mmc rescan ${mmcdev}; then " \
- "if run loadbootscript; then " \
- "run bootscript; " \
+ "if run loadbootenv; then " \
+ "run importbootenv;" \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...;run uenvcmd;" \
+ "else " \
+ "if run loaduimage; then " \
+ "run mmcboot; " \
+ "else run nandboot; " \
+ "fi; " \
+ "fi; " \
"else " \
- "if run loaduimage; then " \
- "run mmcboot; " \
- "else run nandboot; " \
+ "if run loadbootscript; then " \
+ "run bootscript; " \
+ "else " \
+ "if run loaduimage; then " \
+ "run mmcboot; " \
+ "else run nandboot; " \
+ "fi; " \
"fi; " \
"fi; " \
"else run nandboot; fi"
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang,
In message <1295907459.2051.158.camel@haiying-laptop> you wrote:
>
> > It's not the name. But you use it ina few places here, buth then hard
> > encode "tpl" in a number of other paces there. Which means that you
> > cannot change TPL_BOOT to any other value, or building would break.
> > So why do we need this variable?
> It follows the same usage of NAND_SPL.
Ah. I see. Well, so NAND_SPL needs fixing as well :-(
> > Sorry, I cannot follow - which reset? which semicolon?
>
> Sorry, :%s/reset/rest/. The semicolon is the same one in your previous
> comments. I meant the part:
> : $(TIMESTAMP_FILE) $(VERSION_FILE) depend
> $(MAKE) -C tpl/board/$(BOARDDIR) all
Ah, I see what you mean. But that's a colon (':') - a semicolon if a
';'.
> If it is as you thought, then how the platforms will be built without
> NAND_SPL or ONENAND_IPL is not defined?
I have to admit that I wasnot aware that NAND_SPL was usign all teh
same constructs. We should clean all this up.
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
For every complex problem, there is a solution that is simple, neat,
and wrong. - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 2011-01-24 at 23:09 +0100, Wolfgang Denk wrote: > Dear Haiying Wang, > > In message <1295906076.2051.127.camel@haiying-laptop> you wrote: > > > > > What I do not understand is what the TPL_BOOT variable in the > > > Makefile is good for. I cannot understand the current use. > > > > Well, it was used to generate the tpl image under tpl/ directory. Maybe > > TPL_BOOT is a bad name here, I just thought it was too simple to use TPL. > > It's not the name. But you use it ina few places here, buth then hard > encode "tpl" in a number of other paces there. Which means that you > cannot change TPL_BOOT to any other value, or building would break. > So why do we need this variable? It follows the same usage of NAND_SPL. > > > > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > > > > and this rule will probably cause a build error, doesn't it? > > > > No, I don't think there is a build error. > > > > > > WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not > > > defined, which results in this make rule: > > > > > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > i. e. there would be no target name befoe the semicolon. > > If TPL_BOOT here is not defined, the reset(after semicolon) will not be > > executed, just like NAND_SPL and ONENAND_IPL etc. > > Sorry, I cannot follow - which reset? which semicolon? Sorry, :%s/reset/rest/. The semicolon is the same one in your previous comments. I meant the part: : $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C tpl/board/$(BOARDDIR) all If it is as you thought, then how the platforms will be built without NAND_SPL or ONENAND_IPL is not defined? Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Pantheon: Add Board Support for Marvell dkb board
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Wednesday, January 19, 2011 12:13 AM > To: Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Yu Tang; > Ashish Karkare; Prabhanjan Sarnaik; Lei Wen > Subject: [PATCH 5/5] Pantheon: Add Board Support for Marvell dkb board > > DKB is a Development Board for PANTHEON TD/TTC(pxa920/pxa910) with > * Processor upto 806Mhz > * LPDDR1/2 > * x8/x16 SLC/MLC NAND > * Footprints for eMMC & MMC x8 card > > With Peripherals: > * Parallel LCD I/F > * Audio codecs (88PM8607) > * MIPI CSI-2 camera > * Marvell 88W8787 802.11n/BT module > * Marvell 2G/3G RF > * Dual analog mics & speakers, headset jack, LED, ambient > * USB2.0 HS host, OTG (mini AB) > * GPIO, GPIO expander with DIP switches for easier selection > * UART serial over USB, CIR > > This patch adds basic board support with DRAM and UART functionality > > Signed-off-by: Lei Wen > --- > V2: > > V3: > Fix copyright claim year. > > V4: > Add change log to each patch. > > V5: > Remove additional CONFIG_SYS_NS16550_COM1 definition in dkb.h Hi Lei This patch cannot be cleanly applied, please pull u-boot-marvell.git first Also please resolve below warnings. [prafulla@pe-dt061 u-boot-marvell.git]$ cat warn.txt dkb.c: In function board_init: dkb.c:51: warning: implicit declaration of function panth_sdram_base Regards.. Prafulla. . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 2011-01-24 at 13:49 +0100, Wolfgang Denk wrote: > > > > > > > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > > > > +TPL_BOOT = tpl > > > > +endif > > > > > > I don't understand what the "TPL_BOOT" is good for, or how it's > > > supposed to work. > > TPL_BOOT works like NAND_SPL but after NAND_SPL is executed. It is a > > middle stage boot loader to balance the 4K nand spl limitation which can > > not include ddr spd code and the 256K L2 SRAM size which can not > > accommodate the final uboot image on some Freescale Qoriq P1 platforms. > > Yes, I understand what you are atempting to do. > > What I do not understand is what the TPL_BOOT variable in the > Makefile is good for. I cannot understand the current use. Well, it was used to generate the tpl image under tpl/ directory. Maybe TPL_BOOT is a bad name here, I just thought it was too simple to use TPL. > > The main purpose of tpl is to initialize the ddr with spd code in l2 > > sram then load the final uboot image to ddr. The reason to call tpl is > > because it runs after spl, the Second Program Loader. My original patch > > used CONFIG_MIDDLE_STAGE_SRAM_BOOT but you recommended to use > > CONFIG_SYS_2ND_STAGE_BOOT(http://lists.denx.de/pipermail/u-boot/2010-August/075653.html). > > However, 2ND STAGE is not correct here since it runs after SPL. > > > > > > ifeq ($(CONFIG_NAND_U_BOOT),y) > > > > NAND_SPL = nand_spl > > > > U_BOOT_NAND = $(obj)u-boot-nand.bin > > > > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > > > > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > > > > > > > -$(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin > > > > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > > > > $(obj)u-boot-nand.bin > > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > > and this rule will probably cause a build error, doesn't it? > > No, I don't think there is a build error. > > WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not > defined, which results in this make rule: > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > $(MAKE) -C tpl/board/$(BOARDDIR) all > > i. e. there would be no target name befoe the semicolon. If TPL_BOOT here is not defined, the reset(after semicolon) will not be executed, just like NAND_SPL and ONENAND_IPL etc. > > > Has this code ever been tested? > > Yes, I tested it on P1021MDS board, and also built for other 85xx > > NAND_config without error. > > Did you run a "MAKEALL ppc", i. e. build for all PPC board, not only > NAND booting versions? No, I didn't. I will do it and let you know. But I did pass the build for other 85xx non-nand booting version. > > > > + CONFIG_TPL_U_BOOT > > > > + > > > > + Builds a U-Boot image that contains a loader stub > > > > (tertiary > > > > + program loader -- TPL) that boots out of some type of > > > > RAM, > > > > + after being loaded by an SPL or similar > > > > platform-specific > > > > + mechanism. This symbol will be set in all build phases. > > > > + > > > > + CONFIG_TPL_BOOT > > > > + > > > > + This is set by the build system when compiling code to > > > > go into > > > > + the TPL. It is not set when building the code that the > > > > TPL > > > > + loads, or when building the SPL. > > > > > > Can we not do with a single variable definition? > > > > I did not get it. Could you please give a recommendation? > > Well, I see a pollution with such CONFIG_ settings. I don;t have a > solution ready to recommend, but if you can find a way not to define > so many different settings for a single purpose that wouldbe great. > Will apply Scott's recommendation. Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang, In message <1295906076.2051.127.camel@haiying-laptop> you wrote: > > > What I do not understand is what the TPL_BOOT variable in the > > Makefile is good for. I cannot understand the current use. > > Well, it was used to generate the tpl image under tpl/ directory. Maybe > TPL_BOOT is a bad name here, I just thought it was too simple to use TPL. It's not the name. But you use it ina few places here, buth then hard encode "tpl" in a number of other paces there. Which means that you cannot change TPL_BOOT to any other value, or building would break. So why do we need this variable? > > > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > > > and this rule will probably cause a build error, doesn't it? > > > No, I don't think there is a build error. > > > > WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not > > defined, which results in this make rule: > > > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > i. e. there would be no target name befoe the semicolon. > If TPL_BOOT here is not defined, the reset(after semicolon) will not be > executed, just like NAND_SPL and ONENAND_IPL etc. Sorry, I cannot follow - which reset? which semicolon? 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 Quantum Mechanics is God's version of "Trust me." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm: a320evb: fixes for relocation support
Le 20/12/2010 10:07, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang
>
> * add CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR
> * do not update gd->bd in dram_init() because bd is unavailable then
> * move CONFIG_SYS_TEXT_BASE from config.mk to a320evb.h
> * remove config.mk
>
> Signed-off-by: Po-Yu Chuang
> ---
> v2:
> rebase
> remove config.mk
>
> board/faraday/a320evb/a320evb.c |3 +--
> board/faraday/a320evb/config.mk | 35 ---
> include/configs/a320evb.h | 14 ++
> 3 files changed, 11 insertions(+), 41 deletions(-)
> delete mode 100644 board/faraday/a320evb/config.mk
>
> diff --git a/board/faraday/a320evb/a320evb.c b/board/faraday/a320evb/a320evb.c
> index 85b11b9..b9343e4 100644
> --- a/board/faraday/a320evb/a320evb.c
> +++ b/board/faraday/a320evb/a320evb.c
> @@ -46,8 +46,7 @@ int dram_init(void)
>
> actual_size = get_ram_size((void *)sdram_base, expected_size);
>
> - gd->bd->bi_dram[0].start = sdram_base;
> - gd->bd->bi_dram[0].size = actual_size;
> + gd->ram_size = actual_size;
>
> if (expected_size != actual_size)
> printf("Warning: Only %lu of %lu MiB SDRAM is working\n",
> diff --git a/board/faraday/a320evb/config.mk b/board/faraday/a320evb/config.mk
> deleted file mode 100644
> index b751d0d..000
> --- a/board/faraday/a320evb/config.mk
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -#
> -# (C) Copyright 2009 Faraday Technology
> -# Po-Yu Chuang
> -#
> -# 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
> -#
> -
> -# Faraday A320 board with FA526/FA626TE/ARM926EJ-S cpus
> -#
> -# see http://www.faraday-tech.com/ for more information
> -
> -# A320 has 1 bank of 64 MB DRAM
> -#
> -# 1000' to 1400'
> -#
> -# Linux-Kernel is expected to be at 1000'8000, entry 1000'8000
> -#
> -# we load ourself to 13f8'
> -#
> -# download area is 1200'
> -
> -CONFIG_SYS_TEXT_BASE = 0x13f8
> diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h
> index f67cf06..27f137f 100644
> --- a/include/configs/a320evb.h
> +++ b/include/configs/a320evb.h
> @@ -138,15 +138,21 @@
> #define PHYS_SDRAM_10x1000 /* SDRAM Bank #1 */
> #define PHYS_SDRAM_1_SIZE 0x0400 /* 64 MB */
>
> +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1
> +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000
> - \
> + GENERATED_GBL_DATA_SIZE)
> +
> /*
>* Load address and memory test area should agree with
>* board/faraday/a320/config.mk. Be careful not to overwrite U-boot itself.
>*/
> -#define CONFIG_SYS_LOAD_ADDR 0x1200
> +#define CONFIG_SYS_LOAD_ADDR (PHYS_SDRAM_1 + 0x200)
>
> /* memtest works on 63 MB in DRAM */
> -#define CONFIG_SYS_MEMTEST_START 0x1000
> -#define CONFIG_SYS_MEMTEST_END 0x13F0
> +#define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1
> +#define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + 0x3F0)
> +
> +#define CONFIG_SYS_TEXT_BASE 0
>
> /*---
>* Static memory controller configuration
> @@ -215,7 +221,7 @@
>
> /* environments */
> #define CONFIG_ENV_IS_IN_FLASH
> -#define CONFIG_ENV_ADDR 0x0006
> +#define CONFIG_ENV_ADDR (PHYS_FLASH_1 + 0x6)
> #define CONFIG_ENV_SIZE 0x2
>
> #endif /* __CONFIG_H */
As this is a fix, applied to u-boot-arm.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
Dear Tom Warren, In message you wrote: > > >> >> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300) > >> >> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400) > >> >> +#define NV_PA_PMC_BASE 0x7000E400 > >> > > >> > what is the purpose of NV_PA prefix here? > >> NV_Physical_Address - a base address of a HW block (Power Management > >> Cntrlr, etc.) > > > > Well, the NV_ part is not needed, right? > True. I can remove it, but why? It designates this as a > NVIDIA-specific define. I see the same thing > in AT91, OMAP, NetARM, DaVinci, IMX files, etc. etc. OK, I don't insist. 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 A weak mind is like a microscope, which magnifies trifling things, but cannot receive great ones. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm: a320 timer: move static data to global_data struct
Le 20/12/2010 10:00, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang
>
> timer.c used static data and are called before relocation.
> Move all static variables into global_data structure. Also cleanup
> timer.c from unused stubs and make it truly use 64 bit tick values.
>
> Based on Reinhard Meyer's patch
> 5dca710a3d7703e41da0e9894f2d71f9e25bea6b
>
> Signed-off-by: Po-Yu Chuang
> ---
> v2:
> rebase
> use gd->timer_rate_hz.
> remove unused global variable timestamp and lastdec.
> move register bases to local variables
>
> arch/arm/cpu/arm920t/a320/timer.c | 147
> ++---
> 1 files changed, 56 insertions(+), 91 deletions(-)
>
> diff --git a/arch/arm/cpu/arm920t/a320/timer.c
> b/arch/arm/cpu/arm920t/a320/timer.c
> index d2e316f..5af94c2 100644
> --- a/arch/arm/cpu/arm920t/a320/timer.c
> +++ b/arch/arm/cpu/arm920t/a320/timer.c
> @@ -18,21 +18,36 @@
>*/
>
> #include
> +#include
> #include
> #include
> #include
>
> -static ulong timestamp;
> -static ulong lastdec;
> -
> -static struct fttmr010 *tmr = (struct fttmr010 *)CONFIG_FTTMR010_BASE;
> -static struct ftpmu010 *pmu = (struct ftpmu010 *)CONFIG_FTPMU010_BASE;
> +DECLARE_GLOBAL_DATA_PTR;
>
> #define TIMER_CLOCK 32768
> #define TIMER_LOAD_VAL 0x
>
> +static inline unsigned long long tick_to_time(unsigned long long tick)
> +{
> + tick *= CONFIG_SYS_HZ;
> + do_div(tick, gd->timer_rate_hz);
> +
> + return tick;
> +}
> +
> +static inline unsigned long long usec_to_tick(unsigned long long usec)
> +{
> + usec *= gd->timer_rate_hz;
> + do_div(usec, 100);
> +
> + return usec;
> +}
> +
> int timer_init(void)
> {
> + struct fttmr010 *tmr = (struct fttmr010 *)CONFIG_FTTMR010_BASE;
> + struct ftpmu010 *pmu = (struct ftpmu010 *)CONFIG_FTPMU010_BASE;
> unsigned int oscc;
> unsigned int cr;
>
> @@ -76,118 +91,68 @@ int timer_init(void)
> cr |= FTTMR010_TM3_ENABLE;
> writel(cr,&tmr->cr);
>
> - /* init the timestamp and lastdec value */
> - reset_timer_masked();
> + gd->timer_rate_hz = TIMER_CLOCK;
> + gd->tbu = gd->tbl = 0;
>
> return 0;
> }
>
> /*
> - * timer without interrupts
> - */
> -
> -/*
> - * reset time
> + * Get the current 64 bit timer tick count
>*/
> -void reset_timer_masked(void)
> +unsigned long long get_ticks(void)
> {
> - /* capure current decrementer value time */
> - lastdec = readl(&tmr->timer3_counter) / (TIMER_CLOCK / CONFIG_SYS_HZ);
> - timestamp = 0; /* start "advancing" time stamp from 0 */
> -
> - debug("%s(): lastdec = %lx\n", __func__, lastdec);
> -}
> + struct fttmr010 *tmr = (struct fttmr010 *)CONFIG_FTTMR010_BASE;
> + ulong now = TIMER_LOAD_VAL - readl(&tmr->timer3_counter);
>
> -void reset_timer(void)
> -{
> debug("%s()\n", __func__);
> - reset_timer_masked();
> -}
>
> -/*
> - * return timer ticks
> - */
> -ulong get_timer_masked(void)
> -{
> - /* current tick value */
> - ulong now = readl(&tmr->timer3_counter) / (TIMER_CLOCK / CONFIG_SYS_HZ);
> -
> - debug("%s(): now = %lx, lastdec = %lx\n", __func__, now, lastdec);
> -
> - if (lastdec>= now) {
> - /*
> - * normal mode (non roll)
> - * move stamp fordward with absoulte diff ticks
> - */
> - timestamp += lastdec - now;
> - } else {
> - /*
> - * we have overflow of the count down timer
> - *
> - * nts = ts + ld + (TLV - now)
> - * ts=old stamp, ld=time that passed before passing through -1
> - * (TLV-now) amount of time after passing though -1
> - * nts = new "advancing time stamp"...it could also roll and
> - * cause problems.
> - */
> - timestamp += lastdec + TIMER_LOAD_VAL - now;
> - }
> -
> - lastdec = now;
> -
> - debug("%s() returns %lx\n", __func__, timestamp);
> -
> - return timestamp;
> -}
> -
> -/*
> - * return difference between timer ticks and base
> - */
> -ulong get_timer(ulong base)
> -{
> - debug("%s(%lx)\n", __func__, base);
> - return get_timer_masked() - base;
> -}
> -
> -void set_timer(ulong t)
> -{
> - debug("%s(%lx)\n", __func__, t);
> - timestamp = t;
> + /* increment tbu if tbl has rolled over */
> + if (now< gd->tbl)
> + gd->tbu++;
> + gd->tbl = now;
> + return (((unsigned long long)gd->tbu)<< 32) | gd->tbl;
> }
>
> /* delay x useconds AND preserve advance timestamp value */
> void __udelay(unsigned long usec)
> {
> - long tmo = usec * (TIMER_CLOCK / 1000) / 1000;
> - unsigned long now, last = readl(&tmr->timer3_counter);
> -
> - debug("%s(%lu)\n", __func__, usec);
> - while (tmo> 0) {
> - now = readl(&tmr->timer3_counter);
> - if (now> last) /* count down timer overflow */
> - tmo -= TIMER_LOAD_VAL + last - now;
> - else
>
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier wrote: > NOTE: This does not include the actual patch as it is too large for the > mailing list (418 kB). > > Before this commit, weak symbols were not overridden by non-weak symbols > found in archive libraries > when linking with recent versions of binutils. As stated in the System V > ABI, "the link editor does > not extract archive members to resolve undefined weak symbols". > > This commit changes all Makefiles to use partial linking (ld -r) instead of > creating library archives, > which forces all symbols to participate in linking, allowing non-weak symbols > to override weak symbols > as intended. This approach is also used by Linux, from which the gmake > function cmd_link_o_target > (added at the end of config.mk and used in all Makefiles) is inspired. > > The name of each former library archive is preserved except for extensions > which change from ".a" to > ".o". This commit updates references accordingly where needed, in particular > in some linker scripts. > > This commit reveals board configurations that exclude some module but not all > of its dependencies; for > example, disabling CMD_NET but not CMD_NFS results in undefined symbols at > link time. > > Signed-off-by: Sebastien Carlier git-bisect tells me that your patch (or whatever version of it was actually applied) causes this linker warning: powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard float, libpost.o uses soft float See this thread for details: http://lists.denx.de/pipermail/u-boot/2011-January/085811.html I have no idea how to fix this. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Peter,
On Mon, Jan 24, 2011 at 12:14 PM, Peter Tyser wrote:
>
>
>> I see what you're talking about now - I've got uart.c in 2 patch files -
>> created
>> in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
>> happened when I applied my V4 patches to a new branch to get the V5 patchset
>> built. I'll fix it and resubmit.
>>
>> As to 0002 not adding serial port support for Tegra2, that's all it does -
>> adds
>> TEGRA2 defines to serial.h/serial.c for the eserial* tables, and then adds
>> code to turn on Tegra2-specific UART HW. If I remove any mention of uart.c
>> in patch 0001 (add basic Tegra2 support), then does patch 0002 make
>> sense to you?
>
> Yeah, that'd make more sense. Patch 2 would just contain:
> common/serial.c | 3 +-
> drivers/serial/Makefile | 1 +
> drivers/serial/serial_tegra2.c | 205 ++
> drivers/serial/serial_tegra2.h | 49
> include/serial.h | 3 +-
>
Exactly what I was thinking. I'll try to get it right in patch V6.
>> >> >
>> >> >
>> >> > +void uart_init(void)
>> >> >> +{
>> >> >> + /* Init each UART - there may be more than 1 on a board/build */
>> >> >> +#if (CONFIG_TEGRA2_ENABLE_UARTA)
>> >> >> + init_uart();
>> >> >> +#endif
>> >> >> +#if (CONFIG_TEGRA2_ENABLE_UARTD)
>> >> >> + init_uart();
>> >> >> +#endif
>> >> >> +}
>> >> >
>> >> > How about:
>> >> > #if defined(CONFIG_TEGRA2_ENABLE_UARTA) ||
>> >> > defined(CONFIG_TEGRA2_ENABLE_UARTD)
>> >> > init_uart();
>> >> > #endif
>> >> That won't work for a board like Harmony where the developer wants
>> >> both UARTs active, since uart_init is only called once.
>> >
>> > Why should init_uart() be called two times? It looks to initialize both
>> > ports, meaning it should only be called once, right?
>> Correct, again (need more coffee!) Your if defined construct wouldn't work
>> as written, though, because CONFIG_TEGRA2_ENABLE_UARTx is always
>> defined (as 0 or 1). I'd have to rework it.
>
> You could also just get rid of uart_init() altogether and rename
> init_uart() to uart_init(). That would get rid of some idefs and
> simplify the flow.
Yeah, I saw that as I was cleaning up the indentation & reworking the
code to compile
with both UARTs defined. I'll get rid of uart_init (renamed to
init_uart). Thanks.
>
> Best,
> Peter
Thanks,
Tom
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
Wolfgang (& Mike), On Mon, Jan 24, 2011 at 12:00 PM, Wolfgang Denk wrote: > Dear Tom Warren, > > In message you > wrote: >> > ... >> >> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300) >> >> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400) >> >> +#define NV_PA_PMC_BASE 0x7000E400 >> > >> > what is the purpose of NV_PA prefix here? >> NV_Physical_Address - a base address of a HW block (Power Management >> Cntrlr, etc.) > > Well, the NV_ part is not needed, right? True. I can remove it, but why? It designates this as a NVIDIA-specific define. I see the same thing in AT91, OMAP, NetARM, DaVinci, IMX files, etc. etc. > > > Best regards, > > Wolfgang Denk Thanks, Tom > > -- > 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 > Writing a book is like washing an elephant: there's no good place to > begin or end, and it's hard to keep track of what you've already > covered. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Scott Wood, In message <20110124133835.5b26b...@udp111988uds.am.freescale.net> you wrote: > > Now, the naming could be clearer. Changing CONFIG_TPL_BOOT into > CONFIG_TPL would make it look more like the existing SPL names. Or we > could do something like: > > CONFIG_HAS_SPL /* set in all of U-Boot when an SPL is used */ > CONFIG_IN_SPL /* set only when building the SPL */ > CONFIG_HAS_TPL /* set in all of U-Boot when a TPL is used */ > CONFIG_IN_TPL /* set only when building the TPL */ I like that much better. Thanks. 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 moral of the story is: "Don't stop to tighten your shoe laces during the Olympics 100m finals". - Kevin Jones in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message <4d3dd1ec.7010...@arcor.de> you wrote: > > >> C version: > >>textdata bss dec hex filename > >> 202862 18912 266456 488230 77326 u-boot > >> > >> ASM version: > >>textdata bss dec hex filename > >> 203798 18912 266288 488998 77626 u-boot > > > > How exactly did you measure the speed improvement? > > I inserted a printf before and after calls to these functions with sizes > of 1MB or more each. I then measured the times between these printfs > using grabserial (http://elinux.org/Grabserial). In both cases caches > where enabled. > > To be precise: As memset test case I used the memset(.., 0, ..) of the > malloc pool (which was 4MB in my case) and a memcpy from flash to RAM > which I inserted in cmd_bootm.c of about 2.2MB (see RFC patch > http://patchwork.ozlabs.org/patch/79480/ for exact location of the memcpy). OK - so which results do you see in reallife use, say when loading and booting an OS? How much boot time can be saved? > Do you think a factor of 2 is not possible against the C version? Maybe > I have done something wrong while measuring theses times. From my point > of view it should be possible to get such improvements as the code takes > cache alignment into account and also uses the PLD instruction. I don;t doubt your measurements. But this being an optimization approach, it seems appropriate to check wether we are really optimizing a hot spot, and if the measured results can be generalized. I guess the speed improvemnt you see for a few large copy operations is just one side - probably there will be slower excution (due to the effort to set up the operations) for the (many more frequent) small operations. In addition, there is an increase of the memory footprint of nearly 1 kB. I think additional measuremnts need to be done - for example, we should check how the execution times change for typical operations like TFTP download, reading from NAND flash and MMC/SDcard, booting a Linux kernel etc. Also, it should be possible to enable this feature consditionally, so users can decide wether speed or size is more important in their configurations. > I can do some additional measurements tomorrow on two systems (jadecpu > with a 32Bit@166MHz DDR2 memory and a imx25 based on with 16Bit@133MHz > LPDDR) and come up with some exact numbers. Maybe you can give some more > hints what and how the improvements of this patch can be measured. See above. Thanks. 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 Egotist: A person of low taste, more interested in himself than in me. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Atmel_usba_udc working (sort of)
Hi,
I sort of have USB device functionality working on the SAM9G45.
I mention "sort of" because I stripped the Linux driver down to a bare minimum
I would say.
It boots a kernel image over USB using tftpboot.
As mentioned before I disabled all DMA and have implemented the driver with
bits and pieces from the at91_udc driver (mainly requests part). This mainly
because I found the at91_udc driver more easy to understand.
Further more I have set up single buffer for the bulk endpoints.
What I got working is that I use tftboot to boot my kernel image, which
probably means it does work reasonable enough for initial testing. I tested in
a dozen times and it seems to work well.
I still need to check some USB traces, but I think my main problem (NYET) was
caused by enabling the debugging in the driver I think so I ran into some
timing issues. This will be further investigated but I run a bit short on time
in my project, so I'm not sure if I can do it at this point (time issue).
Anyway. I'm not sure about one thing since I'm not as familiar with u-boot
startup than most people on this list.
I currently have this set :
int board_eth_init(bd_t *bis)
{
int rc = -1;
#if defined(CONFIG_USB_ETHER) && defined(CONFIG_USB_GADGET_ATMEL_USBA)
printf("USB probe \n");
rc = usba_udc_probe(&brd);
if (!rc)
rc = usb_eth_initialize(bis);
return rc;
}
Now, someone (I think Albert) mentioned that this would not be preferred, but
I have no idea what IS preferred. I would like to keep things as clean as
possible, so I hope for some advice on this.
Also, I want to test the driver with DMA enabled, but I'm not sure if I can
mange that because of a very tight time schedule (things must be working end
of this week basically). I also wonder whether my current implementation
wouldn't be preferred for U-boot as it is more compact than the Linux driver.
Somehow I like this more for u-boot even though it may be a little slower in
it's communication speed as I think for u-boot robustness and small code
matter more than speed.
I have still a lot to test I guess, but the initial work is there. I also like
to commit my code at some point this week or next week (after that I'm away on
business and have no idea when I return - maybe months later). So, even when
I think the code can be improved a lot, I want to post the current code
already. Is that fine ?
Below is an output of the current status (tested with Fedora core 14 as host)
Best regards,
Marcel
U-Boot 2010.12-09833-gb2c475d-dirty (Jan 24 2011 - 20:23:37)
CPU: AT91SAM9G45
Crystal frequency: 12 MHz
CPU clock: 400 MHz
Master clock : 133.333 MHz
dram init
DRAM: 128 MiB
USB host init
FLASH: 1 MiB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Net: USB probe
USB_ETH_INITIALIZE
usb_ether
Hit any key to stop autoboot: 0
Sam9g45> tftpboot uImage
using atmel_usba_udc, OUT ep2 IN ep1 STATUS ep3
MAC 00:1f:e5:00:1c:7c
HOST MAC 0a:fa:63:8b:e8:0a
ETH set config
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
Issue start status
USB network up!
Using usb_ether device
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename 'uImage'.
Load address: 0x7040
Loading: #
#
done
Bytes transferred = 148 (196e58 hex)
Automatic boot of image at addr 0x7040 ...
## Booting kernel from Legacy Image at 7040 ...
Image Name: Linux-2.6.33-rc4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:1666584 Bytes = 1.6 MiB
Load Address: 70008000
Entry Point: 70008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.33-rc4 (marcel@p4) (gcc version 4.3.2 (GCC) ) #1 Sun Jan 23
15:25:19 CET 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] board/Marvell/DB64360
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Tim Liu > Sent: Monday, January 24, 2011 11:27 AM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] board/Marvell/DB64360 > > Hi, > > > > I am new to the list, any info. Or help is appreciated! > > > > I went through C code of Ethernet initialization of U-boot(version > u-boot-2010_09.tar.gz ) in the board of db64360 under the board name > Marvell and found that there maybe is an obvious coding error in the > function void mv64360_eth_initialize(bd_t *bis) located in mv_eth.c. The > line is underscored. > > The line should be: port_private = calloc (sizeof (struct > mv64360_eth_priv), 1), because it make next line pointless: > ethernet_private->port_private = (void *)port_private; > ethernet_private->port_private should point to mv64360_eth_priv, but > actually point to (*ethernet_private)ETH_PORT_INFO in the code. > This is a very old board support and not up to the mark (maintained). I don't have hardware, if there are no users, we can remove it's support. Copying Josh (Maintainer of this board) Hi Josh What do you think? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] board/Marvell/DB64360
Hi,
I am new to the list, any info. Or help is appreciated!
I went through C code of Ethernet initialization of U-boot(version
u-boot-2010_09.tar.gz ) in the board of db64360 under the board name
Marvell and found that there maybe is an obvious coding error in the
function void mv64360_eth_initialize(bd_t *bis) located in mv_eth.c. The
line is underscored.
The line should be: port_private = calloc (sizeof (struct
mv64360_eth_priv), 1), because it make next line pointless:
ethernet_private->port_private = (void *)port_private;
ethernet_private->port_private should point to mv64360_eth_priv, but
actually point to (*ethernet_private)ETH_PORT_INFO in the code.
Thanks
Tim Liu
Code snippet from mv64360_eth_initialize:
ethernet_private = calloc (sizeof (*ethernet_private), 1);
dev->priv = (void *) ethernet_private;
if (!ethernet_private) {
printf ("%s: %s allocation failure, %s\n",
__FUNCTION__, dev->name,
"Private Device Structure");
free (dev);
return;
}
/* start with an zeroed ETH_PORT_INFO */
memset (ethernet_private, 0, sizeof (ETH_PORT_INFO));
memcpy (ethernet_private->port_mac_addr, dev->enetaddr, 6);
/* set pointer to memory for stats data structure etc... */
port_private = calloc (sizeof (*ethernet_private), 1);
//should be sizeof (struct mv64360_eth_priv)
ethernet_private->port_private = (void *)port_private;
if (!port_private) {
printf ("%s: %s allocation failure, %s\n",
__FUNCTION__, dev->name,
"Port Private Device Structure");
free (ethernet_private);
free (dev);
return;
}
port_private->stats =
calloc (sizeof (struct net_device_stats), 1);
if (!port_private->stats) {
printf ("%s: %s allocation failure, %s\n",
__FUNCTION__, dev->name,
"Net stat Structure");
free (port_private);
free (ethernet_private);
free (dev);
return;
}
memset (ethernet_private->port_private, 0,
sizeof (struct mv64360_eth_priv));
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 24 Jan 2011 13:49:19 +0100 Wolfgang Denk wrote: > > > > + CONFIG_TPL_U_BOOT > > > > + > > > > + Builds a U-Boot image that contains a loader stub > > > > (tertiary > > > > + program loader -- TPL) that boots out of some type of > > > > RAM, > > > > + after being loaded by an SPL or similar > > > > platform-specific > > > > + mechanism. This symbol will be set in all build phases. > > > > + > > > > + CONFIG_TPL_BOOT > > > > + > > > > + This is set by the build system when compiling code to > > > > go into > > > > + the TPL. It is not set when building the code that the > > > > TPL > > > > + loads, or when building the SPL. > > > > > > Can we not do with a single variable definition? > > > > I did not get it. Could you please give a recommendation? > > Well, I see a pollution with such CONFIG_ settings. I don;t have a > solution ready to recommend, but if you can find a way not to define > so many different settings for a single purpose that wouldbe great. They mean different things. We can't "do with a single variable definition" in the current NAND SPL. Why would TPL be any different? Now, the naming could be clearer. Changing CONFIG_TPL_BOOT into CONFIG_TPL would make it look more like the existing SPL names. Or we could do something like: CONFIG_HAS_SPL /* set in all of U-Boot when an SPL is used */ CONFIG_IN_SPL /* set only when building the SPL */ CONFIG_HAS_TPL /* set in all of U-Boot when a TPL is used */ CONFIG_IN_TPL /* set only when building the TPL */ -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux
Am 24.01.2011 17:13, schrieb Wolfgang Denk: > Dear Matthias Weisser, > > In message <1295884607-9044-1-git-send-email-weiss...@arcor.de> you wrote: >> Using optimized versions of memset and memcpy from linux brings a quite >> noticeable speed (x2 or better) improvement for these two functions. >> >> Size impact: >> >> C version: >>textdata bss dec hex filename >> 202862 18912 266456 488230 77326 u-boot >> >> ASM version: >>textdata bss dec hex filename >> 203798 18912 266288 488998 77626 u-boot > > How exactly did you measure the speed improvement? I inserted a printf before and after calls to these functions with sizes of 1MB or more each. I then measured the times between these printfs using grabserial (http://elinux.org/Grabserial). In both cases caches where enabled. To be precise: As memset test case I used the memset(.., 0, ..) of the malloc pool (which was 4MB in my case) and a memcpy from flash to RAM which I inserted in cmd_bootm.c of about 2.2MB (see RFC patch http://patchwork.ozlabs.org/patch/79480/ for exact location of the memcpy). Do you think a factor of 2 is not possible against the C version? Maybe I have done something wrong while measuring theses times. From my point of view it should be possible to get such improvements as the code takes cache alignment into account and also uses the PLD instruction. I can do some additional measurements tomorrow on two systems (jadecpu with a 32Bit@166MHz DDR2 memory and a imx25 based on with 16Bit@133MHz LPDDR) and come up with some exact numbers. Maybe you can give some more hints what and how the improvements of this patch can be measured. Matthias Weißer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
> I see what you're talking about now - I've got uart.c in 2 patch files -
> created
> in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
> happened when I applied my V4 patches to a new branch to get the V5 patchset
> built. I'll fix it and resubmit.
>
> As to 0002 not adding serial port support for Tegra2, that's all it does -
> adds
> TEGRA2 defines to serial.h/serial.c for the eserial* tables, and then adds
> code to turn on Tegra2-specific UART HW. If I remove any mention of uart.c
> in patch 0001 (add basic Tegra2 support), then does patch 0002 make
> sense to you?
Yeah, that'd make more sense. Patch 2 would just contain:
common/serial.c|3 +-
drivers/serial/Makefile|1 +
drivers/serial/serial_tegra2.c | 205 ++
drivers/serial/serial_tegra2.h | 49
include/serial.h |3 +-
> >> >
> >> >
> >> > +void uart_init(void)
> >> >> +{
> >> >> + /* Init each UART - there may be more than 1 on a board/build */
> >> >> +#if (CONFIG_TEGRA2_ENABLE_UARTA)
> >> >> + init_uart();
> >> >> +#endif
> >> >> +#if (CONFIG_TEGRA2_ENABLE_UARTD)
> >> >> + init_uart();
> >> >> +#endif
> >> >> +}
> >> >
> >> > How about:
> >> > #if defined(CONFIG_TEGRA2_ENABLE_UARTA) ||
> >> > defined(CONFIG_TEGRA2_ENABLE_UARTD)
> >> >init_uart();
> >> > #endif
> >> That won't work for a board like Harmony where the developer wants
> >> both UARTs active, since uart_init is only called once.
> >
> > Why should init_uart() be called two times? It looks to initialize both
> > ports, meaning it should only be called once, right?
> Correct, again (need more coffee!) Your if defined construct wouldn't work
> as written, though, because CONFIG_TEGRA2_ENABLE_UARTx is always
> defined (as 0 or 1). I'd have to rework it.
You could also just get rid of uart_init() altogether and rename
init_uart() to uart_init(). That would get rid of some idefs and
simplify the flow.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] fix break caused by new binutils
Dear Steve Sakoman, In message <1295895368.1999.14.camel@quadra> you wrote: > On Mon, 2011-01-24 at 19:36 +0100, Víctor Manuel Jáquez Leal wrote: > > According with this discussion [1] the new assemblers need > > -march=armv7-a+sec on command line or .arch_extension sec inline to > > enable use of the smc instruction. > > > > In the sakoman's u-boot repository there is branch for the omap4 [2] > > which uses the smc instruction with the -march=armv7-a, and it will > > not compile with the latest binutils (2.21) > > Just to clarify -- my branch has Aneesh's "armv7: adapt omap4 to the new > cache maintenance framework" patch series in it. > > So this issue will arise only when Aneesh's patch series is applied. I have a bsic question: do we really need -march=armv7-a at all in U-Boot? What is it good for? 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 "It may be that our role on this planet is not to worship God but to create him." - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Dear Tom Warren, In message you wrote: > > Correct, again (need more coffee!) Your if defined construct wouldn't work > as written, though, because CONFIG_TEGRA2_ENABLE_UARTx is always > defined (as 0 or 1). I'd have to rework it. Please try and avoid relying on specific values. Rather use "#if defined". 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 "We have the right to survive!" "Not be killing others." -- Deela and Kirk, "Wink of An Eye", stardate 5710.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Dear Peter Tyser,
In message <1295891506.2045.146.camel@petert> you wrote:
>
> > I'll use those options in the future (thanks!) to keep things cleaner.
> > Hopefully we can just go with this set of patches so I can get to the
> > other, more interesting code (drivers, A9 CPU init, etc.).
>
> Its up to the ARM maintainer and Wolfgang to decide if adding code in
> one patch just to move it around in the 2nd is acceptable. I'm guess it
No, it is not acceptable. This should be fixed. Thanks for pointing
out.
> Also, just noticed:
> +static void init_uart(void)
> +{
> +#if CONFIG_TEGRA2_ENABLE_UARTA
> + uart_ctlr *const uart = (uart_ctlr *)NV_PA_APB_UARTA_BASE;
> +
> + uart_clock_init();
> +
> + /* Enable UARTA - uses config 0 */
> + pin_mux_uart();
> +
> + setup_uart(uart);
> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
> +#if CONFIG_TEGRA2_ENABLE_UARTD
> + uart_ctlr *const uart = (uart_ctlr *)NV_PA_APB_UARTD_BASE;
> +
>
> Have you compiled with both UARTA and UARTD enabled? Redeclaring 'uart'
> in the middle of the function should throw an error or warning.
Even if the compiler should accept it (which I hpe not), then I will
not accept this ;-) Thanks for pointing out.
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
There is an old custom among my people. When a woman saves a man's
life, he is grateful.
-- Nona, the Kanuto which woman, "A Private Little War",
stardate 4211.8.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
Dear Tom Warren, In message you wrote: > ... > >> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300) > >> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400) > >> +#define NV_PA_PMC_BASE 0x7000E400 > > > > what is the purpose of NV_PA prefix here? > NV_Physical_Address - a base address of a HW block (Power Management > Cntrlr, etc.) Well, the NV_ part is not needed, right? 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 Writing a book is like washing an elephant: there's no good place to begin or end, and it's hard to keep track of what you've already covered. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
Dear Tom Warren,
In message <1295651217-32421-2-git-send-email-twar...@nvidia.com> you wrote:
> Signed-off-by: Tom Warren
>...
...
> +/* Clock/Reset Controller (CLK_RST_CONTROLLER_) regs */
> +typedef volatile struct clk_rst_ctlr {
...
> +/* APB MISC Pin Mux and Tristate (APB_MISC_PP_) registers */
> +typedef volatile struct pinmux_tri_ctlr {
...
> +/* Power Management Controller (APBDEV_PMC_) registers */
> +typedef volatile struct pmc_ctlr {
...
> +#ifndef __ASSEMBLY__
> +typedef volatile struct timerus {
> + unsigned int cntr_1us;
> +} timerus_t;
...
> +/* UART registers */
> +typedef volatile struct uart_ctlr {
Please drop the "typedef" and the "volatile" from all these (and all
other, similar) declarations.
See linux/Documentation/CodingStyle:
It's a _mistake_ to use typedef for structures and pointers.
See Documentation/volatile-considered-harmful.txt
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 am a computer. I am dumber than any human and smarter than any ad-
ministrator.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] fix break caused by new binutils
On Mon, 2011-01-24 at 19:36 +0100, Víctor Manuel Jáquez Leal wrote: > According with this discussion [1] the new assemblers need > -march=armv7-a+sec on command line or .arch_extension sec inline to > enable use of the smc instruction. > > In the sakoman's u-boot repository there is branch for the omap4 [2] > which uses the smc instruction with the -march=armv7-a, and it will > not compile with the latest binutils (2.21) Just to clarify -- my branch has Aneesh's "armv7: adapt omap4 to the new cache maintenance framework" patch series in it. So this issue will arise only when Aneesh's patch series is applied. Perhaps this fix could be incorporated into Aneesh's next revision?? Steve > This patch fix that problem adding conditionally the armv7-a+sec the > march. In order to do this the patch adds as-instr which checks the > latter to enable the correct -march in AFLAGS for files that use smc. > > This patch must be applied on top of > git://www.sakoman.com/git/u-boot.git;branch=omap4-exp > > 1. https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/669912 > 2. > http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-exp > > Signed-off-by: Víctor Manuel Jáquez Leal > --- > arch/arm/cpu/armv7/omap4/Makefile |2 ++ > config.mk |9 + > 2 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/armv7/omap4/Makefile > b/arch/arm/cpu/armv7/omap4/Makefile > index 987dc9d..9dc2b64 100644 > --- a/arch/arm/cpu/armv7/omap4/Makefile > +++ b/arch/arm/cpu/armv7/omap4/Makefile > @@ -26,6 +26,8 @@ include $(TOPDIR)/config.mk > LIB = $(obj)lib$(SOC).o > > SOBJS+= lowlevel_init.o > +plus_sec := $(call as-instr,.arch_extension sec,+sec) > +lowlevel_init.o: AFLAGS += -Wa,-march=armv7-a$(plus_sec) > > COBJS+= board.o > COBJS+= mem.o > diff --git a/config.mk b/config.mk > index c6d6f7b..8d86860 100644 > --- a/config.mk > +++ b/config.mk > @@ -266,3 +266,12 @@ cmd_link_o_target = $(if $(strip $1),\ > rm -f $@; $(AR) rcs $@ ) > > # > + > +# Tries to compile an assembly instruction > +as-instr = $(shell if echo -e "$(1)" | \ > +$(CC) $(AFLAGS) -c -xassembler - \ > + -o $(TMPOUT)astest.out > /dev/null 2>&1; \ > + then rm $(TMPOUT)astest.out; echo "$(2)"; \ > + else echo "$(3)"; fi) > + > +# ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
Dear Mike Rapoport, In message <4d3d68a9.4040...@compulab.co.il> you wrote: > > Besides, since you're using I/O accessors anyway, the struct can replaces with > base address and offset definitions. We do not allow such construtcs in U-Boot. With C structs, you can have proper type checking by the compiler (well, at least assuming you have proper I/O accessors in place). > > +#define NV_PA_APB_UARTC_BASE (NV_PA_APB_MISC_BASE + 0x6200) > > +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300) > > +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400) > > +#define NV_PA_PMC_BASE 0x7000E400 > > what is the purpose of NV_PA prefix here? Good catch. 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 When the bosses talk about improving productivity, they are never talking about themselves. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] fix break caused by new binutils
According with this discussion [1] the new assemblers need -march=armv7-a+sec on command line or .arch_extension sec inline to enable use of the smc instruction. In the sakoman's u-boot repository there is branch for the omap4 [2] which uses the smc instruction with the -march=armv7-a, and it will not compile with the latest binutils (2.21) This patch fix that problem adding conditionally the armv7-a+sec the march. In order to do this the patch adds as-instr which checks the latter to enable the correct -march in AFLAGS for files that use smc. This patch must be applied on top of git://www.sakoman.com/git/u-boot.git;branch=omap4-exp 1. https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/669912 2. http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-exp Signed-off-by: Víctor Manuel Jáquez Leal --- arch/arm/cpu/armv7/omap4/Makefile |2 ++ config.mk |9 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/Makefile b/arch/arm/cpu/armv7/omap4/Makefile index 987dc9d..9dc2b64 100644 --- a/arch/arm/cpu/armv7/omap4/Makefile +++ b/arch/arm/cpu/armv7/omap4/Makefile @@ -26,6 +26,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).o SOBJS += lowlevel_init.o +plus_sec := $(call as-instr,.arch_extension sec,+sec) +lowlevel_init.o: AFLAGS += -Wa,-march=armv7-a$(plus_sec) COBJS += board.o COBJS += mem.o diff --git a/config.mk b/config.mk index c6d6f7b..8d86860 100644 --- a/config.mk +++ b/config.mk @@ -266,3 +266,12 @@ cmd_link_o_target = $(if $(strip $1),\ rm -f $@; $(AR) rcs $@ ) # + +# Tries to compile an assembly instruction +as-instr = $(shell if echo -e "$(1)" | \ +$(CC) $(AFLAGS) -c -xassembler - \ + -o $(TMPOUT)astest.out > /dev/null 2>&1; \ + then rm $(TMPOUT)astest.out; echo "$(2)"; \ + else echo "$(3)"; fi) + +# -- 1.7.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Le 24/01/2011 14:03, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4d3b3cb9.2060...@free.fr> you wrote: >> >>> Thanks - but I also think that Dirk's proposal to create a v2010.12.1 >>> bug fix release makes sense. What do you think? >> >> I didn't comment on this point as it was not for me to decide upon >> releasing an interim U-boot version :) but I'm fine with it if you do. >> When I rebase on u-boot/master before sending my pull request, I'll >> simply skip the corresponding patch in my tree as it will already be on >> yours. > > As soon as you send the pull-request for ARM (when will that be, btw?) > I will also cherry-pick that commit into a .1 stable branch. Ok. I am going through my patchwork backlog; I might be done tomorrow evening, but more probably the day after. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Peter,
On Mon, Jan 24, 2011 at 10:51 AM, Peter Tyser wrote:
>
>
>> > It looks like arch/arm/cpu/armv7/tegra2/board.h and
>> > arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
>> > moved in this patch. It'd be ideal to just add them once in the proper
>> > location.
>> >
>> > On a side note, if you pass "git format-patch" the -M and -C options it
>> > will make pretty diffs that only show what lines changed during a move.
>> > In the case that you do move files in the future its nice to use those
>> > options to ease review.
>> >
>> I'll use those options in the future (thanks!) to keep things cleaner.
>> Hopefully we can just go with this set of patches so I can get to the
>> other, more interesting code (drivers, A9 CPU init, etc.).
>
> Its up to the ARM maintainer and Wolfgang to decide if adding code in
> one patch just to move it around in the 2nd is acceptable. I'm guess it
> won't be acceptable since its considered "bad form", and its unclear
> what patch in this series contains what functionality. Eg this isn't
> really meant to "Add Tegra2 serial port support", it moves existing
> serial port code around? And more? Its not really just adding serial
> port support as the patch title states in any case.
I see what you're talking about now - I've got uart.c in 2 patch files - created
in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
happened when I applied my V4 patches to a new branch to get the V5 patchset
built. I'll fix it and resubmit.
As to 0002 not adding serial port support for Tegra2, that's all it does - adds
TEGRA2 defines to serial.h/serial.c for the eserial* tables, and then adds
code to turn on Tegra2-specific UART HW. If I remove any mention of uart.c
in patch 0001 (add basic Tegra2 support), then does patch 0002 make
sense to you?
>
>> >
>> >
>> > +void uart_init(void)
>> >> +{
>> >> + /* Init each UART - there may be more than 1 on a board/build */
>> >> +#if (CONFIG_TEGRA2_ENABLE_UARTA)
>> >> + init_uart();
>> >> +#endif
>> >> +#if (CONFIG_TEGRA2_ENABLE_UARTD)
>> >> + init_uart();
>> >> +#endif
>> >> +}
>> >
>> > How about:
>> > #if defined(CONFIG_TEGRA2_ENABLE_UARTA) ||
>> > defined(CONFIG_TEGRA2_ENABLE_UARTD)
>> > init_uart();
>> > #endif
>> That won't work for a board like Harmony where the developer wants
>> both UARTs active, since uart_init is only called once.
>
> Why should init_uart() be called two times? It looks to initialize both
> ports, meaning it should only be called once, right?
Correct, again (need more coffee!) Your if defined construct wouldn't work
as written, though, because CONFIG_TEGRA2_ENABLE_UARTx is always
defined (as 0 or 1). I'd have to rework it.
>
> Also, just noticed:
> +static void init_uart(void)
> +{
> +#if CONFIG_TEGRA2_ENABLE_UARTA
> + uart_ctlr *const uart = (uart_ctlr *)NV_PA_APB_UARTA_BASE;
> +
> + uart_clock_init();
> +
> + /* Enable UARTA - uses config 0 */
> + pin_mux_uart();
> +
> + setup_uart(uart);
> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
> +#if CONFIG_TEGRA2_ENABLE_UARTD
> + uart_ctlr *const uart = (uart_ctlr *)NV_PA_APB_UARTD_BASE;
> +
>
> Have you compiled with both UARTA and UARTD enabled? Redeclaring 'uart'
> in the middle of the function should throw an error or warning.
I'd tested with both enabled earlier, but maybe not since the rewrite.
I'll check & resubmit.
>
> + uart_clock_init();
> +
> + /* Enable UARTD - uses config 0 */
> + pin_mux_uart();
> +
> + setup_uart(uart);
> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
> +}
>
> Best,
> Peter
Thanks, again, for your thoroughness!
Tom
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
> > It looks like arch/arm/cpu/armv7/tegra2/board.h and
> > arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
> > moved in this patch. It'd be ideal to just add them once in the proper
> > location.
> >
> > On a side note, if you pass "git format-patch" the -M and -C options it
> > will make pretty diffs that only show what lines changed during a move.
> > In the case that you do move files in the future its nice to use those
> > options to ease review.
> >
> I'll use those options in the future (thanks!) to keep things cleaner.
> Hopefully we can just go with this set of patches so I can get to the
> other, more interesting code (drivers, A9 CPU init, etc.).
Its up to the ARM maintainer and Wolfgang to decide if adding code in
one patch just to move it around in the 2nd is acceptable. I'm guess it
won't be acceptable since its considered "bad form", and its unclear
what patch in this series contains what functionality. Eg this isn't
really meant to "Add Tegra2 serial port support", it moves existing
serial port code around? And more? Its not really just adding serial
port support as the patch title states in any case.
> >
> >
> > +void uart_init(void)
> >> +{
> >> + /* Init each UART - there may be more than 1 on a board/build */
> >> +#if (CONFIG_TEGRA2_ENABLE_UARTA)
> >> + init_uart();
> >> +#endif
> >> +#if (CONFIG_TEGRA2_ENABLE_UARTD)
> >> + init_uart();
> >> +#endif
> >> +}
> >
> > How about:
> > #if defined(CONFIG_TEGRA2_ENABLE_UARTA) ||
> > defined(CONFIG_TEGRA2_ENABLE_UARTD)
> >init_uart();
> > #endif
> That won't work for a board like Harmony where the developer wants
> both UARTs active, since uart_init is only called once.
Why should init_uart() be called two times? It looks to initialize both
ports, meaning it should only be called once, right?
Also, just noticed:
+static void init_uart(void)
+{
+#if CONFIG_TEGRA2_ENABLE_UARTA
+ uart_ctlr *const uart = (uart_ctlr *)NV_PA_APB_UARTA_BASE;
+
+ uart_clock_init();
+
+ /* Enable UARTA - uses config 0 */
+ pin_mux_uart();
+
+ setup_uart(uart);
+#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
+#if CONFIG_TEGRA2_ENABLE_UARTD
+ uart_ctlr *const uart = (uart_ctlr *)NV_PA_APB_UARTD_BASE;
+
Have you compiled with both UARTA and UARTD enabled? Redeclaring 'uart'
in the middle of the function should throw an error or warning.
+ uart_clock_init();
+
+ /* Enable UARTD - uses config 0 */
+ pin_mux_uart();
+
+ setup_uart(uart);
+#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
+}
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Peter,
On Fri, Jan 21, 2011 at 4:46 PM, Peter Tyser wrote:
> Hi Tom,
>
> On Fri, 2011-01-21 at 16:06 -0700, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>> Changes for V2:
>> - Move serial driver to separate patch
>>
>> Changes for V5:
>> - Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
>> rename to serial_tegra2.c
>> - Remove use of uart_num & UART_A/D in serial_tegra2, simplify code
>>
>> arch/arm/cpu/armv7/tegra2/Makefile | 2 +-
>> arch/arm/cpu/armv7/tegra2/board.c | 2 +-
>> arch/arm/cpu/armv7/tegra2/board.h | 58 --
>> arch/arm/cpu/armv7/tegra2/uart.c | 216
>>
>> common/serial.c | 3 +-
>> drivers/serial/Makefile | 1 +
>> drivers/serial/serial_tegra2.c | 205 ++
>> drivers/serial/serial_tegra2.h | 49
>> include/serial.h | 3 +-
>> 9 files changed, 261 insertions(+), 278 deletions(-)
>> delete mode 100644 arch/arm/cpu/armv7/tegra2/board.h
>> delete mode 100644 arch/arm/cpu/armv7/tegra2/uart.c
>> create mode 100644 drivers/serial/serial_tegra2.c
>> create mode 100644 drivers/serial/serial_tegra2.h
>
> It looks like arch/arm/cpu/armv7/tegra2/board.h and
> arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
> moved in this patch. It'd be ideal to just add them once in the proper
> location.
>
> On a side note, if you pass "git format-patch" the -M and -C options it
> will make pretty diffs that only show what lines changed during a move.
> In the case that you do move files in the future its nice to use those
> options to ease review.
>
I'll use those options in the future (thanks!) to keep things cleaner.
Hopefully we can just go with this set of patches so I can get to the
other, more interesting code (drivers, A9 CPU init, etc.).
>
>
> +void uart_init(void)
>> +{
>> + /* Init each UART - there may be more than 1 on a board/build */
>> +#if (CONFIG_TEGRA2_ENABLE_UARTA)
>> + init_uart();
>> +#endif
>> +#if (CONFIG_TEGRA2_ENABLE_UARTD)
>> + init_uart();
>> +#endif
>> +}
>
> How about:
> #if defined(CONFIG_TEGRA2_ENABLE_UARTA) || defined(CONFIG_TEGRA2_ENABLE_UARTD)
> init_uart();
> #endif
That won't work for a board like Harmony where the developer wants
both UARTs active, since uart_init is only called once.
>
> Best,
> Peter
Thanks,
Tom
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] arm: Tegra2: Add support for NVIDIA Harmony board
Mike, On Mon, Jan 24, 2011 at 4:58 AM, Mike Rapoport wrote: > On 01/19/11 23:19, Tom Warren wrote: >> Signed-off-by: Tom Warren >> --- >> Changes for V2: >> - Use board/nvidia/ instead of /board/tegra >> - Change nv-common.h config file to tegra2-common.h >> >> MAINTAINERS | 4 + >> board/nvidia/harmony/Makefile | 50 >> boards.cfg | 1 + >> include/configs/harmony.h | 48 >> include/configs/tegra2-common.h | 160 >> +++ > > What about board/nvidia/harmony/harmony.c? There is no harmony.c file currently - that was whittled down in previous patch edits. It'll be brought back in future patches as features are added that are board-specific. > >> 5 files changed, 263 insertions(+), 0 deletions(-) >> create mode 100644 board/nvidia/harmony/Makefile >> create mode 100644 include/configs/harmony.h >> create mode 100644 include/configs/tegra2-common.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index ba83f71..b5cff19 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -841,6 +841,10 @@ Prafulla Wadaskar >> rd6281a ARM926EJS (Kirkwood SoC) >> sheevaplug ARM926EJS (Kirkwood SoC) >> >> +Tom Warren >> + >> + harmony Tegra2 (ARM7 & A9 Dual Core) >> + >> Matthias Weisser >> >> jadecpu ARM926EJS (MB86R01 SoC) >> diff --git a/board/nvidia/harmony/Makefile b/board/nvidia/harmony/Makefile >> new file mode 100644 >> index 000..3a146cb >> --- /dev/null >> +++ b/board/nvidia/harmony/Makefile >> @@ -0,0 +1,50 @@ >> +# >> +# (C) Copyright 2010,2011 >> +# NVIDIA Corporation >> +# >> +# >> +# 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).o >> + >> +COBJS += ../common/board.o >> + >> +SRCS := $(COBJS:.o=.c) >> +OBJS := $(addprefix $(obj),$(COBJS)) >> + >> +$(LIB): $(obj).depend $(OBJS) >> + $(AR) $(ARFLAGS) $@ $(OBJS) >> + >> +clean: >> + rm -f $(OBJS) >> + >> +distclean: clean >> + rm -f $(LIB) core *.bak $(obj).depend >> + >> +# >> + >> +# defines $(obj).depend target >> +include $(SRCTREE)/rules.mk >> + >> +sinclude $(obj).depend >> + >> +# >> diff --git a/boards.cfg b/boards.cfg >> index 94b8745..ee7c4b7 100644 >> --- a/boards.cfg >> +++ b/boards.cfg >> @@ -122,6 +122,7 @@ omap4_panda arm armv7 >> panda ti >> omap4_sdp4430 arm armv7 sdp4430 ti >> omap4 >> s5p_goni arm armv7 goni >> samsung s5pc1xx >> smdkc100 arm armv7 smdkc100 >> samsung s5pc1xx >> +harmony arm armv7 harmony >> nvidia tegra2 >> actux1 arm ixp >> actux2 arm ixp >> actux3 arm ixp >> diff --git a/include/configs/harmony.h b/include/configs/harmony.h >> new file mode 100644 >> index 000..7d8f27a >> --- /dev/null >> +++ b/include/configs/harmony.h >> @@ -0,0 +1,48 @@ >> +/* >> + * (C) Copyright 2010,2011 >> + * NVIDIA Corporation >> + * >> + * 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
Re: [U-Boot] [PATCH v3 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
Mike,
On Mon, Jan 24, 2011 at 4:55 AM, Mike Rapoport wrote:
> On 01/19/11 23:19, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>> Changes for V2:
>> - Coding style cleanup
>> - Move serial driver changes to separate patch
>> - Use board/nvidia/ instead of /board/tegra
>> - Remove TRUE/FALSE defines
>> - Use standard NS16550 register/bit defines in UART init
>>
>> Changes for V3:
>> - Use I/O accessors for Tegra2 HW MMIO register access
>> - Allow conditional compile of UARTA/UARTD code to save space
>>
>> arch/arm/cpu/armv7/tegra2/Makefile | 48 +
>> arch/arm/cpu/armv7/tegra2/board.c | 91 ++
>> arch/arm/cpu/armv7/tegra2/config.mk | 28 +++
>> arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 66 +++
>> arch/arm/cpu/armv7/tegra2/sys_info.c | 35
>> arch/arm/cpu/armv7/tegra2/timer.c | 122 +
>> arch/arm/include/asm/arch-tegra2/clk_rst.h | 155
>> arch/arm/include/asm/arch-tegra2/pinmux.h | 52 ++
>> arch/arm/include/asm/arch-tegra2/pmc.h | 125 +
>> arch/arm/include/asm/arch-tegra2/sys_proto.h | 33
>> arch/arm/include/asm/arch-tegra2/tegra2.h | 49 +
>> arch/arm/include/asm/arch-tegra2/uart.h | 45 +
>> board/nvidia/common/board.c | 249
>> ++
>> board/nvidia/common/board.h | 57 ++
>> 14 files changed, 1155 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile
>> create mode 100644 arch/arm/cpu/armv7/tegra2/board.c
>> create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk
>> create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S
>> create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c
>> create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c
>> create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h
>> create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h
>> create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h
>> create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h
>> create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h
>> create mode 100644 arch/arm/include/asm/arch-tegra2/uart.h
>> create mode 100644 board/nvidia/common/board.c
>> create mode 100644 board/nvidia/common/board.h
>
> [ snip ]
>
>> + */
>> +
>> +#ifndef _CLK_RST_H_
>> +#define _CLK_RST_H_
>> +
>> +/* Clock/Reset Controller (CLK_RST_CONTROLLER_) regs */
>> +
>> +typedef volatile struct clk_rst_ctlr {
>
> Is it necessary to use the structure to map the clocks and reset controller?
> Wouldn't be better to port Linux implementation of Tegra2 clocks to U-Boot as
> well?
> Besides, since you're using I/O accessors anyway, the struct can replaces with
> base address and offset definitions.
I asked Wolfgang to pre-review the original patch, and this is what he
said about original
base+offset register access code:
Wolfgang> We do not allow this in U-Boot. Please turn all offset
tables into C structs, and
Wolfgang> create a set of I/O accessor functions (or macros) as needed
to provide the needed
Wolfgang> memory barriers on your architecture.
Using structs seems like a natural way to map HW MMIO regs, and is
done throughout U-Boot.
The structs are already written, contain just the members needed for
U-Boot (to a large degree),
and as Wolfgang has said in the past, U-Boot is not Linux, so I see no
reason to bring in the
Linux Tegra2 structs for any of these HW blocks. When I start posting
the drivers (SPI, USB,
etc.), then it might make sense to use (copy w/edits) the Linux data
structs, etc.
>
>> + uint crc_rst_src; /* _RST_SOURCE_0, 0x00*/
>> + uint crc_rst_dev_l; /* _RST_DEVICES_L_0, 0x04*/
>> + uint crc_rst_dev_h; /* _RST_DEVICES_H_0, 0x08*/
>> + uint crc_rst_dev_u; /* _RST_DEVICES_U_0, 0x0C*/
>> + uint crc_clk_out_enb_l; /* _CLK_OUT_ENB_L_0, 0x10*/
>> + uint crc_clk_out_enb_h; /* _CLK_OUT_ENB_H_0, 0x14*/
>
> [ snip ]
>
>> +
>> +#ifndef _PINMUX_H_
>> +#define _PINMUX_H_
>> +
>> +/* APB MISC Pin Mux and Tristate (APB_MISC_PP_) registers */
>> +
>> +typedef volatile struct pinmux_tri_ctlr {
>
> The same comment is valid also for the pin multiplexing registers...
>
>> + uint pmt_reserved0; /* ABP_MISC_PP_ reserved offset 00 */
>> + uint pmt_reserved1; /* ABP_MISC_PP_ reserved offset 04 */
>> + uint pmt_strap_opt_a; /* _STRAPPING_OPT_A_0, offset 08 */
>> +
>> +#ifndef _PMC_H_
>> +#define _PMC_H_
>> +
>> +/* Power Management Controller (APBDEV_PMC_) registers */
>> +
>> +typedef volatile struct pmc_ctlr {
>
> And for the PMC registers as well.
>
>> + uint pmc_cntrl; /* _CNTRL_0, offset 00 */
>> + uint pmc_sec_disable; /* _SEC_DISABLE_0, offset 04 */
>> + uint pmc_pmc_swrst;
Re: [U-Boot] [RFC] ARM timing code refactoring
On 1/24/2011 5:02 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4d3d2942.4060...@free.fr> you wrote:
>> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't>
>> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would>
>> not go through the full 32-bit range, which would cause issues with the>
>> timing loops on rollover -- and while a timeout of more than 65 sec may>
>> not be too likely, a timeout starting near the wraparound value of>
>> bogo_ms still could happen.
Hi All,
If you use my approach of shifting right by n bits (in order to
get a counter that has "about" 1 ms resolution), zeros are shifted into
the top. The counter would never reach more than (32-n) bits in
magnitude. This is easily fixed by creating a "virtual" n msbs for the
counter, as must be done if a 64 bit counter is to be simulated.
Actually, I only need "n" bits, but in any case it requires detecting
that the counter has "backed up" mod 32 bits and if so, increase the
virtual counter by 1.
If you really, really, really want a timer that "ticks" at a 1 ms rate,
instead of bogo_ms/jiffies, I propose the following:
u32 get_time()
{
u32 delta_t_bogo_ms;
u32 t_save;
#if defined(TIMER_IS_64_BITS)
u64 tick;
read(&tick);
t_save = tick >> gd->timer_shift;
delta_t_bogo_ms = t_bogo_ms - gd->prev_timer;
#else
read(t_save);
delta_t_bogo_ms = (t_save - gd->prev_timer) >> gd->timer_shift;
#endif
gd->prev_timer = t_save; /* save previous counter */
if (delta_t_bogo_ms < gd->bogo_ms_per_65_sec)
{
gd->fract_timer+= delta_t_bogo_ms *
gd->cvt_bogo_ms_to_ms; /* accumulate fraction of ms */
gd->timer_in_ms += gd->fract_timer >> 16;
gd->fract_timer &= 0X;
}
else
gd->fract_timer = 0; /* start accumulating from 0 fraction */
return(gd->timer_in_ms)
}
This routine will create a timer in ms, that will be
accurate as long as this routine is called either once about ever 65
seconds or once per time base rollover, whichever is less. Nested timer
use is ok. If the timer is not called frequently enough, it will return
the same value twice, but after that it will start timing normally. This
shouldn't matter, as the second returned value will be the start of a
timing loop. Timeout values can be the full 32 bits, as long as you keep
calling the routine frequently enough. No initialization is required.
Note that you can (and probably should) use the bottom 32
bits of the hardware timebase as a 32 bit timebase unless the clock
would overflow in 65 seconds (running faster than about 66 MHz), or if
you want to relax the 65 seconds.
If you want to save a word in the gd data, use 0X1 instead of
bogo_ms_per_65_sec (or a more precise value if you know it). Note that
gd->timer_shift and gd->cvt_bogo_ms_to_ms can also be replaced by
constants if the clock speed is fixed.
This is more expensive than using the bogo_ms timer, but does have the
advantage that everything is in ms. FWIW, I think converting from ms to
some other unit for loop control is fine, as long as we have a standard
routine to do that that is "cheap". However, others may not agree. For
sure, passing around 64 bit tick values to do this process is, IMHO,
vast overkill and not a good general solution, as many processors really
don't like to do 64 bit operations.
Best Regards.
Bill Campbell
> Sorry, but I don't get it. What exactly is the problem with a 32 bit
> counter, and why would it not go through the full 32-bit range?
>
> Best regards,
>
> Wolfgang Denk
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux
Dear Matthias Weisser, In message <1295884607-9044-1-git-send-email-weiss...@arcor.de> you wrote: > Using optimized versions of memset and memcpy from linux brings a quite > noticeable speed (x2 or better) improvement for these two functions. > > Size impact: > > C version: >textdata bss dec hex filename > 202862 18912 266456 488230 77326 u-boot > > ASM version: >textdata bss dec hex filename > 203798 18912 266288 488998 77626 u-boot How exactly did you measure the speed improvement? 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 Real programmers can write assembly code in any language. :-) - Larry Wall in <8...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux
Using optimized versions of memset and memcpy from linux brings a quite
noticeable speed (x2 or better) improvement for these two functions.
Size impact:
C version:
textdata bss dec hex filename
202862 18912 266456 488230 77326 u-boot
ASM version:
textdata bss dec hex filename
203798 18912 266288 488998 77626 u-boot
Signed-off-by: Matthias Weisser
---
arch/arm/include/asm/assembler.h | 62 ++
arch/arm/include/asm/string.h|4 +-
arch/arm/lib/Makefile|2 +
arch/arm/lib/memcpy.S| 241 ++
arch/arm/lib/memset.S| 126
5 files changed, 433 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/include/asm/assembler.h
create mode 100644 arch/arm/lib/memcpy.S
create mode 100644 arch/arm/lib/memset.S
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
new file mode 100644
index 000..231b1ae
--- /dev/null
+++ b/arch/arm/include/asm/assembler.h
@@ -0,0 +1,62 @@
+/*
+ * arch/arm/include/asm/assembler.h
+ *
+ * Copyright (C) 1996-2000 Russell King
+ *
+ * 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.
+ *
+ * This file contains arm architecture specific defines
+ * for the different processors.
+ *
+ * Do not include any C declarations in this file - it is included by
+ * assembler source.
+ */
+
+/*
+ * Endian independent macros for shifting bytes within registers.
+ */
+#ifndef __ARMEB__
+#define pulllsr
+#define pushlsl
+#define get_byte_0 lsl #0
+#define get_byte_1 lsr #8
+#define get_byte_2 lsr #16
+#define get_byte_3 lsr #24
+#define put_byte_0 lsl #0
+#define put_byte_1 lsl #8
+#define put_byte_2 lsl #16
+#define put_byte_3 lsl #24
+#else
+#define pulllsl
+#define pushlsr
+#define get_byte_0 lsr #24
+#define get_byte_1 lsr #16
+#define get_byte_2 lsr #8
+#define get_byte_3 lsl #0
+#define put_byte_0 lsl #24
+#define put_byte_1 lsl #16
+#define put_byte_2 lsl #8
+#define put_byte_3 lsl #0
+#endif
+
+/*
+ * Data preload for architectures that support it
+ */
+#if defined(__ARM_ARCH_5TE__)
+#define PLD(code...) code
+#else
+#define PLD(code...)
+#endif
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory. Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#define CALGN(code...) code
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index c3ea582..a939571 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -12,7 +12,7 @@ extern char * strrchr(const char * s, int c);
#undef __HAVE_ARCH_STRCHR
extern char * strchr(const char * s, int c);
-#undef __HAVE_ARCH_MEMCPY
+#define __HAVE_ARCH_MEMCPY
extern void * memcpy(void *, const void *, __kernel_size_t);
#undef __HAVE_ARCH_MEMMOVE
@@ -22,7 +22,7 @@ extern void * memmove(void *, const void *, __kernel_size_t);
extern void * memchr(const void *, int, __kernel_size_t);
#undef __HAVE_ARCH_MEMZERO
-#undef __HAVE_ARCH_MEMSET
+#define __HAVE_ARCH_MEMSET
extern void * memset(void *, int, __kernel_size_t);
#if 0
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 454440c..575a919 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -44,6 +44,8 @@ COBJS-y += cache-cp15.o
endif
COBJS-y+= interrupts.o
COBJS-y+= reset.o
+SOBJS-y+= memset.o
+SOBJS-y+= memcpy.o
SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
$(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
new file mode 100644
index 000..40db90e
--- /dev/null
+++ b/arch/arm/lib/memcpy.S
@@ -0,0 +1,241 @@
+/*
+ * linux/arch/arm/lib/memcpy.S
+ *
+ * Author:Nicolas Pitre
+ * Created: Sep 28, 2005
+ * Copyright: MontaVista Software, Inc.
+ *
+ * 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
+
+#define W(instr) instr
+
+#define LDR1W_SHIFT0
+#define STR1W_SHIFT0
+
+ .macro ldr1w ptr reg abort
+ W(ldr) \reg, [\ptr], #4
+ .endm
+
+ .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+ ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+ .endm
+
+ .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+
Re: [U-Boot] [PATCH v3 3/4] arm: Tegra2: Add support for NVIDIA Harmony board
On 01/19/11 23:19, Tom Warren wrote: > Signed-off-by: Tom Warren > --- > Changes for V2: > - Use board/nvidia/ instead of /board/tegra > - Change nv-common.h config file to tegra2-common.h > > MAINTAINERS |4 + > board/nvidia/harmony/Makefile | 50 > boards.cfg |1 + > include/configs/harmony.h | 48 > include/configs/tegra2-common.h | 160 > +++ What about board/nvidia/harmony/harmony.c? > 5 files changed, 263 insertions(+), 0 deletions(-) > create mode 100644 board/nvidia/harmony/Makefile > create mode 100644 include/configs/harmony.h > create mode 100644 include/configs/tegra2-common.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index ba83f71..b5cff19 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -841,6 +841,10 @@ Prafulla Wadaskar > rd6281a ARM926EJS (Kirkwood SoC) > sheevaplug ARM926EJS (Kirkwood SoC) > > +Tom Warren > + > + harmony Tegra2 (ARM7 & A9 Dual Core) > + > Matthias Weisser > > jadecpu ARM926EJS (MB86R01 SoC) > diff --git a/board/nvidia/harmony/Makefile b/board/nvidia/harmony/Makefile > new file mode 100644 > index 000..3a146cb > --- /dev/null > +++ b/board/nvidia/harmony/Makefile > @@ -0,0 +1,50 @@ > +# > +# (C) Copyright 2010,2011 > +# NVIDIA Corporation > +# > +# > +# 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).o > + > +COBJS+= ../common/board.o > + > +SRCS := $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > + > +$(LIB): $(obj).depend $(OBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +clean: > + rm -f $(OBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak $(obj).depend > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/boards.cfg b/boards.cfg > index 94b8745..ee7c4b7 100644 > --- a/boards.cfg > +++ b/boards.cfg > @@ -122,6 +122,7 @@ omap4_panda arm armv7 > panda ti > omap4_sdp4430arm armv7 sdp4430 ti >omap4 > s5p_goni arm armv7 goni > samsungs5pc1xx > smdkc100 arm armv7 smdkc100 > samsungs5pc1xx > +harmony arm armv7 harmony > nvidia tegra2 > actux1 arm ixp > actux2 arm ixp > actux3 arm ixp > diff --git a/include/configs/harmony.h b/include/configs/harmony.h > new file mode 100644 > index 000..7d8f27a > --- /dev/null > +++ b/include/configs/harmony.h > @@ -0,0 +1,48 @@ > +/* > + * (C) Copyright 2010,2011 > + * NVIDIA Corporation > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +#ifndef __CONFIG_H > +#define __CONFIG_H > + > +#include > +#include "tegra2-common.h" > + > +/* High-level configuration options */ > +#define TEGRA2_SYSMEM"mem=384M@0M nvmem=128M@384M > mem=512M@512M" > +#define
Re: [U-Boot] [PATCH v3 1/4] arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
On 01/19/11 23:19, Tom Warren wrote:
> Signed-off-by: Tom Warren
> ---
> Changes for V2:
> - Coding style cleanup
> - Move serial driver changes to separate patch
> - Use board/nvidia/ instead of /board/tegra
> - Remove TRUE/FALSE defines
> - Use standard NS16550 register/bit defines in UART init
>
> Changes for V3:
> - Use I/O accessors for Tegra2 HW MMIO register access
> - Allow conditional compile of UARTA/UARTD code to save space
>
> arch/arm/cpu/armv7/tegra2/Makefile | 48 +
> arch/arm/cpu/armv7/tegra2/board.c| 91 ++
> arch/arm/cpu/armv7/tegra2/config.mk | 28 +++
> arch/arm/cpu/armv7/tegra2/lowlevel_init.S| 66 +++
> arch/arm/cpu/armv7/tegra2/sys_info.c | 35
> arch/arm/cpu/armv7/tegra2/timer.c| 122 +
> arch/arm/include/asm/arch-tegra2/clk_rst.h | 155
> arch/arm/include/asm/arch-tegra2/pinmux.h| 52 ++
> arch/arm/include/asm/arch-tegra2/pmc.h | 125 +
> arch/arm/include/asm/arch-tegra2/sys_proto.h | 33
> arch/arm/include/asm/arch-tegra2/tegra2.h| 49 +
> arch/arm/include/asm/arch-tegra2/uart.h | 45 +
> board/nvidia/common/board.c | 249
> ++
> board/nvidia/common/board.h | 57 ++
> 14 files changed, 1155 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile
> create mode 100644 arch/arm/cpu/armv7/tegra2/board.c
> create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk
> create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S
> create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c
> create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c
> create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h
> create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h
> create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h
> create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h
> create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h
> create mode 100644 arch/arm/include/asm/arch-tegra2/uart.h
> create mode 100644 board/nvidia/common/board.c
> create mode 100644 board/nvidia/common/board.h
[ snip ]
> + */
> +
> +#ifndef _CLK_RST_H_
> +#define _CLK_RST_H_
> +
> +/* Clock/Reset Controller (CLK_RST_CONTROLLER_) regs */
> +
> +typedef volatile struct clk_rst_ctlr {
Is it necessary to use the structure to map the clocks and reset controller?
Wouldn't be better to port Linux implementation of Tegra2 clocks to U-Boot as
well?
Besides, since you're using I/O accessors anyway, the struct can replaces with
base address and offset definitions.
> + uint crc_rst_src; /* _RST_SOURCE_0, 0x00*/
> + uint crc_rst_dev_l; /* _RST_DEVICES_L_0,0x04*/
> + uint crc_rst_dev_h; /* _RST_DEVICES_H_0,0x08*/
> + uint crc_rst_dev_u; /* _RST_DEVICES_U_0,0x0C*/
> + uint crc_clk_out_enb_l; /* _CLK_OUT_ENB_L_0,0x10*/
> + uint crc_clk_out_enb_h; /* _CLK_OUT_ENB_H_0,0x14*/
[ snip ]
> +
> +#ifndef _PINMUX_H_
> +#define _PINMUX_H_
> +
> +/* APB MISC Pin Mux and Tristate (APB_MISC_PP_) registers */
> +
> +typedef volatile struct pinmux_tri_ctlr {
The same comment is valid also for the pin multiplexing registers...
> + uint pmt_reserved0; /* ABP_MISC_PP_ reserved offset 00 */
> + uint pmt_reserved1; /* ABP_MISC_PP_ reserved offset 04 */
> + uint pmt_strap_opt_a; /* _STRAPPING_OPT_A_0, offset 08 */
> +
> +#ifndef _PMC_H_
> +#define _PMC_H_
> +
> +/* Power Management Controller (APBDEV_PMC_) registers */
> +
> +typedef volatile struct pmc_ctlr {
And for the PMC registers as well.
> + uint pmc_cntrl; /* _CNTRL_0, offset 00 */
> + uint pmc_sec_disable; /* _SEC_DISABLE_0, offset 04 */
> + uint pmc_pmc_swrst; /* _PMC_SWRST_0, offset 08 */
> + uint pmc_wake_mask; /* _WAKE_MASK_0, offset 0C */
> + uint pmc_wake_lvl; /* _WAKE_LVL_0, offset 10 */
[ snip ]
> +#ifndef _TEGRA2_H_
> +#define _TEGRA2_H_
> +
> +#define NV_PA_SDRAM_BASE 0x
> +#define NV_PA_TMRUS_BASE 0x60005010
> +#define NV_PA_CLK_RST_BASE 0x60006000
> +#define NV_PA_APB_MISC_BASE 0x7000
> +#define NV_PA_APB_UARTA_BASE (NV_PA_APB_MISC_BASE + 0x6000)
> +#define NV_PA_APB_UARTB_BASE (NV_PA_APB_MISC_BASE + 0x6040)
> +#define NV_PA_APB_UARTC_BASE (NV_PA_APB_MISC_BASE + 0x6200)
> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300)
> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400)
> +#define NV_PA_PMC_BASE 0x7000E400
what is the purpose of NV_PA prefix here?
> +#define TEGRA2_SDRC_CS0 NV_PA_SDRAM_BASE
> +#define LOW_LEVEL_SRAM_STACK 0x4000FFFC
> +
> +#ifndef __ASSEMBLY__
> +typedef volatile struct timerus {
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Dear Albert ARIBAUD, In message <4d3b3cb9.2060...@free.fr> you wrote: > > > Thanks - but I also think that Dirk's proposal to create a v2010.12.1 > > bug fix release makes sense. What do you think? > > I didn't comment on this point as it was not for me to decide upon > releasing an interim U-boot version :) but I'm fine with it if you do. > When I rebase on u-boot/master before sending my pull request, I'll > simply skip the corresponding patch in my tree as it will already be on > yours. As soon as you send the pull-request for ARM (when will that be, btw?) I will also cherry-pick that commit into a .1 stable branch. 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 greatest warriors are the ones who fight for peace." - Holly Near ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Albert ARIBAUD, In message <4d3d2942.4060...@free.fr> you wrote: > > That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't > > have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would > > not go through the full 32-bit range, which would cause issues with the > > timing loops on rollover -- and while a timeout of more than 65 sec may > > not be too likely, a timeout starting near the wraparound value of > > bogo_ms still could happen. Sorry, but I don't get it. What exactly is the problem with a 32 bit counter, and why would it not go through the full 32-bit range? 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 Vor allem kein Gedanke! Nichts ist kompromittierender als ein Gedan- ke!- Friedrich Wilhelm Nietzsche _Der Fall Wagner_ (1888) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Reinhard Meyer,
In message <4d3d2f34.6020...@emk-elektronik.de> you wrote:
> Dear all,
>
> its quite funny to see how we go around in circles here, this proposal of
> Albert
> now is quite close to my original proposal. Only that I factored the
> ms_to_ticks
> AND the comparison into the timer calls:
>
> u64 timer_setup(u32 timeout_in_ms)
> {
> return get_ticks() + ms_to_ticks(timeout_in_ms);
> }
No. I said this severaltimes before, and I repeat it here one other
time: I do not want to see such a function. There nothing to be done
to "set up a timer".
> /*
>* convert the unsigned difference to signed, to easyly
>* check for "carry". In assembly we could just do a BCC
>* after the subtraction to see whether get_ticks()
>* has passed ahead of endtime.
>*/
> return (signed)(endtime - get_ticks()) < 0;
Are you sure this is really working? Why do you insist on this
approach instead of using the proven to be correct way to write this?
> > u32 start = get_timer(); /* start time, in ticks */
No. I do not see any reason to change existing interfaces.
If ticks are wanted, then use get_ticks(). And deal with the overhead
or 64 bit arithmetics.
But in general code I prefer get_timer() - milliseconds, u32.
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
Substitute "damn" every time you're inclined to write "very"; your
editor will delete it and the writing will be just as it should be.
- Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Hi Albert,
Am 24.01.2011 12:58, schrieb Albert ARIBAUD:
> Hi Andreas,
>
> Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>
>>> That's where I come back to one point of my proposal: if we can get a
>>> general framework for get_timer() to return a 64-bit free-running tick
>>> value, then we might not need a ms-based get_time() at all, because we
>>> could use get_timer() as well for ms timings, provided we can convert
>>> our timeout from ms to ticks, i.e.
>>>
>>> /* let's wait 200 milliseconds */
>>> /* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
>>> timeout = ms_to_ticks(200);
>>> u32 start = get_timer(); /* start time, in ticks */
>>> do {
>>> ...
>>> } while ( (get_timer() -start)< timeout);
>>
>> You may think about the following change to this proposal:
>>
>> /* lets wait 200 ms */
>> /* get the end point of our timeout in ticks */
>> u64 timeout_end = get_timer() + ms_to_ticks(200);
>> do {
>> ...
>> } while ( get_timer()< timeout_end);
>
> The problem here is that in the loop exit condition you replace a
> difference between two unsigned times (which always yields the correct
> duration) with a comparison of two dates (which does not).
Ok, I got your point.
regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Albert ARIBAUD, In message <4d3d2942.4060...@free.fr> you wrote: > > - get_timer() works in pure ticks, not ms, and thus does not need > multiply/divide; it may at most need to implement a carry over from 32 > bit to 64 bits *if* the HW counter is 32 bits *and if* we want a 64-bit > virtual counter. > - get_time() works in ms, and thus needs scale conversion, so possibly a > multiply/divide but possibly some other method, to convert a tick value > to an ms value. No. There is get_ticks(), which operates on ticks, and there is get_timer(), which returns milliseconds. > That's where I come back to one point of my proposal: if we can get a > general framework for get_timer() to return a 64-bit free-running tick > value, then we might not need a ms-based get_time() at all, because we > could use get_timer() as well for ms timings, provided we can convert Then you will always have to use 64 bit variables for all related operations. Note that get_timer() returns "unsigned long"", which allows for smaller code in the majority of use cases. 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 Program maintenance is an entropy-increasing process, and even its most skilfull execution only delays the subsidence of the system into unfixable obsolescence. - Fred Brooks, "The Mythical Man Month" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang, In message <1295842861.2196.38.camel@haiying-laptop> you wrote: > On Sat, 2011-01-22 at 23:04 +0100, Wolfgang Denk wrote: > > > diff --git a/Makefile b/Makefile > > > index 87a383d..94af465 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -290,6 +290,10 @@ LDPPFLAGS += \ > > > $(shell $(LD) --version | \ > > > sed -ne 's/GNU ld version > > > \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') > > > > > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > > > +TPL_BOOT = tpl > > > +endif > > > > I don't understand what the "TPL_BOOT" is good for, or how it's > > supposed to work. > TPL_BOOT works like NAND_SPL but after NAND_SPL is executed. It is a > middle stage boot loader to balance the 4K nand spl limitation which can > not include ddr spd code and the 256K L2 SRAM size which can not > accommodate the final uboot image on some Freescale Qoriq P1 platforms. Yes, I understand what you are atempting to do. What I do not understand is what the TPL_BOOT variable in the Makefile is good for. I cannot understand the current use. > The main purpose of tpl is to initialize the ddr with spd code in l2 > sram then load the final uboot image to ddr. The reason to call tpl is > because it runs after spl, the Second Program Loader. My original patch > used CONFIG_MIDDLE_STAGE_SRAM_BOOT but you recommended to use > CONFIG_SYS_2ND_STAGE_BOOT(http://lists.denx.de/pipermail/u-boot/2010-August/075653.html). > However, 2ND STAGE is not correct here since it runs after SPL. > > > ifeq ($(CONFIG_NAND_U_BOOT),y) > > > NAND_SPL = nand_spl > > > U_BOOT_NAND = $(obj)u-boot-nand.bin > > > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > > > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > > > > > -$(U_BOOT_NAND): $(NAND_SPL) $(obj)u-boot.bin > > > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > > > $(obj)u-boot-nand.bin > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > and this rule will probably cause a build error, doesn't it? > No, I don't think there is a build error. WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not defined, which results in this make rule: : $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C tpl/board/$(BOARDDIR) all i. e. there would be no target name befoe the semicolon. > > Has this code ever been tested? > Yes, I tested it on P1021MDS board, and also built for other 85xx NAND_config > without error. Did you run a "MAKEALL ppc", i. e. build for all PPC board, not only NAND booting versions? > > > + CONFIG_TPL_U_BOOT > > > + > > > + Builds a U-Boot image that contains a loader stub (tertiary > > > + program loader -- TPL) that boots out of some type of RAM, > > > + after being loaded by an SPL or similar platform-specific > > > + mechanism. This symbol will be set in all build phases. > > > + > > > + CONFIG_TPL_BOOT > > > + > > > + This is set by the build system when compiling code to go into > > > + the TPL. It is not set when building the code that the TPL > > > + loads, or when building the SPL. > > > > Can we not do with a single variable definition? > > I did not get it. Could you please give a recommendation? Well, I see a pollution with such CONFIG_ settings. I don;t have a solution ready to recommend, but if you can find a way not to define so many different settings for a single purpose that wouldbe great. 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 Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ftide020: add faraday ide ahb controller from Linux kernel
Faraday's ftide020_s is an IDE-AHB controller for SoC design.
This patch ported the u-boot driver (PIO) of ftide020 ATA (IDE) driver
from Linux kernel. IDE commands include read, info, and other functions
has been implemented.
Because this IDE controller support AHB interface only which is differ
from other most IDE controller supports PCI interface. Some registers
access is required during CMD/DATA I/O. Hence a configuration
"CONFIG_IDE_AHB" is required to be defined according to the feature in
cmd_ide.c.
Signed-off-by: Macpaul Lin
---
drivers/block/Makefile |1 +
drivers/block/ftide020.c | 380 ++
drivers/block/ftide020.h | 265
3 files changed, 646 insertions(+), 0 deletions(-)
create mode 100644 drivers/block/ftide020.c
create mode 100644 drivers/block/ftide020.h
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index e27175b..e3f46b8 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libblock.o
COBJS-$(CONFIG_SCSI_AHCI) += ahci.o
COBJS-$(CONFIG_ATA_PIIX) += ata_piix.o
COBJS-$(CONFIG_FSL_SATA) += fsl_sata.o
+COBJS-$(CONFIG_IDE_FTIDE020) += ftide020.o
COBJS-$(CONFIG_LIBATA) += libata.o
COBJS-$(CONFIG_CMD_MG_DISK) += mg_disk.o
COBJS-$(CONFIG_MVSATA_IDE) += mvsata_ide.o
diff --git a/drivers/block/ftide020.c b/drivers/block/ftide020.c
new file mode 100644
index 000..eef8c08
--- /dev/null
+++ b/drivers/block/ftide020.c
@@ -0,0 +1,380 @@
+/*
+ * [origin: Linux kernel drivers/ide/ftide020.c]
+ * Faraday FTIDE020 ATA Controller (AHB)
+ *
+ * (C) Copyright 2011 Andes Technology
+ * Greentime Hu
+ * Macpaul Lin
+ * Kuo-Wei Chou
+ *
+ * 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
+ *
+ */
+/* ftide020.c - ide support functions for the FTIDE020_S controller */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ftide020.h"
+
+#define FTIDE_IP_NAME "FTIDE020_S"
+#define FTIDE_DRIVER_VERSION "1.0.1"
+
+#ifndef TRUE
+#define TRUE 1
+#endif
+
+#ifndef FALSE
+#define FALSE 0
+#endif
+
+/* DEBUG */
+#ifdef FTIDE_DEBUG
+ #define P_DEBUG(fmt, args...) printf(FTIDE_IP_NAME ":" fmt, ## args)
+#else
+ #define P_DEBUG(a...)
+#endif
+
+/* base address */
+#define FTIDE_BASE CONFIG_SYS_ATA_BASE_ADDR
+
+/*
+ * data address - The CMD and DATA use the same FIFO in FTIDE020_S
+ * FTIDE_DATA = CONFIG_SYS_ATA_BASE_ADDR + CONFIG_SYS_ATA_DATA_OFFSET
+ * = &ftide020->rw_fifo
+ */
+#define FTIDE_DATA (&ftide020->rw_fifo)
+
+/* command and data I/O macros */
+/* 0x0 - DATA FIFO */
+#define WRITE_DATA(x) outl((x), &ftide020->rw_fifo) /* 0x00 */
+#define READ_DATA()inl(&ftide020->rw_fifo) /* 0x00 */
+/* 0x04 - R: Status Reg, W: CMD_FIFO */
+#define WRITE_CMD(x) outl((x), &ftide020->cmd_fifo) /* 0x04 */
+#define READ_STATUS() inl(&ftide020->cmd_fifo)/* 0x04 */
+
+#define mdelay(n) ({unsigned long msec = (n); while (msec--) udelay(1000); })
+
+void ftide_set_device(int cx8, int dev)
+{
+ static struct ftide020_s *ftide020 = (struct ftide020_s *) FTIDE_BASE;
+
+ WRITE_CMD(SET_DEV_CMD | IDE_SET_CX8(cx8) | dev);
+}
+
+unsigned char ide_read_register(int dev, unsigned int port)
+{
+ static struct ftide020_s *ftide020 = (struct ftide020_s *) FTIDE_BASE;
+
+ ftide_set_device(0, dev);
+ WRITE_CMD(READ_REG_CMD | IDE_REG_CS_READ(CONFIG_IDE_REG_CS) |
+ IDE_REG_DA_WRITE(port));
+
+ return READ_DATA() & 0xff;
+}
+
+void ide_write_register(int dev, unsigned int port, unsigned char val)
+{
+ static struct ftide020_s *ftide020 = (struct ftide020_s *) FTIDE_BASE;
+
+ ftide_set_device(0, dev);
+ WRITE_CMD(WRITE_REG_CMD | IDE_REG_CS_WRITE(CONFIG_IDE_REG_CS) |
+ IDE_REG_DA_WRITE(port) | val);
+}
+
+void ide_write_data(int dev, ulong *sect_buf, int words)
+{
+ static struct ftide020_s *ftide020 = (struct ftide020_s *) FTIDE_BASE;
+
+ ftide_set_device(0, dev);
+ WRITE_CMD(WRITE_DATA_CMD | ((words << 2) - 1));
+
+ /* block write */
+ outsl(FTIDE_DATA, sect_buf, words);
+}
+
+void ide_read_data(int dev, ulong *sect_buf, int words)
+{
+
[U-Boot] [PATCH 1/2] cmd_ide: enhance new feature "CONFIG_IDE_AHB"
Although most IDE controller is designed to be connected to PCI bridge,
there are still some IDE controller support AHB interface for SoC design.
The driver implementation of these IDE-AHB controllers differ from other
IDE-PCI controller, some additional registers and commands access is required
during CMD/DATA I/O. Hence a configuration "CONFIG_IDE_AHB" in cmd_ide.c is
required to be defined to support these kinds of SoC controllers. Such as
Faraday's FTIDE020 series and Global Unichip's UINF-0301.
Signed-off-by: Macpaul Lin
---
README |8
common/cmd_ide.c | 37 -
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/README b/README
index 727bf8a..3de0605 100644
--- a/README
+++ b/README
@@ -2673,6 +2673,14 @@ Low Level (hardware related) configuration options:
source code. It is used to make hardware dependant
initializations.
+- CONFIG_IDE_AHB:
+ Most IDE controllers were designed to be connected with PCI
+ interface. Only few of them were designed for AHB interface.
+ When software is doing ATA command and data transfer to
+ IDE devices through IDE-AHB controller, some additional
+ registers accessing to these kind of IDE-AHB controller
+ is requierd.
+
- CONFIG_SYS_IMMR: Physical address of the Internal Memory.
DO NOT CHANGE unless you know exactly what you're
doing! (11-4) [MPC8xx/82xx systems only]
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index ea0f4a7..edb4fc0 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -518,8 +518,22 @@ __ide_outb(int dev, int port, unsigned char val)
{
debug ("ide_outb (dev= %d, port= 0x%x, val= 0x%02x) : @ 0x%08lx\n",
dev, port, val,
(ATA_CURR_BASE(dev)+CONFIG_SYS_ATA_PORT_ADDR(port)));
+
+#if defined(CONFIG_IDE_AHB)
+ if (port) {
+ /* write command */
+ extern void ide_write_register(int, unsigned int, unsigned
char);
+
+ ide_write_register(dev, port, val);
+ } else {
+ /* write data */
+ outb(val, (ATA_CURR_BASE(dev)));
+ }
+#else
outb(val, (ATA_CURR_BASE(dev)+CONFIG_SYS_ATA_PORT_ADDR(port)));
+#endif
}
+
void ide_outb (int dev, int port, unsigned char val)
__attribute__((weak, alias("__ide_outb")));
@@ -527,7 +541,15 @@ unsigned char inline
__ide_inb(int dev, int port)
{
uchar val;
+
+#if defined(CONFIG_IDE_AHB)
+ extern unsigned char ide_read_register(int, unsigned int);
+
+ val = ide_read_register(dev, port);
+#else
val = inb((ATA_CURR_BASE(dev)+CONFIG_SYS_ATA_PORT_ADDR(port)));
+#endif
+
debug ("ide_inb (dev= %d, port= 0x%x) : @ 0x%08lx -> 0x%02x\n",
dev, port, (ATA_CURR_BASE(dev)+CONFIG_SYS_ATA_PORT_ADDR(port)),
val);
return val;
@@ -696,6 +718,7 @@ void ide_init (void)
ide_dev_desc[i].blksz=0;
ide_dev_desc[i].lba=0;
ide_dev_desc[i].block_read=ide_read;
+ ide_dev_desc[i].block_write = ide_write;
if (!ide_bus_ok[IDE_BUS(i)])
continue;
ide_led (led, 1); /* LED on */
@@ -902,7 +925,13 @@ output_data(int dev, ulong *sect_buf, int words)
static void
output_data(int dev, ulong *sect_buf, int words)
{
- outsw(ATA_CURR_BASE(dev)+ATA_DATA_REG, sect_buf, words<<1);
+#if defined(CONFIG_IDE_AHB)
+ extern void ide_write_data(int, ulong *, int);
+
+ ide_write_data(dev, sect_buf, words);
+#else
+ outsw(ATA_CURR_BASE(dev)+ATA_DATA_REG, sect_buf, words << 1);
+#endif
}
#endif /* CONFIG_IDE_SWAP_IO */
@@ -960,7 +989,13 @@ input_data(int dev, ulong *sect_buf, int words)
static void
input_data(int dev, ulong *sect_buf, int words)
{
+#if defined(CONFIG_IDE_AHB)
+ extern void ide_read_data(int, ulong *, int);
+
+ ide_read_data(dev, sect_buf, words);
+#else
insw(ATA_CURR_BASE(dev)+ATA_DATA_REG, sect_buf, words << 1);
+#endif
}
#endif /* CONFIG_IDE_SWAP_IO */
--
1.7.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8xxx ethernet not up
On 01/24/2011 01:12 PM, saugat mitra wrote: > Hi > Hi, > I am trying to boot a MPC8XXX based board using uboot version 1.1.3. > I am able to get the serial console up. But when I try to ping it > gives me a time out error. > On trying "mii info" and enabling debug messages I see that all the > mii read messages are > returning 0x. Could any one please suggest me steps to debug. make yourself a favour and upgrade to last U-Boot version. Your version is so ancient that is impossible to find which is the fix for you. And on current release, ethernet works well on mpc8xx (tested on a TQ tqm860L board). Best regards, Stefano Babic -- = 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
Re: [U-Boot] [PATCH 4/8 v2] powerpc/85xx: add TPL_BOOT support
Dear Haiying Wang, In message <1295840749.2196.3.camel@haiying-laptop> you wrote: > > > > +#ifdef CONFIG_FSL_CORENET > > > + return (gd->bus_clk + 8) / 16; > > > +#else > > > + return (gd->bus_clk + 4UL)/8UL; > > > +#endif > > > > This looks inconsistent. Either this should be "... +8UL) / 16UL" or > > "... + 4) / 8;" > This part was copied from arch/powerpc/cpu/mpc85xx/cpu.c, just want too > reduce the image size without including that file(cpu.c). Will fix it. Instead of copying, can we please move it to some common code? 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 It is wrong always, everywhere and for everyone to believe anything upon insufficient evidence. - W. K. Clifford, British philosopher, circa 1876 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8xxx ethernet not up
Hi I am trying to boot a MPC8XXX based board using uboot version 1.1.3. I am able to get the serial console up. But when I try to ping it gives me a time out error. On trying "mii info" and enabling debug messages I see that all the mii read messages are returning 0x. Could any one please suggest me steps to debug. Thanks & Regards Saugat. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot support for board(s) meesc, otc570
Dear Daniel Gorsulowski, > Hello Reinhard, > > ... >>> >>> Check that your AT91Bootstrap loads u-boot to a sane address not at the >>> very end >>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where >>> AT91Bootstrap >>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin >>> of DRAM >>> for our boards.) >>> >> >> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address, >> so the problem must be located elsewhere. Not necessaryly. You have not changed them, but who says they were correct before? I am not sure, but before relocation it might have not mattered if they were different. Just really check to make sure. >> >> Today I found out by GPIO debugging, that U-Boot seems to boot but prints >> its startup messages to wrong USART with proper baudrate. I'll try to >> find out, why there is no output on DBGU. >> > > I have to correct myself. > My board_init() and checkboard() fanctions are executed. But the board > crashes, before misc_init_r() functions executes. > (I guess, it crashes somwhere in board_init_f()) > I'll try to find out more infos. But without an appropriate opportunity > to debug, it will be verry difficult. I can only advice a step by step approach: Take the at91sam9260ek port and only change the bits that are different for 9263 and your board. I don't have any 9263 based board here, so I cannot point to a proven, working port for that SoC. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Le 24/01/2011 12:58, Albert ARIBAUD a écrit : > For instance, if at loop entry get_timer() was, say, 10 ticks to > rollover and the loop timing was 12 ticks, you end up with an end date > of 2. If your loop body runs long enough, get_timer() may already have > gone past this and will this stay greater than timeout_end for a very > long time. I should always wait for the coffee to produce its effect before posting. The right example is having timeout_end *not* have rolled over (thus being a very high number) and the loop body being long enough that get_timer() is called at the first loop condition test *after* rollover, thus being very small. > OTOH, using get_timer() on entry of loop and subtracting it from > get_timer() at each loop iteration always yields the time elapsed, > unaffected by rollover. You can then safely compare this elapsed time > with the time-out value. > > Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Hi Andreas,
Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>> That's where I come back to one point of my proposal: if we can get a
>> general framework for get_timer() to return a 64-bit free-running tick
>> value, then we might not need a ms-based get_time() at all, because we
>> could use get_timer() as well for ms timings, provided we can convert
>> our timeout from ms to ticks, i.e.
>>
>> /* let's wait 200 milliseconds */
>> /* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
>> timeout = ms_to_ticks(200);
>> u32 start = get_timer(); /* start time, in ticks */
>> do {
>> ...
>> } while ( (get_timer() -start)< timeout);
>
> You may think about the following change to this proposal:
>
> /* lets wait 200 ms */
> /* get the end point of our timeout in ticks */
> u64 timeout_end = get_timer() + ms_to_ticks(200);
> do {
> ...
> } while ( get_timer()< timeout_end);
The problem here is that in the loop exit condition you replace a
difference between two unsigned times (which always yields the correct
duration) with a comparison of two dates (which does not).
For instance, if at loop entry get_timer() was, say, 10 ticks to
rollover and the loop timing was 12 ticks, you end up with an end date
of 2. If your loop body runs long enough, get_timer() may already have
gone past this and will this stay greater than timeout_end for a very
long time.
OTOH, using get_timer() on entry of loop and subtracting it from
get_timer() at each loop iteration always yields the time elapsed,
unaffected by rollover. You can then safely compare this elapsed time
with the time-out value.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot support for board(s) meesc, otc570
Hello Reinhard, ... >> >> Check that your AT91Bootstrap loads u-boot to a sane address not at the >> very end >> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where >> AT91Bootstrap >> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin >> of DRAM >> for our boards.) >> > > I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address, > so the problem must be located elsewhere. > > Today I found out by GPIO debugging, that U-Boot seems to boot but prints > its startup messages to wrong USART with proper baudrate. I'll try to > find out, why there is no output on DBGU. > I have to correct myself. My board_init() and checkboard() fanctions are executed. But the board crashes, before misc_init_r() functions executes. (I guess, it crashes somwhere in board_init_f()) I'll try to find out more infos. But without an appropriate opportunity to debug, it will be verry difficult. Best regards Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] MX51: drop config.mk from mx51evk
The config.mk file in board directory is now obsolete and should be removed. Add option for the IMX image into boards.cfg Signed-off-by: Stefano Babic --- board/freescale/mx51evk/config.mk | 25 - boards.cfg|2 +- include/configs/mx51evk.h |2 ++ 3 files changed, 3 insertions(+), 26 deletions(-) delete mode 100644 board/freescale/mx51evk/config.mk diff --git a/board/freescale/mx51evk/config.mk b/board/freescale/mx51evk/config.mk deleted file mode 100644 index 6e90671..000 --- a/board/freescale/mx51evk/config.mk +++ /dev/null @@ -1,25 +0,0 @@ -# -# Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved. -# -# 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 -# - -CONFIG_SYS_TEXT_BASE = 0x9780 -IMX_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/imximage.cfg -ALL += $(obj)u-boot.imx diff --git a/boards.cfg b/boards.cfg index 18bcc69..b8e228c 100644 --- a/boards.cfg +++ b/boards.cfg @@ -105,7 +105,7 @@ magnesiumarm arm926ejs imx27lite logicpd omap5912osk arm arm926ejs - ti omap edminiv2 arm arm926ejs - LaCie orion5x ca9x4_ct_vxp arm armv7 vexpressarmltd -mx51evk arm armv7 mx51evk freescale mx5 +mx51evk arm armv7 mx51evk freescale mx5 mx51evk:IMX_CONFIG=board/freescale/mx51evk/imximage.cfg mx53evk arm armv7 mx53evk freescale mx5 vision2 arm armv7 vision2 ttcontrol mx5 omap3_overo arm armv7 overo - omap3 diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h index 591d6e1..8da8222 100755 --- a/include/configs/mx51evk.h +++ b/include/configs/mx51evk.h @@ -33,6 +33,8 @@ #define CONFIG_DISPLAY_CPUINFO #define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_TEXT_BASE 0x9780 + #define CONFIG_L2_OFF #include -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Makefile: change rule to build IMX image
config.mk in board directory is obsolete and should be removed. The patch allows to get rid of own config.mk adding the imximage.cfg file to the options in the boards.cfg Signed-off-by: Stefano Babic --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index fd21ef3..fff5741 100644 --- a/Makefile +++ b/Makefile @@ -353,7 +353,7 @@ $(obj)u-boot.img: $(obj)u-boot.bin -d $< $@ $(obj)u-boot.imx: $(obj)u-boot.bin - $(obj)tools/mkimage -n $(IMX_CONFIG) -T imximage \ + $(obj)tools/mkimage -n $(CONFIG_IMX_CONFIG) -T imximage \ -e $(CONFIG_SYS_TEXT_BASE) -d $< $@ $(obj)u-boot.kwb: $(obj)u-boot.bin -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Albert ARIBAUD,
Am 24.01.2011 um 08:24 schrieb Albert ARIBAUD:
> Le 24/01/2011 02:42, J. William Campbell a écrit :
>
>> Hi All,
>>In order to avoid doing 64 bit math, we can define a "jiffie"
>> or a "bogo_ms" that is the 64 bit timebase shifted right such that the
>> lsb of the bottom 32 bits has a resolution of between 0.5 ms and 1 ms.
>> It is then possible to convert the difference between two jiffie/bogo_ms
>> values to a number of ms using a 32 bit multiply and a right shift of 16
>> bits, with essentially negligible error. get_bogo_ms() would return a
>> 32 bit number in bogo_ms, thus the timing loop would be written.
>>
>> u32 start_time = get_bogo_ms();
>> do {
>> if ("data_ready")
>> /* transfer a byte */
>> if (bogo_ms_to_ms(get_timer() - start_time)> TIMEOUT_IN_MS)
>> /* fail and exit loop */
>> } while (--"bytestodo"> 0);
>>
>> u32 get_bogo_ms()
>> {
>> u64 tick;
>> read(tick);
>>
>> return (tick>> gd->timer_shift);
>> }
>> u32 bogo_ms_to_ms(u32 x)
>> {
>> /* this code assumes the resulting ms will be between 0 and 65535,
>> or 65 seconds */
>> return ((x * gd->cvt_bogo_ms_to_ms)>> 16); /* cvt_bogo_ms_to_ms
>> is a 16 bit binary fraction */
>> }
>>
>> All the above code assumes timeouts are 65 seconds or less, which I
>> think is probably fair. Conversion of ms values up to 65 seconds to
>> bogo_ms is also easy, and a 32 bit multiplied result is all that is
>> required.
>> What is not so easy is converting a 32 bit timer value to ms. It can be
>> done if the CPU can do a 32 by 32 multiply to produce a 64 bit result,
>> use the msb, and possibly correct the result by an add if bit 32,of the
>> timer is set. You need a 33 bit counter in bogo_ms to get a monotonic,
>> accurate 32 bit counter in ms. The powerpc can use a mulhw operation to
>> do this, and any CPU that will produce a 64 bit product can do this.
>> However, many CPUs do not produce 64 bit products easily. Using division
>> to do these operations are even less appealing, as many CPUs do not
>> provide hardware division at all. Since it is not necessary to do this
>> conversion to easily use timeouts with 1 ms resolution and accuracy, I
>> think the idea of not using a timer in ms but rather bogo_ms/jiffies is
>> possibly better?
>>
>> Best Regards,
>> Bill Campbell
>
> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't
> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would
> not go through the full 32-bit range, which would cause issues with the
> timing loops on rollover -- and while a timeout of more than 65 sec may
> not be too likely, a timeout starting near the wraparound value of
> bogo_ms still could happen.
I agree with the possibility of wrap around near the end of u32 'bogo_ms'
counter. Therefore we do need to define some constraints for such a '64 bit
free running tick counter'. It could be implemented to overflow in some seconds
as the u32 bogo_ms would do.
> Besides, the 'tick' unit of time makes physical sense but the bogo_ms
> would not, while still not being a common timing value -- reminds me of
> my ms_to_ticks conversion macro that Wolfgang did not like.
I also dislike to have another virtual physical dimension defined here.
> In a more general perspective, I'd like to see where where exactly we
> need 64-bit multiply/divide operations in Wolfgang's proposal before we
> try to get rid of it. In my understanding:
>
> - get_timer() works in pure ticks, not ms, and thus does not need
> multiply/divide; it may at most need to implement a carry over from 32
> bit to 64 bits *if* the HW counter is 32 bits *and if* we want a 64-bit
> virtual counter.
>
> - get_time() works in ms, and thus needs scale conversion, so possibly a
> multiply/divide but possibly some other method, to convert a tick value
> to an ms value.
>
> That's where I come back to one point of my proposal: if we can get a
> general framework for get_timer() to return a 64-bit free-running tick
> value, then we might not need a ms-based get_time() at all, because we
> could use get_timer() as well for ms timings, provided we can convert
> our timeout from ms to ticks, i.e.
>
> /* let's wait 200 milliseconds */
> /* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
> timeout = ms_to_ticks(200);
> u32 start = get_timer(); /* start time, in ticks */
> do {
> ...
> } while ( (get_timer() -start) < timeout);
You may think about the following change to this proposal:
/* lets wait 200 ms */
/* get the end point of our timeout in ticks */
u64 timeout_end = get_timer() + ms_to_ticks(200);
do {
...
} while ( get_timer() < timeout_end);
If I got Reinhard's proposal correct this is exactly what he meant. He call it
'timer_init(timeout_val)' and 'is_timeout()' but I feel this is exactly what he
described.
First we calculate the t
