Re: [U-Boot-Users] [PATCH] sh: Add support Renesas Solutions Migo-R board
In message <[EMAIL PROTECTED]> Nobuhiro Iwamatsu wrote: > > > +#define CONFIG_NETMASK 255.255.255.0 > > +#define CONFIG_IPADDR 192.168.10.100 > > +#define CONFIG_SERVERIP192.168.10.77 > > +#define CONFIG_GATEWAYIP 192.168.10.77 > > +#define CONFIG_ETHADDR 00:00:00:07:08:09 > > Please change MAC address. > Does this board have Ether ROM? > If this board doesn't have it, please set the MAC address in > your company. This MAC address is not good. The MAC address shout NOT be set in the board config file at all. Don't do it, it is a very bad idea! 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: [EMAIL PROTECTED] You Don't Have To Be 'Damned' To Work Here, But It Helps!!! - Terry Pratchett, _Eric_ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot-Users Digest, Vol 20, Issue 264
In message <[EMAIL PROTECTED]> you wrote: > > I have some requirement to debug a patch based on u-boot 1.1.3, could u > please let me know how to revert from the current git tree and get to the > 1.1.3 version. man git or here: git-checkout U-Boot-1_1_3 > --=_Part_429_28785085.1201239635250 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline But don't post HTML here! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] The light at the end of the tunnel is usually a "No Exit" sign. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Fix remaining CONFIG_COMMANDS
update comments
Fix coding style
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
diff --git a/api/api_storage.c b/api/api_storage.c
index 7cd4efb..7e63240 100644
--- a/api/api_storage.c
+++ b/api/api_storage.c
@@ -61,21 +61,21 @@ static struct stor_spec specs[ENUM_MAX] = { { 0, 0, 0, 0,
"" }, };
void dev_stor_init(void)
{
-#if (CONFIG_COMMANDS & CFG_CMD_IDE)
+#if defined(CONFIG_CMD_IDE)
specs[ENUM_IDE].max_dev = CFG_IDE_MAXDEVICE;
specs[ENUM_IDE].enum_started = 0;
specs[ENUM_IDE].enum_ended = 0;
specs[ENUM_IDE].type = DEV_TYP_STOR | DT_STOR_IDE;
specs[ENUM_IDE].name = "ide";
#endif
-#if (CONFIG_COMMANDS & CFG_CMD_USB)
+#if defined(CONFIG_CMD_USB)
specs[ENUM_USB].max_dev = USB_MAX_STOR_DEV;
specs[ENUM_USB].enum_started = 0;
specs[ENUM_USB].enum_ended = 0;
specs[ENUM_USB].type = DEV_TYP_STOR | DT_STOR_USB;
specs[ENUM_USB].name = "usb";
#endif
-#if (CONFIG_COMMANDS & CFG_CMD_SCSI)
+#if defined(CONFIG_CMD_SCSI)
specs[ENUM_SCSI].max_dev = CFG_SCSI_MAX_DEVICE;
specs[ENUM_SCSI].enum_started = 0;
specs[ENUM_SCSI].enum_ended = 0;
diff --git a/board/BuS/EB+MCF-EV123/mii.c b/board/BuS/EB+MCF-EV123/mii.c
index ebd3ed9..3ea20a6 100644
--- a/board/BuS/EB+MCF-EV123/mii.c
+++ b/board/BuS/EB+MCF-EV123/mii.c
@@ -132,7 +132,7 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0x);/* data read from phy */
}
-#endif /* CFG_DISCOVER_PHY || (CONFIG_COMMANDS &
CONFIG_CMD_MII) */
+#endif /* CFG_DISCOVER_PHY || CONFIG_CMD_MII */
#if defined(CFG_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
diff --git a/board/cobra5272/mii.c b/board/cobra5272/mii.c
index fadcbb3..d0a4a39 100644
--- a/board/cobra5272/mii.c
+++ b/board/cobra5272/mii.c
@@ -131,7 +131,7 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0x);/* data read from phy */
}
-#endif /* CFG_DISCOVER_PHY || (CONFIG_COMMANDS &
CONFIG_CMD_MII) */
+#endif /* CFG_DISCOVER_PHY || CONFIG_CMD_MII */
#if defined(CFG_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
diff --git a/board/idmr/mii.c b/board/idmr/mii.c
index f6c63c3..f130e6e 100644
--- a/board/idmr/mii.c
+++ b/board/idmr/mii.c
@@ -131,7 +131,7 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0x);/* data read from phy */
}
-#endif /* CFG_DISCOVER_PHY || (CONFIG_COMMANDS &
CONFIG_CMD_MII) */
+#endif /* CFG_DISCOVER_PHY || CONFIG_CMD_MII */
#if defined(CFG_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
diff --git a/board/m5271evb/mii.c b/board/m5271evb/mii.c
index 3830ce7..78a7028 100644
--- a/board/m5271evb/mii.c
+++ b/board/m5271evb/mii.c
@@ -131,7 +131,7 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0x);/* data read from phy */
}
-#endif /* CFG_DISCOVER_PHY || (CONFIG_COMMANDS &
CONFIG_CMD_MII) */
+#endif /* CFG_DISCOVER_PHY || CONFIG_CMD_MII */
#if defined(CFG_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
diff --git a/board/m5272c3/mii.c b/board/m5272c3/mii.c
index 0ecc44a..b30ba80 100644
--- a/board/m5272c3/mii.c
+++ b/board/m5272c3/mii.c
@@ -131,7 +131,7 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0x);/* data read from phy */
}
-#endif /* CFG_DISCOVER_PHY || (CONFIG_COMMANDS &
CONFIG_CMD_MII) */
+#endif /* CFG_DISCOVER_PHY || CONFIG_CMD_MII */
#if defined(CFG_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
diff --git a/board/m5282evb/mii.c b/board/m5282evb/mii.c
index d7c6d1f..8ae2ec6 100644
--- a/board/m5282evb/mii.c
+++ b/board/m5282evb/mii.c
@@ -132,7 +132,7 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0x);/* data read from phy */
}
-#endif /* CFG_DISCOVER_PHY || (CONFIG_COMMANDS &
CONFIG_CMD_MII) */
+#endif /* CFG_DISCOVER_PHY || CONFIG_CMD_MII */
#if defined(CFG_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
diff --git a/drivers/net/cs8900.c b/drivers/net/cs8900.c
index 80c4ba2..55ef346 100644
--- a/drivers/net/cs8900.c
+++ b/drivers/net/cs8900.c
@@ -165,7 +165,7 @@ void cs8900_get_enetaddr (uchar * addr)
addr[0], addr[1],
addr[2], addr[3],
addr[4], addr[5]) ;
- debug ("### Set environment from HW MAC addr =
\"%s\"\n", ethaddr);
+ debug ("### Set environment from HW MAC addr =
\"%s\"\n", ethaddr);
setenv ("ethaddr", ethaddr);
}
@@ -317,6 +317,6 @@ int cs8900_e2prom_write(unsigned char addr, unsigned short
value)
return 0;
}
-#endif /* COMMANDS & CFG_NE
Re: [U-Boot-Users] U-Boot-Users Digest, Vol 20, Issue 264
On Fri, 25 Jan 2008 11:10:35 +0530 "Manish Jaggi" <[EMAIL PROTECTED]> wrote: > Hi All, > > I have some requirement to debug a patch based on u-boot 1.1.3, could > u please let me know how to revert from the current git tree and get > to the 1.1.3 version. First of all, please don't start a new thread by replying to a different message (or a digest.) Your subject isn't very informative, and the threading tends to get messed up. Second of all, this is really a question about git, so it's somewhat off-topic for this list. Anyway, "git checkout -b my-debug-branch v1.1.3" will make "my-debug-branch" point to the 1.1.3 version and populate your working tree with it. Oh, and the next step should be "git rebase origin/master" to bring your patch up to date ;-) Haavard - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] sh: Add support Renesas Solutions Migo-R board
Hi, Goda-san. 2008/1/25, goda.yusuke <[EMAIL PROTECTED]>: > Migo-R is a board based on SH7722 and has may devices. > In this patch, supported SCIF, NOR flash and Ethernet. > > Signed-off-by: Yusuke Goda <[EMAIL PROTECTED]> > diff --git a/board/MigoR/migo_r.c b/board/MigoR/migo_r.c > new file mode 100644 > index 000..23dcd49 > --- /dev/null > +++ b/board/MigoR/migo_r.c > @@ -0,0 +1,54 @@ > +/* > + * Copyright (C) 2007 > + * Nobuhiro Iwamatsu <[EMAIL PROTECTED]> > + * > + * Copyright (C) 2007 > + * Kenati Technologies, Inc. > + * > + * board/MigoR/ms7722se.c board/MigoR/migo_r.c ? > diff --git a/include/configs/MigoR.h b/include/configs/MigoR.h > new file mode 100644 > index 000..b557999 > --- /dev/null > +++ b/include/configs/MigoR.h > +#define CONFIG_NETMASK 255.255.255.0 > +#define CONFIG_IPADDR 192.168.10.100 > +#define CONFIG_SERVERIP192.168.10.77 > +#define CONFIG_GATEWAYIP 192.168.10.77 > +#define CONFIG_ETHADDR 00:00:00:07:08:09 Please change MAC address. Does this board have Ether ROM? If this board doesn't have it, please set the MAC address in your company. This MAC address is not good. regards, Nobuhiro - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] sh: Add support Renesas Solutions Migo-R board
Migo-R is a board based on SH7722 and has may devices. In this patch, supported SCIF, NOR flash and Ethernet. Signed-off-by: Yusuke Goda <[EMAIL PROTECTED]> --- MAINTAINERS |4 + MAKEALL |1 + Makefile|5 + board/MigoR/Makefile| 48 board/MigoR/config.mk | 32 + board/MigoR/lowlevel_init.S | 269 +++ board/MigoR/migo_r.c| 54 + board/MigoR/u-boot.lds | 106 + include/configs/MigoR.h | 152 9 files changed, 671 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 239f5c3..44a4372 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -680,6 +680,10 @@ Yoshihiro Shimoda <[EMAIL PROTECTED] MS7720SESH7720 +Yusuke Goda <[EMAIL PROTECTED]> + + MIGO-R SH7722 + # # End of MAINTAINERS list # # diff --git a/MAKEALL b/MAKEALL index 180bc44..a5dbbe9 100755 --- a/MAKEALL +++ b/MAKEALL @@ -681,6 +681,7 @@ LIST_blackfin=" \ LIST_sh4=" \ ms7750se\ ms7722se\ + Migo-R \ " LIST_sh3=" \ diff --git a/Makefile b/Makefile index c322c5c..1bc597c 100644 --- a/Makefile +++ b/Makefile @@ -2770,6 +2770,11 @@ ms7722se_config : unconfig @echo "#define CONFIG_MS7722SE 1" >> $(obj)include/config.h @./mkconfig -a $(@:_config=) sh sh4 ms7722se +MigoR_config : unconfig + @ >include/config.h + @echo "#define CONFIG_MIGO_R 1" >> include/config.h + @./mkconfig -a $(@:_config=) sh sh4 MigoR + # # # diff --git a/board/MigoR/Makefile b/board/MigoR/Makefile new file mode 100644 index 000..5a9d651 --- /dev/null +++ b/board/MigoR/Makefile @@ -0,0 +1,48 @@ +# +# Copyright (C) 2007 +# Nobuhiro Iwamatsu <[EMAIL PROTECTED]> +# +# Copyright (C) 2007 +# Kenati Technologies, Inc. +# +# board/MigoR/Makefile +# +# 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= lib$(BOARD).a + +OBJS := migo_r.o +SOBJS := lowlevel_init.o + +$(LIB):$(OBJS) $(SOBJS) + $(AR) crv $@ $(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) > $@ + +-include .depend + +# diff --git a/board/MigoR/config.mk b/board/MigoR/config.mk new file mode 100644 index 000..c68cb72 --- /dev/null +++ b/board/MigoR/config.mk @@ -0,0 +1,32 @@ +# +# Copyright (C) 2007 +# Nobuhiro Iwamatsu <[EMAIL PROTECTED]> +# +# Copyright (C) 2007 +# Kenati Technologies, Inc. +# +# board/MigoR/config.mk +# +# 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 + +# +# TEXT_BASE refers to image _after_ relocation. +# +# NOTE: Must match value used in u-boot.lds (in this directory). +# + +TEXT_BASE = 0x8FFC + diff --git a/board/MigoR/lowlevel_init.S b/board/MigoR/lowlevel_init.S new file mode 100644 index 000..7f
Re: [U-Boot-Users] U-Boot-Users Digest, Vol 20, Issue 264
Hi All, I have some requirement to debug a patch based on u-boot 1.1.3, could u please let me know how to revert from the current git tree and get to the 1.1.3 version. Thanks Manish - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/6] [new uImage] patchset2 - cleanup cont.
On Jan 23, 2008, at 8:43 AM, Marian Balakowicz wrote: > Hi, > > This is a second patchset for new uImage, it includes architecture > file > renames, removals of OF_FLAT_TREE and standalone application support > and > further code refactoring. > > This patchset is based on patchset1. MAKEALL was run for ppc/arm/ > mips/coldfire, > architestures, plus regression tests on lite5200b. > > [new uImage] Move FDT error printing to common fdt_error() routine > [new uImage] Factor out common routines for getting os/arch/type/ > comp names > [new uImage] Remove standalone applications handling from boootm > [new uImage] Remove OF_FLAT_TREE support from PPC bootm code > [new uImage] Use image API in SH do_bootm_linux() routine > [new uImage] Rename architecture specific bootm code files > > Cheers, > m. I haven't looked through these, but is it possible to make it so if you are using a flat device tree blob on PPC that we can grow the size dynamically as we handle some of the board fixups as part of the bootm processing? - k - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: Concise Build Output
Grant Likely wrote: > On 1/23/08, Wolfgang Denk <[EMAIL PROTECTED]> wrote: >> Dear Jon, >> >> in message <[EMAIL PROTECTED]> you wrote: >>> In the spirit of the Linux and Git build systems, >>> I have a modified U-Boot build system that supports >>> a much more concise output! One of the primary >>> motivations for this style of output is that it >>> will very readily highlight build issues and problems >>> as your build progresses. The original, complete >>> build output is obtainable by simply supplying "V=1" >>> on the make invocation in exactly the same way as >>> both Linux and Git do today. > >> So my question is: which problem are you trying to solve that is not >> already solved by "make -s" or "MAKEALL"? I don't really see the need >> for a solution between no output and full output. YMMV, of course. >> >> Hope I didn't frustrate you - I still appreciate the effort. > > Hey Jon, Wolfgang; > > I think this is a good change myself. The biggest reason is that it > makes the default output terse instead of verbose. I'd hazard to > wager that most developers don't use 'make -s', MAKEALL, or anything > else to trim the output (I certainly don't). By making the default > output terse, with errors and warning visually distinct from progress > indication, in increases the likelyhood that warnings will actually > get seen and fixed (because more people will notice it). > > I say make this change. > > Cheers, > g. Plus my 2 cents if this is a voting matter. gvb - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 4/6] [new uImage] Remove standalone applications handling from boootm
On Jan 24, 2008 3:14 AM, Marian Balakowicz <[EMAIL PROTECTED]> wrote: > >> Standalone applications are supposed to be run using the "go" command. > >> This patch removes standalone images handling from the do_bootm(). > >> > >> Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]> > > > > For me handling standalone images in bootm is a big win and I do not > > want it removed. > > ...stuff deleted... > > Agree. But bootm is not a place for standalone applications, bootm is > a OS booting command. uImage support for standalone applications will > be re-added when the new uImage format is implemented, perhaps as a > separate command. I guess I don't see why bootm shouldn't be able to boot whatever types of u-boot image files the code knows about. Why make n different boot commands for each format (unless there is a 'one ring to bind them all' kind of master boot command that will call the correct one). In any case, can it please wait for deletion until the other code is ready? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: Concise Build Output
Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: >> Wolfgang Denk wrote: >>> So my question is: which problem are you trying to solve that is not >>> already solved by "make -s" or "MAKEALL"? I don't really see the need >>> for a solution between no output and full output. YMMV, of course. >> It's nice to have a progress meter of what's currently being compiled, >> without so much noise that warnings are missed. > > Hm... you don't need a progress meter, you need a faster machine ;-) Either that or Ritalin. :-) -Scott - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: Concise Build Output
On 1/23/08, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Dear Jon, > > in message <[EMAIL PROTECTED]> you wrote: > > > > In the spirit of the Linux and Git build systems, > > I have a modified U-Boot build system that supports > > a much more concise output! One of the primary > > motivations for this style of output is that it > > will very readily highlight build issues and problems > > as your build progresses. The original, complete > > build output is obtainable by simply supplying "V=1" > > on the make invocation in exactly the same way as > > both Linux and Git do today. > > So my question is: which problem are you trying to solve that is not > already solved by "make -s" or "MAKEALL"? I don't really see the need > for a solution between no output and full output. YMMV, of course. > > Hope I didn't frustrate you - I still appreciate the effort. Hey Jon, Wolfgang; I think this is a good change myself. The biggest reason is that it makes the default output terse instead of verbose. I'd hazard to wager that most developers don't use 'make -s', MAKEALL, or anything else to trim the output (I certainly don't). By making the default output terse, with errors and warning visually distinct from progress indication, in increases the likelyhood that warnings will actually get seen and fixed (because more people will notice it). I say make this change. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: Concise Build Output
In message <[EMAIL PROTECTED]> you wrote: > Wolfgang Denk wrote: > > So my question is: which problem are you trying to solve that is not > > already solved by "make -s" or "MAKEALL"? I don't really see the need > > for a solution between no output and full output. YMMV, of course. > > It's nice to have a progress meter of what's currently being compiled, > without so much noise that warnings are missed. Hm... you don't need a progress meter, you need a faster machine ;-) 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: [EMAIL PROTECTED] "God is a comedian playing to an audience too afraid to laugh." - Voltaire - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] latest (1.3.1) doesn't compile: Makefile issue
In message <[EMAIL PROTECTED]> you wrote: > > [EMAIL PROTECTED]:~/toledo/u-boot$ make all > Generating include/autoconf.mk > ppc_8xx-gcc: compilation of header file requested Please use recent code instead, or a more recent toolchain. 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: [EMAIL PROTECTED] Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] ppc start.S 'rfmci' opcode not recognized by ppc-440 compiler
In message <[EMAIL PROTECTED]> you wrote: > > 1) also i made a change in the Makefile show above which made me wonder if > using ppc_8xx as the default for all ppc board is a correct assumption ? It's a pretty good default, as you can build all existing PPC targets with it, and 90% of them will actually run on the target. Of course it's not recommended to actually do that. Instead, you should always set CXROSS_COMPILE as appropriate for your CPU. > maybe its just a place holder. or maybe the rfmci is only available in > ppc_8xx. > 2) other question is what option do i have to use the latest u-boot 1.3.1 > with my ppc_440 build tools as it doesn't recognizes 'rfmci' opcode. Please read the documentation for your toolchain, i. e. how to use it correctly. If this doesn't help, please contact MontaVista technical support. 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: [EMAIL PROTECTED] Keep your eyes wide open before marriage, half shut afterwards. -- Benjamin Franklin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: Concise Build Output
Wolfgang Denk wrote: > So my question is: which problem are you trying to solve that is not > already solved by "make -s" or "MAKEALL"? I don't really see the need > for a solution between no output and full output. YMMV, of course. It's nice to have a progress meter of what's currently being compiled, without so much noise that warnings are missed. -Scott - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] ColdFire: Added M5275EVB support.
Thanks, TsiChung. With the patches you emailed me it worked fine. It must have been a problem with the way I was creating the patch files, although I still can't see a difference between my files and yours. What I was doing was copy-pasting from gmail to gedit, and I guess that is messing with newlines, because the wrap text seems to be fine. Anyway, I have u-boot compiled and will probably try it out on our board tomorrow. Thanks very much for your help. -David - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] ColdFire: Added M5275EVB support.
David, Make sure your patch is wrap text when you export or save as from email. Aso, make sure your patches do not contain (CR+LF) newlines. unwrap text in your patch: ... 8 files changed, 849 insertions(+), 0 deletions(-) create mode 100644 board/freescale/m5275evb/Makefile create mode 100644 board/freescale/m5275evb/config.mk create mode 100644 board/freescale/m5275evb/m5275evb.c create mode 100644 board/freescale/m5275evb/mii.c create mode 100644 board/freescale/m5275evb/u-boot.lds create mode 100644 include/configs/M5275EVB.h ... wrap text in your patch: ... 8 files changed, 849 insertions(+), 0 deletions(-) create mode 100644 board/freescale/m5275evb/Makefile create mode 100644 board/freescale/m5275evb/config.mk create mode 100644 board/freescale/m5275evb/m5275evb.c create mode 100644 board/freescale/m5275evb/mii.c create mode 100644 board/freescale/m5275evb/u-boot.lds create mode 100644 include/configs/M5275EVB.h ... Regards, TsiChung - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] I Dream of you
I Would Dream http://82.158.158.122/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/5] ATNGW100: Fix default mtest range
Let mtest cover the whole SDRAM except the last megabyte, which is
where u-boot lives.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
include/configs/atngw100.h | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/configs/atngw100.h b/include/configs/atngw100.h
index 414e130..5aad043 100644
--- a/include/configs/atngw100.h
+++ b/include/configs/atngw100.h
@@ -170,13 +170,9 @@
#define CFG_PBSIZE (CFG_CBSIZE + sizeof(CFG_PROMPT) + 16)
#define CFG_LONGHELP 1
-#define CFG_MEMTEST_START \
- ({ DECLARE_GLOBAL_DATA_PTR; gd->bd->bi_dram[0].start; })
-#define CFG_MEMTEST_END
\
- ({ \
- DECLARE_GLOBAL_DATA_PTR;\
- gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size; \
- })
+#define CFG_MEMTEST_START CFG_SDRAM_BASE
+#define CFG_MEMTEST_END(CFG_MEMTEST_START + 0x1f0)
+
#define CFG_BAUDRATE_TABLE { 115200, 38400, 19200, 9600, 2400 }
#endif /* __CONFIG_H */
--
1.5.3.8
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 0/5] AVR32 fixes
The following 5 patches contain relatively minor fixes for the AVR32 architecture and related boards. As per the recent discussion on u-boot-users about Custodian workflow, I've also pushed out this series to the "avr32-fixes" branch on git://www.denx.de/git/u-boot-avr32.git avr32-fixes so please check out this branch if you want to help testing this stuff. Note that I'm _not_ asking anyone to merge anything at this point. Review and test feedback is much appreciated. I'll apply any fixes on top of the branch; later, when it is deemed stable, I'll rebase, combine and move things around a bit so that everything looks nice before I pull it into my "master" branch. After this, I'll post a request asking Wolfgang to pull my "master" branch. Shortlog and diffstat follows. Haavard Skinnemoen (5): ATNGW100: Fix default mtest range ATSTK1002: Use SDRAM + 4MB as default load address ATSTK1004: Fix comment about default load address ATSTK1000: Fix potential flash programming bug AVR32: Make SDRAM refresh rate configurable board/atmel/atngw100/atngw100.c |3 +++ board/atmel/atstk1000/atstk1000.c |3 +++ board/atmel/atstk1000/flash.c | 31 ++- cpu/at32ap/hsdramc.c|6 +- include/asm-avr32/arch-at32ap700x/clk.h |3 +++ include/asm-avr32/sdram.h |3 +++ include/configs/atngw100.h | 10 +++--- include/configs/atstk1002.h |4 ++-- include/configs/atstk1004.h |2 +- 9 files changed, 45 insertions(+), 20 deletions(-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 3/5] ATSTK1004: Fix comment about default load address
The default load address is SDRAM + 2MB, not SDRAM + 4MB. The latter wouldn't have worked anyway since the board can only access 4MB of SDRAM. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- include/configs/atstk1004.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/atstk1004.h b/include/configs/atstk1004.h index 1bad171..b81fc21 100644 --- a/include/configs/atstk1004.h +++ b/include/configs/atstk1004.h @@ -167,7 +167,7 @@ #define CFG_MALLOC_LEN (256*1024) -/* Allow 4MB for the kernel run-time image */ +/* Allow 2MB for the kernel run-time image */ #define CFG_LOAD_ADDR (CFG_SDRAM_BASE + 0x0020) #define CFG_BOOTPARAMS_LEN (16 * 1024) -- 1.5.3.8 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 4/5] ATSTK1000: Fix potential flash programming bug
The (now obsolete) atngw100 flash programming code was having problems
programming the onboard at49bv642 chip. The atstk1000 flash
programming code may have the same bug, so import fix for this problem
from the AVR32 Linux BSP.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atstk1000/flash.c | 31 ++-
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/board/atmel/atstk1000/flash.c b/board/atmel/atstk1000/flash.c
index 93d790f..4047825 100644
--- a/board/atmel/atstk1000/flash.c
+++ b/board/atmel/atstk1000/flash.c
@@ -159,7 +159,7 @@ int __flashprog write_buff(flash_info_t *info, uchar *src,
{
unsigned long flags;
uint16_t *base, *p, *s, *end;
- uint16_t word, status;
+ uint16_t word, status, status1;
int ret = ERR_OK;
if (addr < info->start[0]
@@ -194,20 +194,33 @@ int __flashprog write_buff(flash_info_t *info, uchar *src,
sync_write_buffer();
/* Wait for completion */
+ status1 = readw(p);
do {
/* TODO: Timeout */
- status = readw(p);
- } while ((status != word) && !(status & 0x28));
+ status = status1;
+ status1 = readw(p);
+ } while (((status ^ status1) & 0x40)/* toggled */
+&& !(status1 & 0x28)); /* error bits */
- writew(0xf0, base);
- readw(base);
-
- if (status != word) {
- printf("Flash write error at address 0x%p: 0x%02x\n",
- p, status);
+ /*
+* We'll need to check once again for toggle bit
+* because the toggle bit may stop toggling as I/O5
+* changes to "1" (ref at49bv642.pdf p9)
+*/
+ status1 = readw(p);
+ status = readw(p);
+ if ((status ^ status1) & 0x40) {
+ printf("Flash write error at address 0x%p: "
+ "0x%02x != 0x%02x\n",
+ p, status,word);
ret = ERR_PROG_ERROR;
+ writew(0xf0, base);
+ readw(base);
break;
}
+
+ writew(0xf0, base);
+ readw(base);
}
if (flags)
--
1.5.3.8
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 5/5] AVR32: Make SDRAM refresh rate configurable
The existing code assumes the SDRAM row refresh period should always
be 15.6 us. This is not always true, and indeed on the ATNGW100, the
refresh rate should really be 7.81 us.
Add a refresh_period member to struct sdram_info and initialize it
properly for both ATSTK1000 and ATNGW100. Out-of-tree boards will
panic() until the refresh_period member is updated properly.
Big thanks to Gerhard Berghofer for pointing out this issue.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atngw100/atngw100.c |3 +++
board/atmel/atstk1000/atstk1000.c |3 +++
cpu/at32ap/hsdramc.c|6 +-
include/asm-avr32/arch-at32ap700x/clk.h |3 +++
include/asm-avr32/sdram.h |3 +++
5 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/board/atmel/atngw100/atngw100.c b/board/atmel/atngw100/atngw100.c
index bd4b6b4..1ccbe2c 100644
--- a/board/atmel/atngw100/atngw100.c
+++ b/board/atmel/atngw100/atngw100.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -40,6 +41,8 @@ static const struct sdram_info sdram = {
.trcd = 2,
.tras = 5,
.txsr = 5,
+ /* 7.81 us */
+ .refresh_period = (781 * (SDRAMC_BUS_HZ / 1000)) / 10,
};
int board_early_init_f(void)
diff --git a/board/atmel/atstk1000/atstk1000.c
b/board/atmel/atstk1000/atstk1000.c
index 6618963..28f64c4 100644
--- a/board/atmel/atstk1000/atstk1000.c
+++ b/board/atmel/atstk1000/atstk1000.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -40,6 +41,8 @@ static const struct sdram_info sdram = {
.trcd = 2,
.tras = 5,
.txsr = 5,
+ /* 15.6 us */
+ .refresh_period = (156 * (SDRAMC_BUS_HZ / 1000)) / 1,
};
int board_early_init_f(void)
diff --git a/cpu/at32ap/hsdramc.c b/cpu/at32ap/hsdramc.c
index a936e03..1fcfe75 100644
--- a/cpu/at32ap/hsdramc.c
+++ b/cpu/at32ap/hsdramc.c
@@ -38,6 +38,10 @@ unsigned long sdram_init(const struct sdram_info *info)
unsigned long bus_hz;
unsigned int i;
+ if (!info->refresh_period)
+ panic("ERROR: SDRAM refresh period == 0. "
+ "Please update the board code\n");
+
tmp = (HSDRAMC1_BF(NC, info->col_bits - 8)
| HSDRAMC1_BF(NR, info->row_bits - 11)
| HSDRAMC1_BF(NB, info->bank_bits - 1)
@@ -113,7 +117,7 @@ unsigned long sdram_init(const struct sdram_info *info)
* 15.6 us is a typical value for a burst of length one
*/
bus_hz = get_sdram_clk_rate();
- hsdramc1_writel(TR, (156 * (bus_hz / 1000)) / 1);
+ hsdramc1_writel(TR, info->refresh_period);
printf("SDRAM: %u MB at address 0x%08lx\n",
sdram_size >> 20, info->phys_addr);
diff --git a/include/asm-avr32/arch-at32ap700x/clk.h
b/include/asm-avr32/arch-at32ap700x/clk.h
index ea84c08..385319a 100644
--- a/include/asm-avr32/arch-at32ap700x/clk.h
+++ b/include/asm-avr32/arch-at32ap700x/clk.h
@@ -75,4 +75,7 @@ static inline unsigned long get_mci_clk_rate(void)
}
#endif
+/* Board code may need the SDRAM base clock as a compile-time constant */
+#define SDRAMC_BUS_HZ (MAIN_CLK_RATE >> CFG_CLKDIV_HSB)
+
#endif /* __ASM_AVR32_ARCH_CLK_H__ */
diff --git a/include/asm-avr32/sdram.h b/include/asm-avr32/sdram.h
index 5057eef..833af6e 100644
--- a/include/asm-avr32/sdram.h
+++ b/include/asm-avr32/sdram.h
@@ -26,6 +26,9 @@ struct sdram_info {
unsigned long phys_addr;
unsigned int row_bits, col_bits, bank_bits;
unsigned int cas, twr, trc, trp, trcd, tras, txsr;
+
+ /* SDRAM refresh period in cycles */
+ unsigned long refresh_period;
};
extern unsigned long sdram_init(const struct sdram_info *info);
--
1.5.3.8
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/5] ATSTK1002: Use SDRAM + 4MB as default load address
Many people run into problems when they compile a big kernel and load the uImage at the default SDRAM + 2MB address as the kernel will overwrite the uImage as it is being unpacked. Increase the default load address so that we can load a 4MB kernel image without any problems. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- include/configs/atstk1002.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/atstk1002.h b/include/configs/atstk1002.h index b33e26f..95aeab6 100644 --- a/include/configs/atstk1002.h +++ b/include/configs/atstk1002.h @@ -184,8 +184,8 @@ #define CFG_MALLOC_LEN (256*1024) #define CFG_DMA_ALLOC_LEN (16384) -/* Allow 2MB for the kernel run-time image */ -#define CFG_LOAD_ADDR (CFG_SDRAM_BASE + 0x0020) +/* Allow 4MB for the kernel run-time image */ +#define CFG_LOAD_ADDR (CFG_SDRAM_BASE + 0x0040) #define CFG_BOOTPARAMS_LEN (16 * 1024) /* Other configuration settings that shouldn't have to change all that often */ -- 1.5.3.8 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] latest (1.3.1) doesn't compile: Makefile issue
On Jan 23, 2008 6:16 PM, Jon Loeliger <[EMAIL PROTECTED]> wrote: > > Tales Toledo wrote: > > Hi > > > > I saw a previous discussion but I think main reason why 1.3.1 doesn't > > compile is different from mentioned there. > > I had the same error trying to compile to EP88x with eldk 3.1 toolchains. > > > > It seems that /common/Makefile conditional CONFIG_CMD_FLASH isn't working > > fine. > > It should be set at previous configuration files like config.mk but it > > is just set at header files. > > > > I just change the line as follow I got it work. > > > > #COBJS-$(CONFIG_CMD_FLASH) += cmd_flash.o > > COBJS-y += cmd_flash.o > > > > I'm not familiar with this new Makefile style since I have used old > > u-boot versions. > > Any help to make this work properly is appreciated. > > > > The line you commented-out is the _new_ U-Boot > Makefile style. Expect much, much more of it! > > If your port needs the cmd_flash file, then you > need to ensure that CONFIG_CMD_FLASH is #define'd > in your port config .h file. EP88x.h includes config_cmd_defaults.h and CONFIG_CMD_FLASH is defined there. Then, ensure that it > is also appearing in the autoconf.mk file after it > is generated too. I didn't see any include/autoconf.mk file, only include/autoconf.mk.dep and it was empty. [EMAIL PROTECTED]:~/toledo/u-boot$ make all Generating include/autoconf.mk ppc_8xx-gcc: compilation of header file requested for dir in tools examples ; do make -C $dir _depend ; done make[1]: Entering directory `/home/toledo/u-boot/tools' ln -s ../common/environment.c environment.c ln -s ../lib_generic/crc32.c crc32.c ln -s ../lib_generic/sha1.c sha1.c tt > > jdl > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] ppc start.S 'rfmci' opcode not recognized by ppc-440 compiler
Hi, I'm working on a amcc taishan board. The board works find with for u-boot 1.1.3 and 1.1.6. I'm using montavista ppc_440-gcc build tools. But any version after 1.2.0 compilation fails at start.S apparently it complains about an Unrecognized opcode 'rfmci (message show below) Questions: 1) also i made a change in the Makefile show above which made me wonder if using ppc_8xx as the default for all ppc board is a correct assumption ? maybe its just a place holder. or maybe the rfmci is only available in ppc_8xx. 2) other question is what option do i have to use the latest u-boot 1.3.1 with my ppc_440 build tools as it doesn't recognizes 'rfmci' opcode. any insights would be appreciated. Thanks in advance ! kunal --- change that i made in Makefile --- ifeq ($(ARCH),ppc) CROSS_COMPILE = ppc_8xx- endif to ifeq ($(ARCH),ppc) CROSS_COMPILE = ppc_440- endif - following is the error message for make all - c_440-objcopy -O srec hello_world hello_world.srec 2>/dev/null ppc_440-ld -g -Ttext 0x4 \ -o sched -e sched sched.o libstubs.a \ -L/opt/montavista/pro/devkit/ppc/440/bin/../lib/gcc-lib/powerpc-hardhat-linux/3.3.1 -lgcc ppc_440-objcopy -O srec sched sched.srec 2>/dev/null ppc_440-objcopy -O binary hello_world hello_world.bin 2>/dev/null ppc_440-objcopy -O binary sched sched.bin 2>/dev/null make[1]: Leaving directory `/export/old-root/export/share/uboot/u-boot-1.3.1/examples' make -C cpu/ppc4xx start.o make[1]: Entering directory `/export/old-root/export/share/uboot/u-boot-1.3.1/cpu/ppc4xx' make[1]: Leaving directory `/export/old-root/export/share/uboot/u-boot-1.3.1/cpu/ppc4xx' make[1]: Entering directory `/export/old-root/export/share/uboot/u-boot-1.3.1/cpu/ppc4xx' ppc_440-gcc -D__ASSEMBLY__ -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0xFFFC -I/export/old-root/export/share/uboot/u-boot-1.3.1/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/montavista/pro/devkit/ppc/440/bin/../lib/gcc-lib/powerpc-hardhat-linux/3.3.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -c -o start.o start.S start.S: Assembler messages: start.S:1210: Error: Unrecognized opcode: `rfmci' make[1]: *** [start.o] Error 1 make[1]: Leaving directory `/export/old-root/export/share/uboot/u-boot-1.3.1/cpu/ppc4xx' make: *** [cpu/ppc4xx/start.o] Error 2 _ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/7] 86xx: New law setup and updated reginfo patchset
Becky Bruce wrote: > This patchset adds support for the new law setup method in > fsl_law.c to 86xx. The existing platforms (mpc8641hpcn, > mpc8610hpcd, and sbc8641d) are converted to use the new > method. The old support is them removed. > > A print_laws() function is then added to fsl_law.c, and > then used to implement a rudimentary reginfo for 86xx. > > The first 2 patches in this set supersede these 2 previous > patches sent to the list: > > mpc86xx: Rearrange start.S to allow use of new law code > mpc86xx: Convert to using new law setup code > > The new patches are the same, but with cleaned-up > commit logs. > > This patchset contains: > 86xx: Rearrange the sequence in start.S for 86xx > 86xx: Support new law setup and convert mpc8641 > 86xx: Convert mpc8610hpcd to new law setup method > 86xx: Convert sbc8641d to use new law setup code > 86xx: Remove old style law setup code for 86xx > 86xx: Add print_laws function to fsl_law.c > 86xx: Add reginfo command for mpc86xx > > Cheers, > Becky Becky, I've picked up the entire set and applied it. I'll slate it for the _next_ merge window! Thanks, jdl - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH: fix timer overflow in DaVinci
Peter Pearse wrote: > Dirk, Alex > Did this get tested? I looked again into it. As I now have real hardware, I can test it. > If so did it pass? Yes. At least for me ;) I tested with (x) >> 1 (division by 2, didn't want to wait ~42 minutes) and the wrap around time was doubled. > Shall I treat it as a submitted patch? Yes, please. Thanks for asking! Best regards Dirk >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf >>Of Dirk Behme >>Sent: 20 October 2007 07:24 >>To: Alex Shnitman >>Cc: u-boot-users@lists.sourceforge.net >>Subject: Re: [U-Boot-Users] PATCH: fix timer overflow in DaVinci >> >>Wolfgang Denk wrote: >> >>>In message >> >><[EMAIL PROTECTED] > > angodsp.com> you wrote: > The get_timer() function in DaVinci's timer.c doesn't >> >>handle overflow >> -- it simply subtracts the "base" from the current time, but if the timer overflowed and the current time is smaller than base, >> >>a negative >> number results. The attached patch fixes that. >>> >>>I think this is the wrong approach. get_timer() should not have to >>>deal with wrap arounds, because get_timer_masked() is suppsoed to >>>handle this internally. So please fix it there. >> >>Do you like to test this? It should decrease the counter >>values from the timer running at high frequency by division. >>With this, we should have some more time before timestamp >>wraps around. >> >>Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> >> > > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] [DRIVERS] is only available for ppc boards.
Andy Fleming wrote: > On Jan 24, 2008 10:33 AM, Peter Pearse <[EMAIL PROTECTED]> wrote: > >> +#if defined(CONFIG_MPC834X) || \ >> + defined(CONFIG_MPC8313) || \ >> + defined(CONFIG_MPC8315) || \ >> + defined(CONFIG_MPC837X) >> #include >> +#endif >> >> #ifdef CONFIG_HARD_SPI >> --- >> >> or should asm-ppc/mpc8xxx_spi.h be moved to drivers/spi? >> > > Hm. I'd prefer that, since that SPI driver will possibly propagate > through *many* variants, and it seems silly to change the driver every > time we make a new part. :) > > I'm not familiar enough with the device or driver to know whether the > header is truly ppc-specific, or just coincidentally so. > > Andy > The header is specific to this SPI controller, but not really PPC-specific. I don't know enough about how Freescale works to know if the different divisions such as PPC and Coldfire and whatever else share building blocks like these controllers, but conceivably (in my mind at least) this could be on anything Freescale makes. I'm no expert on Kconfig, but I think that once it's in play the Makefile for this driver determines whether to even compile the driver depending on whether a CONFIG is set or not. I probably forgot to define something like CONFIG_MPC8XXX_SPI. Maybe a change to the Makefile is needed here? Sorry for the seemingly random mumblings. regards, Ben - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] ARM optimized memcpy/memmove routines
Llandre Your patch is available for test from git://linux-arm.org/u-boot-armdev.git#071107_mem However, would it be possible to re-factor it to remove the parts which apply only to linux e.g include/linux/linkage.h etc. And it would be interesting to have some measurements of how much this might speed up say copying a compressed kernel from flash to RAM Sorry for the long delay Regards Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Update board NetStar
Ladislav Your patch is available for test from git://linux-arm.org/u-boot-armdev.git#070524_netstar Please confirm that the code runs on netstar Sorry for the delay, I hope to get this patch into the next merge window. Regards Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] pci: Add CONIFG_PCI_SKIP_HOST_BRIDGE config
On Thu, 24 Jan 2008 10:23:52 +0900
Nobuhiro Iwamatsu <[EMAIL PROTECTED]> wrote:
> In current source code, when the device number of PCI is 0, process PCI
> bridge without fail. However, when the device number is 0, it is not PCI
> always bridge. There are times when device of PCI allocates.
>
> When CONIFG_PCI_SKIP_HOST_BRIDGE is enable, this problem is solved when
> use this patch.
>
> Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
> ---
> drivers/pci/pci.c | 13 ++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 50ca6b0..3027fc7 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -425,6 +425,9 @@ int pci_hose_scan_bus(struct pci_controller *hose, int
> bus)
>dev < PCI_BDF(bus,PCI_MAX_PCI_DEVICES-1,PCI_MAX_PCI_FUNCTIONS-1);
>dev += PCI_BDF(0,0,1))
> {
> +
> + /* Bus 0 is not necessarily PCI bridge. */
> +#if defined(CONIFG_PCI_SKIP_HOST_BRIDGE)
> /* Skip our host bridge */
> if ( dev == PCI_BDF(hose->first_busno,0,0) ) {
> #if defined(CONFIG_PCI_CONFIG_HOST_BRIDGE) /* don't skip host
> bridge */
> @@ -434,9 +437,10 @@ int pci_hose_scan_bus(struct pci_controller *hose, int
> bus)
> if (getenv("pciconfighost") == NULL) {
> continue; /* Skip our host bridge */
> }
> -#else
> +#else /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
> continue; /* Skip our host bridge */
> -#endif
> +#endif /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
> +#endif /* CONIFG_PCI_SKIP_HOST_BRIDGE */
> }
>
> if (PCI_FUNC(dev) && !found_multi)
> @@ -473,8 +477,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, int
> bus)
> hose->fixup_irq(hose, dev);
>
> #ifdef CONFIG_PCI_SCAN_SHOW
> +#if defined(CONIFG_PCI_SKIP_HOST_BRIDGE)
> /* Skip our host bridge */
> - if ( dev != PCI_BDF(hose->first_busno,0,0) ) {
> + if ( dev != PCI_BDF(hose->first_busno,0,0) )
> +#endif
> + {
without verifying the logic of this patch, I can immediately see an
s/CONIFG/CONFIG/g'd version coming...:)
Kim
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Fix interrupt sub mask on S3C2410, Fix clock calculation for S3C2410 cpu.
Martin Your patches (slightly amended as per Wolfgangs comments) are available for test from git://linux-arm.org/u-boot-armdev.git#S3C2410 Please confirm that the code runs on whatever S3C boards you have available. Sorry for the delay, I hope to get this merged in the next window Regards Peter -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] [DRIVERS] is only available for ppc boards.
On Thu, 24 Jan 2008 10:50:09 -0600 "Andy Fleming" <[EMAIL PROTECTED]> wrote: > On Jan 24, 2008 10:33 AM, Peter Pearse <[EMAIL PROTECTED]> wrote: > > > > +#if defined(CONFIG_MPC834X) || \ > > + defined(CONFIG_MPC8313) || \ > > + defined(CONFIG_MPC8315) || \ > > + defined(CONFIG_MPC837X) > > #include > > +#endif > > > > #ifdef CONFIG_HARD_SPI > > --- does Vlad's post not work for you?: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/35888 > > > > or should asm-ppc/mpc8xxx_spi.h be moved to drivers/spi? > > Hm. I'd prefer that, since that SPI driver will possibly propagate > through *many* variants, and it seems silly to change the driver every > time we make a new part. :) > > I'm not familiar enough with the device or driver to know whether the > header is truly ppc-specific, or just coincidentally so. mpc8xxx_spi.h is included by other files in asm-ppc. btw, apologies for not testing non-ppc. Kim - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] [DRIVERS] is only available for ppc boards.
On Jan 24, 2008 10:33 AM, Peter Pearse <[EMAIL PROTECTED]> wrote: > > +#if defined(CONFIG_MPC834X) || \ > + defined(CONFIG_MPC8313) || \ > + defined(CONFIG_MPC8315) || \ > + defined(CONFIG_MPC837X) > #include > +#endif > > #ifdef CONFIG_HARD_SPI > --- > > or should asm-ppc/mpc8xxx_spi.h be moved to drivers/spi? Hm. I'd prefer that, since that SPI driver will possibly propagate through *many* variants, and it seems silly to change the driver every time we make a new part. :) I'm not familiar enough with the device or driver to know whether the header is truly ppc-specific, or just coincidentally so. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] [DRIVERS] is only available for ppc boards.
is only available for ppc boards. Patch against git://www.denx.de/git/u-boot.git commit 33dac03b1b5d61e4fed7bad445ba40b4c97feba0 Signed-off-by: Peter Pearse <[EMAIL PROTECTED]> --- diff -purN u-boot_unpatched/drivers/spi/mpc8xxx_spi.c u-boot/drivers/spi/mpc8xxx_spi.c --- u-boot_unpatched/drivers/spi/mpc8xxx_spi.c 2008-01-24 16:18:07.37509 + +++ u-boot/drivers/spi/mpc8xxx_spi.c2008-01-24 16:14:50.560475000 + @@ -23,7 +23,13 @@ #include #include + +#if defined(CONFIG_MPC834X) || \ + defined(CONFIG_MPC8313) || \ + defined(CONFIG_MPC8315) || \ + defined(CONFIG_MPC837X) #include +#endif #ifdef CONFIG_HARD_SPI --- or should asm-ppc/mpc8xxx_spi.h be moved to drivers/spi? Regards Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch 0/3] KB9202 CodeSourcery ARM EABI toolchainbuild fixes
On Wed, Jan 23, 2008, Peter Pearse wrote: > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Johannes Stezenbach > > Sent: 25 October 2007 17:11 > > > > I wanted to build u-boot-1.3.0-rc3 for the KwikByte KB9202 > > board with the current ARM toolchain from CodeSourcery. > > I needed the following three patches to get it to build. > > > > The first one is probably a bugfix needed for other toolchains, too. > > Thanks for this - it has alerted me to the use of > sub rx, rx, #CONSTANT in several of the ARM .S assembler files. > Whilst sub rx, rx, #CONSTANT saves code size it does demand > that users understand their constants, what they are for and where > they are used. > For ARM #CONSTANT in this context must be capable of being formed by > rotating > an 8 bit constant in a 32 bit register > e.g. 0x22000 is allowed whereas 0x20200 is not. > > I am going to reject your patch though. It is the code that should be > changed. > I have added an action to my list of required patches > http://www.denx.de/wiki/UBoot/PatchStatus to examine the use of constants in > the ARM assembler > code. The simple patch below at least circumvents the problem and allows u-boot to build for the kb9202. Please consider applying this one. It is not toolchain specific. > > The other two patches are specific to the CodeSourcery > > toolchain (or probably to any EABI toolchain with gcc-4.2.x). > > I haven't checked if they break the build for other ARM > > toolchains, so it's probably better to not apply them unless > > someone else confirms they're OK. > > > > Thanks for submitting these - they will be of use/interest to users building > EABI code. > > However I do not propose to submit them to the main tree since they are > toolchain > specific. The standard toolchain for building U-Boot is that supplied in the > ELDK > http://www.denx.de/wiki/DULG/ELDK. > Of course many users have reasons for using others, however to support all > possible > toolchains would result in a support nightmare. The patch propsed in [U-Boot-Users] [patch u-boot git 2/3] better ARM9 compiler options From: David Brownell <[EMAIL PROTECTED]> - 2008-01-18 20:55 http://sourceforge.net/mailarchive/forum.php?thread_name=200801181250.50303.david-b%40pacbell.net&forum_name=u-boot-users would take care of the CodeSourcery build issues, too. It should work with any toolchain. --- KB9202 compile fix make -C cpu/arm920t start.o ... start.S: Assembler messages: start.S:205: Error: invalid constant (20200) after fixup etc. The environment size is the same as in the kb9202 patch available from www.kwikbyte.com. Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> diff --git a/include/configs/kb9202.h b/include/configs/kb9202.h index 75d9c3b..88e8737 100644 --- a/include/configs/kb9202.h +++ b/include/configs/kb9202.h @@ -128,8 +128,8 @@ #defineCFG_ENV_IS_IN_EEPROM #ifdef CONFIG_KB9202 -#define CFG_ENV_OFFSET 0x3E00 -#define CFG_ENV_SIZE 0x0200 +#define CFG_ENV_OFFSET 0x2000 +#define CFG_ENV_SIZE 0x2000 #else #define CFG_ENV_OFFSET 0x1000 #define CFG_ENV_SIZE 0x1000 Thanks, Johannes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] When Love Comes Knocking
Hugging My Pillow http://117.195.0.228/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] esluiter
http://www.eyagioah.com/ Do you really know what a girl wants? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Ethernet: read/write register inside lxt972 with at91rm9200 processor
Hi, I want to change one register inside the LXT971A: set 0 the parameter PHY_LXT971_DIG_CFG_MII_DRIVE for the register PHY_LXT971_TX_CTRL, this register is define in the file include/lxt971a.h , so I think that I have need to change the file cpu/at91rm9200/lxt972.c . I call the function at91rm9200_EmacWritePhy(p_mac, PHY_LXT971_TX_CTRL, 0) inside the function lxt972_InitPhy but without success, just no ethernet efter my modification. If you have any idea to modify just the parameter PHY_LXT971_DIG_CFG_MII_DRIVE ? Thanks for your help. - Looking for last minute shopping deals? Find them fast with Yahoo! Search.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U- Boot support for Remote Debugging
In message <[EMAIL PROTECTED]> you wrote: > > Could you please tell me whether U-Boot support remote debugging through > Ethernet ? What do you want to debug? U-Boot itself? Then use a BDI3000 over ethernet. Linux? Use a BDI3000. > Is there any supporting files for Ethernet and Serial I/O with > U-Boot? Of course U-Boot has serial and network drivers. Also, you can enable the "bedbug" embedded debugger on many platforms. However, I have no idea what your question actually is about... > --=_Part_22939_14788860.1201167339590 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline And please don;t post HTML here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Es sind überhaupt nur die Dummköpfe, die sich den Befehlen der Mäch- tigen widersetzen. Um sie zu ruinieren ist es genug, ihre Befehle treu zu erfüllen. - Peter Hacks: "Die schöne Helena" - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch] add support for "eeprom info"
In message <[EMAIL PROTECTED]> you wrote: > > > I think you are doing something wrong when you try to use "eeprom" to > > access "SPI flash" - these are differnt entities... > > let's make sure we're talking about the same thing. SPI flashes are eeproms > that have a SPI interface. so Spansion's S25FL, ST's m25pxtmels > AT45DB, Winbond's W25Xxx/W25Pxx, and such. they need to be erased before > writing, are split up into some unit size, etc... all SPI flashes nowadays > conform to the JEDEC standard (JEP106) which allows for querying of > manufacturer/device ids so that they can be dynamically detected. sounds to > me like "eeprom" is the correct interface for utilizing these devices. Sounds to me as if you were talking about flash devices with a SPI bus interface. The original SPI eeprom support was implemented som 7+ years ago for the Siemens CCM board; this is where the "CONFIG_SPI" stuff in common/cmd_eeprom.c comes from, and this was supported by the cpu/mpc8xx/spi.c SPI driver. Note that this was a real EEPROM device, i. e. we just needed spi_read() and spi_write() functions to access it. No erase, no sectors or any such stuff. That was an EEPROM - what you have looks like a flash device to me. 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: [EMAIL PROTECTED] In the pitiful, multipage, connection-boxed form to which the flow- chart has today been elaborated, it has proved to be useless as a design tool -- programmers draw flowcharts after, not before, writing the programs they describe.- Fred Brooks, Jr. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch] add support for "eeprom info"
In message <[EMAIL PROTECTED]> you wrote: > > > drivers added for generic SPI support. My preference would be for you > > to expand the 'spi' command with something like: > > > > 'spi eeprom info' > > i dont see how in the long run, this is any different from today. Wolfgang > can still argue that the SPI flash is not an eeprom device, so "spi > eeprom ..." is not appropriate. which means there is still no subsystem > whatsoever for accessing SPI flashes. You are right - I think "spi eeprom" is not a good choice - if it is an EEPROM, then the "eeprom" command should work, no matter what the actual bus interface is. If the device is SPI flash, then why not call it like that, i. e. spi flash info Or spiflash info to make it similar to the "nand" commands? On the other hand, it might be still too shortsighted to tie this to the bus interface. For example, what about dataflash? As discussed many times before, we have similar issues with dataflash devices. I don't have a good idea how to do it, but maybe this is a chance to get a good solution for NAND, dataflash, SPI flash and who knows what else? 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: [EMAIL PROTECTED] "To IBM, 'open' means there is a modicum of interoperability among some of their equipment."- Harv Masterson - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] U- Boot support for Remote Debugging
Hi all, Could you please tell me whether U-Boot support remote debugging through Ethernet ? Is there any supporting files for Ethernet and Serial I/O with U-Boot? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] u-boot for SC32442B
tangwei hotmail.com> writes: > dear ,all Hi Tangwei > I have a board use S3C2442B43 (400MHz, 64MB mSDRAM, 128MB Nand), and there is > no flash or other memory,so have to use the nand boot, is there someone have > done something for this, please give me some advices, thanks. Booting from NAND flash usually requires some special provisions as code can not directly be executed from it. Have a look at nand_spl and its documentation in doc/README.nand-boot-ppc440 describing the process applicable to PowerPC SOCs. As I don't know much about the S3C2442B I can't give you any concrete advice there, but you will have to find out from its documentation whether and what its NAND booting provisions are. Cheers Marcel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch] add support for "eeprom info"
On Wednesday 23 January 2008, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support > > the jedec id command which allows for dynamic detection (which is how the > > Blackfin SPI driver that i wrote works). hook up any SPI flash and it > > "just works". > > I think you are doing something wrong when you try to use "eeprom" to > access "SPI flash" - these are differnt entities... let's make sure we're talking about the same thing. SPI flashes are eeproms that have a SPI interface. so Spansion's S25FL, ST's m25pxtmels AT45DB, Winbond's W25Xxx/W25Pxx, and such. they need to be erased before writing, are split up into some unit size, etc... all SPI flashes nowadays conform to the JEDEC standard (JEP106) which allows for querying of manufacturer/device ids so that they can be dynamically detected. sounds to me like "eeprom" is the correct interface for utilizing these devices. -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] u-boot for Microblaze build problem
Hi Bruce > I am having trouble compiling a build for u-boot 1.1.6. I have a > microblaze processor. I know that I am just missing a step but I am new > to using u-boot and need some help. > I have done a "make suzaku_config" > When I compile the code I get the error "#error Unknown CPU type". > What parameter do I use to configure for a microblaze? > > Here are some other questions that I have. > > Where do I get the latest version of U-Boot for microblaze? Latest version of U-BOOT is in git repository on denx.de. gitweb is www.denx.de/cgi-bin/gitweb.cgi > Where do I get the latest version of mb-gcc (Microblaze gcc compiler)? I personally use Petalogix uclibc toolchain. > Where is the best documentation to help me get U-Boot up and running on > my board? http://www.monstr.eu/wiki/ What IP cores do you want to use? > Any help would be appreciated. > Thanks > Bruce Christensen Regards, Michal Simek - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
