[U-Boot] [PATCH] smc911x MII made available
From: Helmut Raiger
The driver already had the MII functions, but they have not been
registered using miiphy_register().
---
drivers/net/smc911x.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index aeafeba..8753588 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -235,6 +235,25 @@ static int smc911x_rx(struct eth_device *dev)
return 0;
}
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+/* wrapper for smc911x_miiphy_read */
+static int mii_phy_read(char *devname, u8 phy, u8 reg, u16 *val)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ if (dev)
+ return smc911x_miiphy_read(dev, phy, reg, val);
+ return -1;
+}
+/* wrapper for smc911x_miiphy_write */
+static int mii_phy_write(char *devname, u8 phy, u8 reg, u16 val)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ if (dev)
+ return smc911x_miiphy_write(dev, phy, reg, val);
+ return -1;
+}
+#endif
+
int smc911x_initialize(u8 dev_num, int base_addr)
{
unsigned long addrl, addrh;
@@ -273,5 +292,10 @@ int smc911x_initialize(u8 dev_num, int base_addr)
sprintf(dev->name, "%s-%hu", DRIVERNAME, dev_num);
eth_register(dev);
+
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+ miiphy_register(dev->name, mii_phy_read, mii_phy_write);
+#endif
+
return 1;
}
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi Aneesh, On 27.06.2011 08:29, Aneesh V wrote: >> I wonder why do we need this whole spl thing in the first place (well, >> surely I know what they are used for but why do we need a separate entity >> for this)? Isn't it just the same U-Boot in, well, very special >> configuration >> (minimal set of drivers, no shell, etc)? Why do we need a whole shadow >> tree >> at spl/ instead of just providing the _configuration_? >> >> Am I missing something? > > The reason is that the regular U-Boot is not configurable enough to > build the extremely small images that should fit in internal RAM. The > last time I attempted, I ended up getting an ~60KB image for > OMAP4(that too without any of the hardware initialization I am adding > in my SPL work). Yes, surely I understand that currently U-Boot is not configurable enough to meet hard SPL constraints. But why don't we add the required configuration options instead of implementing the SPL thing separately? Again, maybe I'm missing something but it looks like not very difficult task to add the required configuration options and this approach seems to be more straight to me... >> Aneesh, what's the state of your patches? I'm especially interrested in >> OMAP3 (AM3517) support. Maybe I will be able to help you. > > I should be able to send out an updated revision of my series once we > finalize on the new framework for SPL. > > BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. > That can be integrated with my work and we will get an SPL that > supports both MMC and NAND. I guess Simon Schwarz is also doing some > work lately on OMAP3. Thanks for the pointers, I will take a look. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ORIGEN Board Support
Adds support for ORIGEN board with MMC Booting. Chander Kashyap (2): ARMV7: Add support for Samsung ORIGEN board ORIGEN: Add MMC SPL support MAINTAINERS |1 + board/samsung/origen/Makefile | 46 ++ board/samsung/origen/lowlevel_init.S | 468 + board/samsung/origen/mem_setup.S | 392 + board/samsung/origen/origen.c | 103 + boards.cfg|1 + include/configs/origen.h | 167 mmc_spl/board/samsung/origen/Makefile | 105 + mmc_spl/board/samsung/origen/mmc_boot.c | 75 mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 ++ mmc_spl/board/samsung/origen/u-boot.lds | 86 11 files changed, 1583 insertions(+), 0 deletions(-) create mode 100644 board/samsung/origen/Makefile create mode 100644 board/samsung/origen/lowlevel_init.S create mode 100644 board/samsung/origen/mem_setup.S create mode 100644 board/samsung/origen/origen.c create mode 100644 include/configs/origen.h create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARMV7: Add support for Samsung ORIGEN board
Origen board is based upon S5PV310 SoC which is similiar to
S5PC210 SoC.
Signed-off-by: Chander Kashyap
---
MAINTAINERS |1 +
board/samsung/origen/Makefile| 46
board/samsung/origen/lowlevel_init.S | 468 ++
board/samsung/origen/mem_setup.S | 392
board/samsung/origen/origen.c| 103
boards.cfg |1 +
include/configs/origen.h | 167
7 files changed, 1178 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/origen/Makefile
create mode 100644 board/samsung/origen/lowlevel_init.S
create mode 100644 board/samsung/origen/mem_setup.S
create mode 100644 board/samsung/origen/origen.c
create mode 100644 include/configs/origen.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 30c327b..c233f82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -707,6 +707,7 @@ Minkyu Kang
Chander Kashyap
SMDKV310ARM ARMV7 (S5PC210 SoC)
+ origen ARM ARMV7 (S5PC210 SoC)
Frederik Kriewitz
diff --git a/board/samsung/origen/Makefile b/board/samsung/origen/Makefile
new file mode 100644
index 000..65eff91
--- /dev/null
+++ b/board/samsung/origen/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# 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
+
+SOBJS := mem_setup.o
+SOBJS += lowlevel_init.o
+COBJS += origen.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/origen/lowlevel_init.S
b/board/samsung/origen/lowlevel_init.S
new file mode 100644
index 000..cbb3c45
--- /dev/null
+++ b/board/samsung/origen/lowlevel_init.S
@@ -0,0 +1,468 @@
+/*
+ * Lowlevel setup for ORIGEN board based on S5PV310
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * 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
+#include
+#include
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+#define MEM_DLLl_ON
+
+_TEXT_BASE:
+ .word CONFIG_SYS_TEXT_BASE
+
+ .globl lowlevel_init
+lowlevel_init:
+ push{lr}
+
+ /* r5 has always zero */
+ mov r5, #0
+ ldr r7, =S5PC210_GPIO_PART1_BASE
+ ldr r6, =S5PC210_GPIO_PART2_BASE
+
+ /* check reset status */
+ ldr r0, =(S5PC210_POWER_BASE + 0x804) @ INFORM1
+ ldr r1, [r0]
+
+ /* AFTR wakeup reset */
+ ldr r2, =S5P_CHECK_DIDLE
+ cmp r1, r2
+ beq exit_wakeup
+
+ /* Sleep wakeup reset */
+ ldr r2, =S5P_CHECK_SLEEP
+ cmp r1, r2
+ beq wakeup_reset
+
+ /*
+* If U-boot is already running in ram, no need to relocate U-Boot.
+* Memory controller must be configured before relocating U-Boot
+* in ram.
+*/
+ ldr r0, =0x0ff /* r0 <- Mask Bits*/
+ bic r1, pc, r0 /* pc <- current addr of
[U-Boot] [PATCH 2/2] ORIGEN: Add MMC SPL support
Adds mmc boot support.
Signed-off-by: Chander Kashyap
---
mmc_spl/board/samsung/origen/Makefile | 105
mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++
mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 +
mmc_spl/board/samsung/origen/u-boot.lds | 86 +
4 files changed, 405 insertions(+), 0 deletions(-)
create mode 100644 mmc_spl/board/samsung/origen/Makefile
create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c
create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c
create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds
diff --git a/mmc_spl/board/samsung/origen/Makefile
b/mmc_spl/board/samsung/origen/Makefile
new file mode 100644
index 000..7b62684
--- /dev/null
+++ b/mmc_spl/board/samsung/origen/Makefile
@@ -0,0 +1,105 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering,
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics,
+#
+# 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_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/mmc_spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_PRELOADER
+
+SOBJS = start.o mem_setup.o lowlevel_init.o
+COBJS = mmc_boot.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR := $(OBJTREE)/mmc_spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/mmc_spl/
+
+
+MKV310_MMC_SPL_EXEC = mkv310_mmc_spl_exec
+MMC_SPL_BIN = u-boot-mmc-spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:$(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN): $(mmcobj)u-boot-spl.bin tools/$(MKV310_MMC_SPL_EXEC)
+ ./tools/$(MKV310_MMC_SPL_EXEC) $(mmcobj)u-boot-spl.bin
$(mmcobj)$(MMC_SPL_BIN)
+ rm -f tools/$(MKV310_MMC_SPL_EXEC)
+
+tools/$(MKV310_MMC_SPL_EXEC): tools/mkv310_image.c
+ $(HOSTCC) tools/mkv310_image.c -o tools/$(MKV310_MMC_SPL_EXEC)
+
+$(mmcobj)u-boot-spl.bin: $(mmcobj)u-boot-spl
+ $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
+
+$(mmcobj)u-boot-spl: $(OBJS) $(mmcobj)u-boot.lds
+ cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
+ -Map $(mmcobj)u-boot-spl.map \
+ -o $(mmcobj)u-boot-spl
+
+$(mmcobj)u-boot.lds: $(LDSCRIPT)
+ $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
+
+# create symbolic links for common files
+
+# from cpu directory
+start.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/arch/arm/cpu/armv7/start.S $@
+
+# from board directory
+mem_setup.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/origen/mem_setup.S $@
+
+lowlevel_init.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/origen/lowlevel_init.S $@
+
+#
+
+$(obj)%.o: %.S
+ $(CC) $(AFLAGS) -c -o $@ $<
+
+$(obj)%.o: %.c
+ $(CC) $(CFLAGS) -c -o $@ $<
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/mmc_spl/board/samsung/origen/mmc_boot.c
b/mmc_spl/board/samsung/origen/mmc_boot.c
new file mode 100644
index 000..459d27d
--- /dev/null
+++ b/mmc_spl/board/samsung/origen/mmc_boot.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * 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.
+ *
Re: [U-Boot] SPL framework re-design
Hi, > You mentioned that /spl can not be used for source files. Isn't there a > way to workaround this problem? Why should we have source files in a SPL directory? I would prefer to have spl specific sources right where the rest ist - maybe marked with something like _spl or excluded by some #define-test. If we have a SPL specific directory we have to copy most of the tree (arch/cpu etc.) which in my eyes is totally unnecessary if we don't do the symlinking stuff... > Also, I agree with Scott's opinion that re-compiling some files while > re-using the binary of some other files won't be a good idea. In this > case, CONFIG_PRELOADER will be honored in some files but not in other > files. That will be a source of confusion for developers. I also see this as the biggest problem with reusing the object-files. It will add more complexity than a simple re-run with different flags like suggested by Daniel. > BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. > That can be integrated with my work and we will get an SPL that > supports both MMC and NAND. I guess Simon Schwarz is also doing some > work lately on OMAP3. I am working on OMAP3 (on devkit8000). If this discussion comes to a conclusion soon I would prefer sending the patches with the new SPL format. Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi Ilya, On Monday 27 June 2011 01:54 PM, Ilya Yanok wrote: > Hi Aneesh, > > On 27.06.2011 08:29, Aneesh V wrote: >>> I wonder why do we need this whole spl thing in the first place (well, >>> surely I know what they are used for but why do we need a separate entity >>> for this)? Isn't it just the same U-Boot in, well, very special >>> configuration >>> (minimal set of drivers, no shell, etc)? Why do we need a whole shadow >>> tree >>> at spl/ instead of just providing the _configuration_? >>> >>> Am I missing something? >> >> The reason is that the regular U-Boot is not configurable enough to >> build the extremely small images that should fit in internal RAM. The >> last time I attempted, I ended up getting an ~60KB image for >> OMAP4(that too without any of the hardware initialization I am adding >> in my SPL work). > > Yes, surely I understand that currently U-Boot is not configurable > enough to meet hard SPL constraints. But why don't we add the required > configuration options instead of implementing the SPL thing separately? > Again, maybe I'm missing something but it looks like not very difficult > task to add the required configuration options and this approach seems > to be more straight to me... > I agree. SPL, as I understand, was an easy workaround for this problem. But if we are spending a lot of time on SPL framework, we may rather solve the real problem(Oh no, I am not volunteering:-)) Honestly, I have no idea how much effort that will be. Actually, I had raised this point sometime back. But that was more in favor of keeping SPL the way it is now and not adding anymore complexity. http://news.gmane.org/find-root.php?group=gmane.comp.boot-loaders.u-boot&article=100550 best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh, In message <4e0804dc.8090...@ti.com> you wrote: > > >> +spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend > >> + $(MAKE) -C spl/ all > >> + > >>$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl > > > > The mmc_spl/ is suppoed to be moved into spl/, isn't it? > > This patch was intended only as a prototype for the new directory > structure. I didn't bother to touch the existing stuff. I see. > >> --- /dev/null > >> +++ b/spl/Makefile > >> @@ -0,0 +1,94 @@ > >> +# > >> +# (C) Copyright 2011 Daniel Schwierzeck, > >> daniel.schwierz...@googlemail.com. > > > > Really??? > > I copied Daniel's Makefile and started from there. I guess the only real part that was left from the old file is the GPL header... > > As Mike mentioned, we can eventually directly include the OBJSs here > > and omit the building of libraries? > > I can't seem to find a mail from Mike on this thread. Did I miss any > mail? I can find it either. I don't know what I had in mind then. > Do you mean re-using equivalent libraries from the normal U-Boot > without re-compiling them? There are actually two different topics here: - The first is how to link all the objects in the spl/ tree together. As I understand, you proposal was to link all objects in each of the subdirectories into a library, and then link all the libraries together. Instead of doing this, we could as well just maintain a list of objects and then link all these together directly, without creating libraries first. - The other topic is if to build new object files, and where. At the moment we have two situations: * Some files are built with special options such that unneeded code gets commented out using respecive #ifdef's / #ifndef's. We can probably get rid of (most of ?) these #ifdef's / #ifndef's when properly using -ffunction-sections / --gc-sections Why should we then recompile the code? * Some files (start.S) really need different code. Here the questions is more how and where to recompile using proper options. I would be glad if we could get rid of the symlinking. Maybe we can add respective build rules to the original Makefiles (see also proposal by Ilya, http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102033 ), eventually just using a different suffix, say ".splo" instead of ".o"? > > allow for vendor directories (where "BOARDDIR = $(VENDOR)/$(BOARD)"). > > I didn't want to make the directory structure any longer than required. > But I can add this if required. It will be needed. > > Hm... can we try to do without the symlinks? > > Well. I think it's difficult. Most of my hardware initialization such > as clock init, SDRAM init etc need to know under what context it > is getting executed. The context can be: > 1. SPL > 2. Regular U-Boot executing from NOR flash > 3. Regular U-Boot executing from SDRAM > etc. Agreed - we need another, independent set of object files. But cannot we create these in the existent source tree? > If you want to do away with symlinks, I would propose going with > Daniel's approach. This uses /spl as a remote building directory, but > do not create any symlinks. Yes, this is an improvement over the current situation - but Ilya's question is a good one: why do we need the pl/ subtree in the first place? 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 "You shouldn't make my toaster angry." - Household security explained in "Johnny Quest" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Ilya, In message you wrote: > > I wonder why do we need this whole spl thing in the first place (well, > surely I know what they are used for but why do we need a separate entity > for this)? Isn't it just the same U-Boot in, well, very special configuration > (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree > at spl/ instead of just providing the _configuration_? Good point. Eventually we can just add additional build rules for new object files (say, ".splo" instead of ".o") ? 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 "Have you lived in this village all your life?""No, not yet." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh, In message <4e080733.2030...@ti.com> you wrote: > > > I wonder why do we need this whole spl thing in the first place (well, > > surely I know what they are used for but why do we need a separate entity > > for this)? Isn't it just the same U-Boot in, well, very special > > configuration > > (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree > > at spl/ instead of just providing the _configuration_? > > > > Am I missing something? > > The reason is that the regular U-Boot is not configurable enough to > build the extremely small images that should fit in internal RAM. The > last time I attempted, I ended up getting an ~60KB image for > OMAP4(that too without any of the hardware initialization I am adding > in my SPL work). This statement does not make much sense to me. If we can do it in the spl/ directory, we should be able to do it in any other directory as well. The worst to happen is that we have to keep two setsof object files separated, but chosing a different suffix should be sufficient. > BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. Yes, but AFAIR he never followed up to the requested changes. > That can be integrated with my work and we will get an SPL that > supports both MMC and NAND. I guess Simon Schwarz is also doing some > work lately on OMAP3. OK, so we have all the more reason to do this thorougly now. 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 Applying computer technology is simply finding the right wrench to pound in the correct screw. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] promo
Your Email Id has won 1,000,000.00 GBP in the British MICROSOFT Promo 2011. send your Names. Address. Sex. Age. Tel. Occupation. to our claims department: carl_rob...@hotmail.com Thank you for your full corporation. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
> -Original Message- > From: Igor Grinberg [mailto:grinb...@compulab.co.il] > Sent: Monday, June 27, 2011 12:17 PM > To: Premi, Sanjeev > Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet > reset sequence for Rev.G board > > On 06/27/11 08:06, Premi, Sanjeev wrote: > > >> -Original Message- > >> From: Premi, Sanjeev > >> Sent: Thursday, June 23, 2011 4:48 PM > >> To: Premi, Sanjeev; Igor Grinberg > >> Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de > >> Subject: RE: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet > >> reset sequence for Rev.G board > >> > >>> -Original Message- > >>> From: u-boot-boun...@lists.denx.de > >>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev > >>> Sent: Thursday, June 23, 2011 4:43 PM > >>> To: Igor Grinberg > >>> Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de > >>> Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet > >>> reset sequence for Rev.G board > >>> > -Original Message- > From: Igor Grinberg [mailto:grinb...@compulab.co.il] > Sent: Thursday, June 23, 2011 2:38 PM > To: Premi, Sanjeev > Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan > Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet > reset sequence for Rev.G board > > Hi Sanjeev, > > On 06/22/11 22:24, Sanjeev Premi wrote: > > From: Sriramakrishnan > > > > The GPIO pin used for resetting the external LAN chip has > > changed for Rev.G board. > > > > Signed-off-by: Sriramakrishnan > > Signed-off-by: Sanjeev Premi > > --- > > board/ti/evm/evm.c | 27 ++- > > 1 files changed, 18 insertions(+), 9 deletions(-) > > > > [snip]...[snip] > > > > + /* Send a pulse on the GPIO pin */ > > + writel(pin, &gpio_base->setdataout); > > udelay(1); > > - writel(GPIO0, &gpio3_base->cleardataout); > > + writel(pin, &gpio_base->cleardataout); > > udelay(1); > > - writel(GPIO0, &gpio3_base->setdataout); > > + writel(pin, &gpio_base->setdataout); > Why keep messing with the gpio registers? > Why not use gpio framework? > Though it is omap specific, but it will be much cleaner then > the above. > >>> [sp] I guess the intent was to keep code similar. But yes, > >>> gpio framework can be used. > >>> > >> [sp] Sorry, mail went earlier than I wanted :( > >> > >> The only issue is that I couln't see gpio framework for omap. > >> Let me dig further... > >> > > [sp] Implementing GPIO for OMAP would be a long task. It should be > > done for long term; but is it necessary pre-condition for the > > patch? > > There is no need to implement GPIO for OMAP. It is already there, > you just need to use it instead of writing directly to the > GPIO registers. > You can find all the implementation in: > arch/arm/cpu/armv7/omap3/gpio.c > and the header is: arch/arm/include/asm/arch-omap3/gpio.h [sp] No wonder, I couldn't find it in drivers/gpio. (Didn't occur that it could be in ARCH specific dir) Will rebase and send an updated patch soon. ~sanjeev > > All you need is to include the header, request the appropriate gpio, > send the pulse and maybe (if you don't need it anymore) free > that gpio. > This is not hard or long at all. > > > > -- > Regards, > Igor. > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Email;uk.claims.department2...@live.com
You have been selected for a cash prize of £800,000.Contact with the below information for claim./Name/Tell/Occupation/Address/Age/via Email;uk.claims.department2...@live.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi, On Mon, Jun 27, 2011 at 11:27 AM, Wolfgang Denk wrote: > Dear Ilya, > > In message you wrote: >> >> I wonder why do we need this whole spl thing in the first place (well, >> surely I know what they are used for but why do we need a separate entity >> for this)? Isn't it just the same U-Boot in, well, very special configuration >> (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree >> at spl/ instead of just providing the _configuration_? I guess that is because the discussion started with several directories (nand_spl, mmc_spl etc.) which should be merged into a single spl directory. > > Good point. Eventually we can just add additional build rules for > new object files (say, ".splo" instead of ".o") ? I agree this approach seems to be the best one. But then we have to create SPL-specific libraries too, right? (e.g. lib$(ARCH).splo, lib$(CPU).splo) Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Monday 27 June 2011 02:57 PM, Wolfgang Denk wrote: > Dear Aneesh, > > In message<4e0804dc.8090...@ti.com> you wrote: >> +spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend + $(MAKE) -C spl/ all + $(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl >>> >>> The mmc_spl/ is suppoed to be moved into spl/, isn't it? >> >> This patch was intended only as a prototype for the new directory >> structure. I didn't bother to touch the existing stuff. > > I see. > --- /dev/null +++ b/spl/Makefile @@ -0,0 +1,94 @@ +# +# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com. >>> >>> Really??? >> >> I copied Daniel's Makefile and started from there. > > I guess the only real part that was left from the old file is the GPL > header... > >>> As Mike mentioned, we can eventually directly include the OBJSs here >>> and omit the building of libraries? >> >> I can't seem to find a mail from Mike on this thread. Did I miss any >> mail? > > I can find it either. I don't know what I had in mind then. > >> Do you mean re-using equivalent libraries from the normal U-Boot >> without re-compiling them? > > There are actually two different topics here: > > - The first is how to link all the objects in the spl/ tree together. >As I understand, you proposal was to link all objects in each of the >subdirectories into a library, and then link all the libraries >together. > >Instead of doing this, we could as well just maintain a list of >objects and then link all these together directly, without creating >libraries first. > Is this like a make variable that keeps accumulating objects from sub-directories? If so, is that through a *.mk at each level and including all these *.mk at the top level Makefile. Or is there some other idea? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2] omap3evm: Update ethernet reset sequence for Rev.G board
From: Sriramakrishnan
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
The patch uses generic gpio API instead of direct access
to corresponding registers.
Signed-off-by: Sriramakrishnan
Signed-off-by: Sanjeev Premi
---
Changes since v1:
* Use of gpio API instead of direct register access.
Tested basic ethernet operations - dhcp and tftpboot - on the
OMAP3EVM Rev G to load kernel and ramdisk images.
board/ti/evm/evm.c | 35 ++-
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..2c95fae 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -33,10 +33,14 @@
#include
#include
#include
+#include
#include
#include
#include "evm.h"
+#define OMAP3EVM_GPIO_ETH_RST_GEN1 64
+#define OMAP3EVM_GPIO_ETH_RST_GEN2 7
+
DECLARE_GLOBAL_DATA_PTR;
static u32 omap3_evm_version;
@@ -181,17 +185,30 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(&gpio3_base->oe) & ~(GPIO0), &gpio3_base->oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, &gpio3_base->setdataout);
+ int ret;
+ int rst_gpio;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ rst_gpio = OMAP3EVM_GPIO_ETH_RST_GEN1;
+ } else {
+ rst_gpio = OMAP3EVM_GPIO_ETH_RST_GEN2;
+ }
+
+ ret = omap_request_gpio(rst_gpio);
+ if (ret < 0) {
+ printf("Unable to get GPIO %d\n", rst_gpio);
+ return ;
+ }
+
+ /* Configure as output */
+ omap_set_gpio_direction(rst_gpio, 0);
+
+ /* Send a pulse on the GPIO pin */
+ omap_set_gpio_dataout(rst_gpio, 1);
udelay(1);
- writel(GPIO0, &gpio3_base->cleardataout);
+ omap_set_gpio_dataout(rst_gpio, 0);
udelay(1);
- writel(GPIO0, &gpio3_base->setdataout);
+ omap_set_gpio_dataout(rst_gpio, 1);
}
int board_eth_init(bd_t *bis)
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 11:27:31 +0200 Wolfgang Denk wrote: > Dear Ilya, > > In message you wrote: > > > > I wonder why do we need this whole spl thing in the first place (well, > > surely I know what they are used for but why do we need a separate entity > > for this)? Isn't it just the same U-Boot in, well, very special > > configuration > > (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree > > at spl/ instead of just providing the _configuration_? > > Good point. Eventually we can just add additional build rules for > new object files (say, ".splo" instead of ".o") ? No need for new extensions -- we should be able to use the target directory to influence rule selection. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 11:36:33 +0200 Wolfgang Denk wrote: > Dear Aneesh, > > In message <4e080733.2030...@ti.com> you wrote: > > > > > I wonder why do we need this whole spl thing in the first place (well, > > > surely I know what they are used for but why do we need a separate entity > > > for this)? Isn't it just the same U-Boot in, well, very special > > > configuration > > > (minimal set of drivers, no shell, etc)? Why do we need a whole shadow > > > tree > > > at spl/ instead of just providing the _configuration_? > > > > > > Am I missing something? > > > > The reason is that the regular U-Boot is not configurable enough to > > build the extremely small images that should fit in internal RAM. The > > last time I attempted, I ended up getting an ~60KB image for > > OMAP4(that too without any of the hardware initialization I am adding > > in my SPL work). > > This statement does not make much sense to me. If we can do it in the > spl/ directory, we should be able to do it in any other directory as > well. The worst to happen is that we have to keep two setsof object > files separated, but chosing a different suffix should be sufficient. We do it in the spl/ directory by bypassing the normal makefile config system, specifying a board-and-spl-specific list of objects instead. It could of course be done with the standard config system, but it will require that every bit of code in U-Boot be enabled only with a particular config option -- no "always on" code. This would be a good thing anyway, but it will take some work to do it cleanly. A first step would probably be a global "finegrained/small" flag that configs use to opt into the new system, but eventually all bits of functionality should have appropriate individual config symbols. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x MII made available
On Monday, June 27, 2011 03:22:03 helmut.rai...@hale.at wrote: > From: Helmut Raiger > > The driver already had the MII functions, but they have not been > registered using miiphy_register(). missing signed-off-by tag > +static int mii_phy_read(char *devname, u8 phy, u8 reg, u16 *val) this name is already in common name space in mii_phy.h. all driver funcs really should be prefixed anyways. so perhaps: smc911x_mii_phy_read -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Display a warning for unsupported DDR data rates
If DDR initialziation uses a speed table and the speed is not matched, print
a warning message instead of silently ignoring.
Signed-off-by: York Sun
---
board/freescale/corenet_ds/ddr.c |6 ++
board/freescale/mpc8572ds/ddr.c |8
board/freescale/mpc8641hpcn/ddr.c |5 +
board/freescale/p2020ds/ddr.c |6 ++
board/xes/xpedite550x/ddr.c |6 ++
5 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index f2b716d..a184592 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -192,10 +192,16 @@ void fsl_ddr_board_options(memctl_options_t *popts,
popts->clk_adjust = pbsp->clk_adjust;
popts->wrlvl_start = pbsp->wrlvl_start;
popts->twoT_en = pbsp->force_2T;
+ break;
}
pbsp++;
}
+ if (i == num_params) {
+ printf("Warning: board specific timing not found "
+ "for data rate %lu MT/s!\n", ddr_freq);
+ }
+
/*
* Factors to consider for half-strength driver enable:
* - number of DIMMs installed
diff --git a/board/freescale/mpc8572ds/ddr.c b/board/freescale/mpc8572ds/ddr.c
index ab471af..adcbd58 100644
--- a/board/freescale/mpc8572ds/ddr.c
+++ b/board/freescale/mpc8572ds/ddr.c
@@ -104,7 +104,6 @@ void fsl_ddr_board_options(memctl_options_t *popts,
u32 num_params;
u32 i;
ulong ddr_freq;
- int matched = 0;
if (!pdimm->n_ranks)
return;
@@ -151,14 +150,15 @@ void fsl_ddr_board_options(memctl_options_t *popts,
popts->cpo_override = pbsp->cpo;
popts->write_data_delay = pbsp->write_data_delay;
popts->twoT_en = pbsp->force_2T;
- matched = 1;
break;
}
pbsp++;
}
- if (!matched)
- printf("Warning: board specific timing not found!\n");
+ if (i == num_params) {
+ printf("Warning: board specific timing not found "
+ "for data rate %lu MT/s!\n", ddr_freq);
+ }
/*
* Factors to consider for half-strength driver enable:
diff --git a/board/freescale/mpc8641hpcn/ddr.c
b/board/freescale/mpc8641hpcn/ddr.c
index bd0b299..4f2e853 100644
--- a/board/freescale/mpc8641hpcn/ddr.c
+++ b/board/freescale/mpc8641hpcn/ddr.c
@@ -127,6 +127,11 @@ void fsl_ddr_board_options(memctl_options_t *popts,
}
}
+ if (i == num_params) {
+ printf("Warning: board specific timing not found "
+ "for data rate %lu MT/s!\n", ddr_freq);
+ }
+
/* 2T timing enable */
popts->twoT_en = 1;
}
diff --git a/board/freescale/p2020ds/ddr.c b/board/freescale/p2020ds/ddr.c
index 9bf7d2f..926fd19 100644
--- a/board/freescale/p2020ds/ddr.c
+++ b/board/freescale/p2020ds/ddr.c
@@ -83,10 +83,16 @@ void fsl_ddr_board_options(memctl_options_t *popts,
popts->cpo_override = pbsp->cpo;
popts->write_data_delay = pbsp->write_data_delay;
popts->twoT_en = pbsp->force_2T;
+ break;
}
pbsp++;
}
+ if (i == num_params) {
+ printf("Warning: board specific timing not found "
+ "for data rate %lu MT/s!\n", ddr_freq);
+ }
+
/*
* Factors to consider for half-strength driver enable:
* - number of DIMMs installed
diff --git a/board/xes/xpedite550x/ddr.c b/board/xes/xpedite550x/ddr.c
index 3b6e08b..8031a34 100644
--- a/board/xes/xpedite550x/ddr.c
+++ b/board/xes/xpedite550x/ddr.c
@@ -125,10 +125,16 @@ void fsl_ddr_board_options(memctl_options_t *popts,
popts->clk_adjust = pbsp->clk_adjust;
popts->cpo_override = pbsp->cpo;
popts->twoT_en = 0;
+ break;
}
pbsp++;
}
+ if (i == num_params) {
+ printf("Warning: board specific timing not found "
+ "for data rate %lu MT/s!\n", ddr_freq);
+ }
+
/*
* Factors to consider for half-strength driver enable:
* - number of DIMMs installed
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc8xxx: fix DDR data width checking
Checking width before setting DDR controller. SPD for DDR1 and DDR2 has data
width and primary sdram width. The latter one has different meaning for DDR3.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/options.c | 35 ---
1 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index 02efe58..bd9c466 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -423,14 +423,33 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
* presuming all dimms are similar
* 0 = 64-bit, 1 = 32-bit, 2 = 16-bit
*/
- if (pdimm[0].primary_sdram_width == 64)
- popts->data_bus_width = 0;
- else if (pdimm[0].primary_sdram_width == 32)
- popts->data_bus_width = 1;
- else if (pdimm[0].primary_sdram_width == 16)
- popts->data_bus_width = 2;
- else
- panic("Error: invalid primary sdram width!\n");
+#if defined(CONFIG_FSL_DDR1) || defined(CONFIG_FSL_DDR2)
+ if (pdimm[0].n_ranks != 0) {
+ if ((pdimm[0].data_width >= 64) && \
+ (pdimm[0].data_width <= 72))
+ popts->data_bus_width = 0;
+ else if ((pdimm[0].data_width >= 32) || \
+ (pdimm[0].data_width <= 40))
+ popts->data_bus_width = 1;
+ else {
+ panic("Error: data width %u is invalid!\n",
+ pdimm[0].data_width);
+ }
+ }
+#else
+ if (pdimm[0].n_ranks != 0) {
+ if (pdimm[0].primary_sdram_width == 64)
+ popts->data_bus_width = 0;
+ else if (pdimm[0].primary_sdram_width == 32)
+ popts->data_bus_width = 1;
+ else if (pdimm[0].primary_sdram_width == 16)
+ popts->data_bus_width = 2;
+ else {
+ panic("Error: primary sdram width %u is invalid!\n",
+ pdimm[0].primary_sdram_width);
+ }
+ }
+#endif
/* Choose burst length. */
#if defined(CONFIG_FSL_DDR3)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/corenet_ds: Fix RCW overriding for RDIMM
Allow overriding RCW for all RDIMM, not only quad-rank ones.
Signed-off-by: York Sun
---
board/freescale/corenet_ds/ddr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index 98024c7..f2b716d 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -219,7 +219,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
popts->ddr_cdr1 = DDR_CDR1_DHC_EN;
/* override SPD values. rcw_2 should vary at differnt speed */
- if (pdimm[0].n_ranks == 4) {
+ if (pdimm[0].registered_dimm == 1) {
popts->rcw_override = 1;
popts->rcw_1 = 0x000a5a00;
if (ddr_freq <= 800)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Daniel, In message you wrote: > > > Good point. Eventually we can just add additional build rules for > > new object files (say, ".splo" instead of ".o") ? > > I agree this approach seems to be the best one. > But then we have to create SPL-specific libraries too, right? > (e.g. lib$(ARCH).splo, lib$(CPU).splo) Not necessarily. We might instead just link the object files we build. 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 "This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you?" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message <4e089a25.4050...@ti.com> you wrote: > > >Instead of doing this, we could as well just maintain a list of > >objects and then link all these together directly, without creating > >libraries first. > > Is this like a make variable that keeps accumulating objects > from sub-directories? If so, is that through a *.mk at each level and > including all these *.mk at the top level Makefile. Or is there some > other idea? Well, if we do it right and build only such objects we actually need for the target binary, we might not need any explicit rules at all and instead just use file globbing to link all objects we find. 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 express preference for a chronological sequence of events which precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message <20110627133435.31cd3...@schlenkerla.am.freescale.net> you wrote: > > > Good point. Eventually we can just add additional build rules for > > new object files (say, ".splo" instead of ".o") ? > > No need for new extensions -- we should be able to use the target > directory to influence rule selection. But if we do not create a new hierarchy of target directories we will have the "normal" and the "spl" objects in parallel (and I don't want to delete one when building the other). 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 Karl's version of Parkinson's Law: Work expands to exceed the time alloted it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message <20110627134205.021af...@schlenkerla.am.freescale.net> you wrote: > > > This statement does not make much sense to me. If we can do it in the > > spl/ directory, we should be able to do it in any other directory as > > well. The worst to happen is that we have to keep two setsof object > > files separated, but chosing a different suffix should be sufficient. > > We do it in the spl/ directory by bypassing the normal makefile > config system, specifying a board-and-spl-specific list of objects instead. We can provide such a "board-and-spl-specific list of objects" for the spl code in the normal Makefiles as well. > It could of course be done with the standard config system, but it will > require that every bit of code in U-Boot be enabled only with a particular > config option -- no "always on" code. This would be a good thing anyway, > but it will take some work to do it cleanly. A first step would probably > be a global "finegrained/small" flag that configs use to opt into the > new system, but eventually all bits of functionality should have > appropriate individual config symbols. If we do it right, we will only build such objects in spl configuration that are needed for the spl linking. So we can start with this finer control for spl initially, and then (later) extend it for "normal" builds as well. 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 only way to get rid of a temptation is to yield to it. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 22:50:46 +0200 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110627133435.31cd3...@schlenkerla.am.freescale.net> you wrote: > > > > > Good point. Eventually we can just add additional build rules for > > > new object files (say, ".splo" instead of ".o") ? > > > > No need for new extensions -- we should be able to use the target > > directory to influence rule selection. > > But if we do not create a new hierarchy of target directories we will > have the "normal" and the "spl" objects in parallel (and I don't want > to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message <20110627155535.4217b...@schlenkerla.am.freescale.net> you wrote: > > > But if we do not create a new hierarchy of target directories we will > > have the "normal" and the "spl" objects in parallel (and I don't want > > to delete one when building the other). > > What's wrong with creating a new hierarchy of target directories? It > would be like specifying a different output directory. The question came up what we need it 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 "I haven't lost my mind - it's backed up on tape somewhere." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 23:10:33 +0200 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110627155535.4217b...@schlenkerla.am.freescale.net> you wrote: > > > > > But if we do not create a new hierarchy of target directories we will > > > have the "normal" and the "spl" objects in parallel (and I don't want > > > to delete one when building the other). > > > > What's wrong with creating a new hierarchy of target directories? It > > would be like specifying a different output directory. > > The question came up what we need it for. Just seems cleaner to me than jamming it into the file extension. If we're treating it as a separate build, it should go into a separate place. It's not really a different type of file. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message <20110627161803.16783...@schlenkerla.am.freescale.net> you wrote: > > > > > But if we do not create a new hierarchy of target directories we will > > > > have the "normal" and the "spl" objects in parallel (and I don't want > > > > to delete one when building the other). > > > > > > What's wrong with creating a new hierarchy of target directories? It > > > would be like specifying a different output directory. > > > > The question came up what we need it for. > > Just seems cleaner to me than jamming it into the file extension. If we're > treating it as a separate build, it should go into a separate place. It's > not really a different type of file. I'm fine with that as well. 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 modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi All, Just thought I'd throw in a left-field idea... Could we make the loading of U-Boot into a generic multi-stage framework with each stage bootstrapping the next stage? OK, I know this is how IPL, SPL etc work already, but I'm thinking something more formal and arch independent. I can think of three disctinct phases which are relatively commong across most arch's (especially NAND Flash arches) 1) An intial page (say 256 bytes for example) which loads a second stage into the CPU's cache 2) A second phase running in the CPU cache which initialises SDRAM and loads the remainder into main memory (performs relocations etc) 3) A final phase which is U-Boot proper, running at the final target address in SDRAM Now what I'm thinking is that if we formalise these loader stages, we could actually add a little more flexibility by, say, allowing the final U-Boot binary to reside on a file-system. And even break the final binary up into smaller 'run-once-and-discard' chunks. For example, a lot of the low level init is only ever done once, but it stays in SDRAM as a permanent piece of the U-Boot image - What if the second stage loader could instead load an low-level init blob and run it before loading the final U-Boot blob? This then opens the door for all sort of options - What if U-Boot commands were build into stand-alone binary blobs and only loaded when needed. Same with device drivers So a lot of what is now build-time configuration could be reduced to run-time configuration Just a few wild ideas... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/9] armv7: cache maintenance operations
On 24 June 2011 04:24, Paulraj, Sandeep wrote: > > >> >> Hi All, >> >> Le 17/06/2011 11:30, Aneesh V a écrit : >> > With D-cache and MMU enabled for ARM in u-boot it becomes imperative to >> > support a minimal set of cache maintenance operations and necessary >> > initializations before enabling MMU. >> > >> > This series of patches attempt to do the following for armv7: >> > * Necessary initialization sequence before enabling MMU that includes >> > invalidation of TLB, data caches, branch predictor array etc. >> > * Framework for supporting SOC specific outer caches in a generic manner >> > (using a structure of function pointers - inspired by the Linux >> > implementation) >> > * Generic armv7 cache maintenance operations for caches known to the CPU >> > * Support for ARM PL310 L2 cache controller used in OMAP4 >> > * Cleanup of the cleanup_before_linux() function >> > * Adapting all armv7 SOCs to use the new framework and removing >> > duplicated code >> >> Sandeep, Minkyu: is the patch series OK with you? If so I'll pull it all >> in ARM and issue a last pull request. >> >> Amicalement, >> -- >> Albert. > > I am fine with it. > > Acked-by: Sandeep Paulraj Acked-by: Minkyu Kang Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Graeme Russ, In message you wrote: > > I can think of three disctinct phases which are relatively commong across > most arch's (especially NAND Flash arches) > > 1) An intial page (say 256 bytes for example) which loads a second stage >into the CPU's cache > 2) A second phase running in the CPU cache which initialises SDRAM and >loads the remainder into main memory (performs relocations etc) > 3) A final phase which is U-Boot proper, running at the final target >address in SDRAM The thing is that we have many different architectures, and NAND booting systems are just one configuration out of many. Depending on your architecture, the initialization of the RAM may be semi-automatic (with just very few parameters needed), or data-driven (you have to provide some magic data blob that gets interpreted by some ROM code), or completely manual (where you have to pay close attentian to insert the correct N microseconds delay here and there in your code, as required by the RAM data sheet). If you look back at the trouble reports from people who ported U-Boot (and Linux) to their platforms you can see that RAM initialization problems have always been a major problem area. This experience, collected over many years, has led to the design we have now: http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#6_Keep_it_Debuggable Having debug output on the console as soon as possible is a pretty important design goal; if technically possible, we do want to have debug output long before initializing the RAM. Unfortunately, this pulls in a lot of dependencies: bigger parts of the code like printf() and friends, access to the environment (to read the baudrate settings, etc.) > Now what I'm thinking is that if we formalise these loader stages, we > could actually add a little more flexibility by, say, allowing the final > U-Boot binary to reside on a file-system. And even break the final binary > up into smaller 'run-once-and-discard' chunks. For example, a lot of the > low level init is only ever done once, but it stays in SDRAM as a > permanent piece of the U-Boot image - What if the second stage loader > could instead load an low-level init blob and run it before loading the > final U-Boot blob? You would most probably lose the capability to have early debug messages. > This then opens the door for all sort of options - What if U-Boot commands > were build into stand-alone binary blobs and only loaded when needed. Same > with device drivers Device drivers clearly need a rework. But I'm not sure if dynamic loading is as easy as you imagine it - we have a large number of architectures here, and you need some support (drivers, file system [or other structured storage space]) to koads objects from external storage. > So a lot of what is now build-time configuration could be reduced to > run-time configuration It sounds like a nice idea, but I fear there are a lots of devils in the details. 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 memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hi Wolfgang, The following changes since commit 9623c158f6a5150a21c25026bfba79e7ff7912f5: Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-23 15:37:33 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Aneesh V (9): arm: make default implementation of cache_flush() weakly linked armv7: cache maintenance operations for armv7 armv7: rename cache related CONFIG flags armv7: integrate cache maintenance support arm: minor fixes for cache and mmu handling armv7: add PL310 support to u-boot armv7: adapt omap4 to the new cache maintenance framework armv7: adapt omap3 to the new cache maintenance framework armv7: adapt s5pc1xx to the new cache maintenance framework README| 11 + arch/arm/cpu/arm1136/start.S |4 +- arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/cache_v7.c | 394 + arch/arm/cpu/armv7/cpu.c | 50 ++-- arch/arm/cpu/armv7/omap3/Makefile |1 - arch/arm/cpu/armv7/omap3/board.c | 136 -- arch/arm/cpu/armv7/omap3/cache.S | 263 - arch/arm/cpu/armv7/omap3/lowlevel_init.S | 32 ++ arch/arm/cpu/armv7/omap4/board.c | 12 + arch/arm/cpu/armv7/omap4/lowlevel_init.S |9 + arch/arm/cpu/armv7/s5pc1xx/cache.S| 88 +- arch/arm/cpu/armv7/start.S| 18 +- arch/arm/include/asm/arch-omap3/omap3.h | 20 ++ arch/arm/include/asm/arch-omap3/sys_proto.h | 10 +- arch/arm/include/asm/arch-omap4/sys_proto.h |2 +- arch/arm/include/asm/arch-s5pc1xx/sys_proto.h |3 - arch/arm/include/asm/armv7.h | 67 + arch/arm/include/asm/global_data.h|2 +- arch/arm/include/asm/pl310.h | 73 + arch/arm/include/asm/utils.h | 56 arch/arm/lib/Makefile |3 +- arch/arm/lib/board.c |8 +- arch/arm/lib/cache-cp15.c | 22 +- arch/arm/lib/cache-pl310.c| 115 +++ arch/arm/lib/cache.c | 20 +- board/armltd/integrator/split_by_variant.sh |8 +- common/cmd_bdinfo.c |2 +- include/common.h |5 +- include/configs/B2.h |3 +- include/configs/assabet.h |2 +- include/configs/ca9x4_ct_vxp.h|2 +- include/configs/cerf250.h |2 +- include/configs/cradle.h |2 +- include/configs/csb226.h |2 +- include/configs/dnp1110.h |2 +- include/configs/efikamx.h |2 +- include/configs/evb4510.h |3 +- include/configs/gcplus.h |2 +- include/configs/innokom.h |2 +- include/configs/jornada.h |2 +- include/configs/lart.h|2 +- include/configs/lubbock.h |2 +- include/configs/mx51evk.h |2 +- include/configs/mx53evk.h |2 +- include/configs/omap4_panda.h |8 +- include/configs/omap4_sdp4430.h |8 +- include/configs/pleb2.h |2 +- include/configs/pxa255_idp.h |2 +- include/configs/s5pc210_universal.h |2 +- include/configs/shannon.h |2 +- include/configs/tegra2-common.h |2 +- include/configs/trizepsiv.h |2 +- include/configs/vision2.h |2 +- include/configs/xaeniax.h |2 +- include/configs/xm250.h |2 +- include/configs/zylonite.h|2 +- 57 files changed, 1048 insertions(+), 458 deletions(-) create mode 100644 arch/arm/cpu/armv7/cache_v7.c delete mode 100644 arch/arm/cpu/armv7/omap3/cache.S create mode 100644 arch/arm/include/asm/armv7.h create mode 100644 arch/arm/include/asm/pl310.h create mode 100644 arch/arm/include/asm/utils.h create mode 100644 arch/arm/lib/cache-pl310.c Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/9] armv7: cache maintenance operations
Le 17/06/2011 11:30, Aneesh V a écrit : > With D-cache and MMU enabled for ARM in u-boot it becomes imperative to > support a minimal set of cache maintenance operations and necessary > initializations before enabling MMU. > > This series of patches attempt to do the following for armv7: > * Necessary initialization sequence before enabling MMU that includes >invalidation of TLB, data caches, branch predictor array etc. > * Framework for supporting SOC specific outer caches in a generic manner >(using a structure of function pointers - inspired by the Linux >implementation) > * Generic armv7 cache maintenance operations for caches known to the CPU > * Support for ARM PL310 L2 cache controller used in OMAP4 > * Cleanup of the cleanup_before_linux() function > * Adapting all armv7 SOCs to use the new framework and removing >duplicated code > > Testing: > * Extensive testing on OMAP4430SDP and OMAP3430SDP by creating coherency >issues and solving them using the maintenance routines > - Eg: memfill a region of memory with a known pattern > - Invalidate the region > - Read back and compare the region with the original pattern > - If match fails it means that invalidate is successful > - Now add a flush call just before the invalidate > - If match succeeds it means that flush was successful > - Outer caches were tested with experiments involving making the > function pointers NULL > * Kernel booting on OMAP4430SDP and OMAP3430SDP > Note: v2 has been tested only on OMAP4430SDP > > V2: > * Pointer based callback mechanism for outer cache operations >changed to a weakly linked functions. > * Change -march=armv7-a back to armv5 > * Moved utility macros out of armv7.h > * Added documentation for new CONFIG options. > * Changed implementation of log2n to not use CLZ instruction as armv4 >doesn't support this instruction and newly added Tegra2 uses >-march=armv4 > * Blank line after local variable declarations - fixed globally > * Explicitly added an empty flush_cache() under >#ifdef CONFIG_SYS_NO_DCACHE > * Removed the print inside the weakly linked stub function - >__arm_init_before_mmu > * Fixed signature of flush_cache in cache.c > * More descriptive commit message for the PL310 support patch > * C struct for PL310 register accesses > * Fixed white space issues > > V3: > * Rebased to latest HEAD of master > * Added comments on changes done in V2 in individual patch headers. This >was missing in V2 > > V4: > * Removed bit field manipulation macros > * Renamed CONFIG_SYS_NO_*CACHE flags to CONFIG_SYS_*CACHE_OFF globally > > Aneesh V (9): >arm: make default implementation of cache_flush() weakly linked >armv7: cache maintenance operations for armv7 >armv7: rename cache related CONFIG flags >armv7: integrate cache maintenance support >arm: minor fixes for cache and mmu handling >armv7: add PL310 support to u-boot >armv7: adapt omap4 to the new cache maintenance framework >armv7: adapt omap3 to the new cache maintenance framework >armv7: adapt s5pc1xx to the new cache maintenance framework > > README | 11 + > arch/arm/cpu/arm1136/start.S |4 +- > arch/arm/cpu/armv7/Makefile|2 +- > arch/arm/cpu/armv7/cache_v7.c | 394 > > arch/arm/cpu/armv7/cpu.c | 50 +-- > arch/arm/cpu/armv7/omap3/Makefile |1 - > arch/arm/cpu/armv7/omap3/board.c | 136 ++- > arch/arm/cpu/armv7/omap3/cache.S | 263 - > arch/arm/cpu/armv7/omap3/lowlevel_init.S | 32 ++ > arch/arm/cpu/armv7/omap4/board.c | 12 + > arch/arm/cpu/armv7/omap4/lowlevel_init.S |9 + > arch/arm/cpu/armv7/s5pc1xx/cache.S | 88 + > arch/arm/cpu/armv7/start.S | 18 +- > arch/arm/include/asm/arch-omap3/omap3.h| 20 + > arch/arm/include/asm/arch-omap3/sys_proto.h| 10 +- > arch/arm/include/asm/arch-omap4/sys_proto.h|2 +- > arch/arm/include/asm/arch-s5pc1xx/sys_proto.h |3 - > arch/arm/include/asm/armv7.h | 67 > arch/arm/include/asm/global_data.h |2 +- > arch/arm/include/asm/pl310.h | 73 > .../omap4/lowlevel_init.S => include/asm/utils.h} | 51 ++- > arch/arm/lib/Makefile |3 +- > arch/arm/lib/board.c |8 +- > arch/arm/lib/cache-cp15.c | 22 +- > arch/arm/lib/cache-pl310.c | 115 ++ > arch/arm/lib/cache.c | 20 +- > board/armltd/integrator/split_by_variant.sh|8 +- > common/cmd_bdinfo.c
Re: [U-Boot] [PATCH] OMAP[34]: fix broken timer
Sandeep, Albert,
Please, apply this patch. It fixes a real issue with timer on omap.
Thanks
On 12/28/10 02:33, John Rigby wrote:
> As implemented now the timer used to implement __udelay counts
> to 0x and then gets stuck there because the the programmed
> reload value is 0x. This value is not only wrong but
> illegal according to the reference manual.
>
> One can reproduce the bug by leaving a board at the u-boot prompt
> for sometime then issuing a sleep command. The sleep will hang
> forever.
>
> The timer is a count up timer that reloads as it rolls over
> from 0x so the correct load value is 0.
>
> Change TIMER_LOAD_VAL from 0x to 0 and introduce
> a new constant called TIMER_OVERFLOW_VAL set to 0x.
>
> Signed-off-by: John Rigby
Tested-by: Igor Grinberg
On DM3730, AM3703, OMAP3530.
> ---
> arch/arm/cpu/armv7/omap-common/timer.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/timer.c
> b/arch/arm/cpu/armv7/omap-common/timer.c
> index 9beebb1..59bbca8 100644
> --- a/arch/arm/cpu/armv7/omap-common/timer.c
> +++ b/arch/arm/cpu/armv7/omap-common/timer.c
> @@ -43,8 +43,9 @@ static struct gptimer *timer_base = (struct gptimer
> *)CONFIG_SYS_TIMERBASE;
> * Nothing really to do with interrupts, just starts up a counter.
> */
>
> -#define TIMER_CLOCK (V_SCLK / (2 << CONFIG_SYS_PTV))
> -#define TIMER_LOAD_VAL 0x
> +#define TIMER_CLOCK (V_SCLK / (2 << CONFIG_SYS_PTV))
> +#define TIMER_OVERFLOW_VAL 0x
> +#define TIMER_LOAD_VAL 0
>
> int timer_init(void)
> {
> @@ -86,7 +87,7 @@ void __udelay(unsigned long usec)
> while (tmo > 0) {
> now = readl(&timer_base->tcrr);
> if (last > now) /* count up timer overflow */
> - tmo -= TIMER_LOAD_VAL - last + now;
> + tmo -= TIMER_OVERFLOW_VAL - last + now + 1;
> else
> tmo -= now - last;
> last = now;
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Tuesday 28 June 2011 02:52 AM, Wolfgang Denk wrote: > Dear Scott Wood, > > In message<20110627161803.16783...@schlenkerla.am.freescale.net> you wrote: >> > But if we do not create a new hierarchy of target directories we will > have the "normal" and the "spl" objects in parallel (and I don't want > to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. >>> >>> The question came up what we need it for. >> >> Just seems cleaner to me than jamming it into the file extension. If we're >> treating it as a separate build, it should go into a separate place. It's >> not really a different type of file. > > I'm fine with that as well. I too think this approach is cleaner. This is essentially Daniel's approach. So, we can use some of his code. There are couple of open points though: 1. If there are SPL customized generic files like the nand_spl/nand_boot.c where do we keep them? I suggest that we keep them in spl/nand, spl/onenand etc. And for the object file hierarchy let's have something like spl/obj. How about that? 3. I hope partially linked libraries is fine. Or do you want to link all object files in a single stage? Is there any advantage in doing that? Shall I re-work my series using this framework? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
