[U-Boot] [PATCH v5 1/1] imx: Get fec mac address from fuse

[Jason Liu]

The patch is to support getting FEC MAC address from fuse bank.

Signed-off-by: Jason Liu r64...@freescale.com

---
Changes for v2:
 - correct the mac address byte order according to review comments
 - add memset(edev, 0. sizeof(*edev)) when do fec_probe,
 - fix some code comments
Changes for v3:
 - rebase
 - address the comments of Stefano, make the imx_get_mac_from_fuse(),
   declared independently inside each imx-regs.h to make it specific
   for each processor, because it accesses to different structures.
 - address the comments of Wolfgang and Stefano, use struct to access
   mac_addr fuse.
Changes for v4:
 - Address the comments of Wolfgang, use fuse_regs instead of bank addres
   and change from fuse1_6 to fuse0_5 naming convention and use fuse_bank0_regs
   instead of fuse_bank0 to kill misleading.
Changes for v5:
 - Fix the typo error of fuse5_31[0x11] as Wolfgang point out
 - Change the print message got MAC address from EEPROM to
   got MAC address from fuse which comply with this commit title.
---
 arch/arm/cpu/arm926ejs/mx25/generic.c |   12 ++
 arch/arm/cpu/arm926ejs/mx27/generic.c |   12 ++
 arch/arm/cpu/armv7/mx5/soc.c  |   14 
 arch/arm/include/asm/arch-mx25/imx-regs.h |   19 +--
 arch/arm/include/asm/arch-mx27/imx-regs.h |   18 ++-
 arch/arm/include/asm/arch-mx5/imx-regs.h  |   34 +
 drivers/net/fec_mxc.c |   17 +
 7 files changed, 97 insertions(+), 29 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index b80a389..4ac7bbb 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -260,4 +260,16 @@ void mx25_fec_init_pins (void)
writel (outpadctl, padctl-pad_fec_tdata1);
 
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = iim-bank[0];
+   struct fuse_bank0_regs *fuse =
+   (struct fuse_bank0_regs *)bank-fuse_regs;
+
+   for (i = 0; i  6; i++)
+   mac[i] = readl(fuse-mac_addr[i]);
+}
 #endif /* CONFIG_FEC_MXC */
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c 
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index ae2ce58..ceaac48 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -313,6 +313,18 @@ void mx27_fec_init_pins(void)
for (i = 0; i  ARRAY_SIZE(mode); i++)
imx_gpio_mode(mode[i]);
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = iim-bank[0];
+   struct fuse_bank0_regs *fuse =
+   (struct fuse_bank0_regs *)bank-fuse_regs;
+
+   for (i = 0; i  6; i++)
+   mac[6-1-i] = readl(fuse-mac_addr[i]);
+}
 #endif /* CONFIG_FEC_MXC */
 
 #ifdef CONFIG_MXC_MMC
diff --git a/arch/arm/cpu/armv7/mx5/soc.c b/arch/arm/cpu/armv7/mx5/soc.c
index 7c7a565..c22d6dc 100644
--- a/arch/arm/cpu/armv7/mx5/soc.c
+++ b/arch/arm/cpu/armv7/mx5/soc.c
@@ -100,6 +100,20 @@ int cpu_eth_init(bd_t *bis)
return rc;
 }
 
+#if defined(CONFIG_FEC_MXC)
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = iim-bank[1];
+   struct fuse_bank1_regs *fuse =
+   (struct fuse_bank1_regs *)bank-fuse_regs;
+
+   for (i = 0; i  6; i++)
+   mac[i] = readl(fuse-mac_addr[i]);
+}
+#endif
+
 /*
  * Initializes on-chip MMC controllers.
  * to override, implement board_mmc_init()
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index f5a2929..55ad115 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -36,6 +36,7 @@
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_FEC_MXC
 extern void mx25_fec_init_pins(void);
+extern void imx_get_mac_from_fuse(unsigned char *mac);
 #endif
 
 /* Clock Control Module (CCM) registers */
@@ -129,12 +130,17 @@ struct iim_regs {
u32 iim_srev;
u32 iim_prog_p;
u32 res1[0x1f5];
-   u32 iim_bank_area0[0x20];
-   u32 res2[0xe0];
-   u32 iim_bank_area1[0x20];
-   u32 res3[0xe0];
-   u32 iim_bank_area2[0x20];
+   struct fuse_bank {
+   u32 fuse_regs[0x20];
+   u32 fuse_rsvd[0xe0];
+   } bank[3];
 };
+
+struct fuse_bank0_regs {
+   u32 fuse0_25[0x1a];
+   u32 mac_addr[6];
+};
+
 #endif
 
 /* AIPS 1 */
@@ -312,7 +318,4 @@ struct iim_regs {
 #define WSR_UNLOCK10x
 #define WSR_UNLOCK20x
 
-/* FUSE bank offsets */
-#define IIM0_MAC   0x1a
-
 #endif /* _IMX_REGS_H */
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h 

[U-Boot] [PATCH] Makefile: Fix build with USE_PRIVATE_LIBGCC

[Matthias Weisser]

If USE_PRIVATE_LIBGCC is set the yes building fails with a missing
libgcc.a As we use partial linking now it is libgcc.o now.

Signed-off-by: Matthias Weisser weiss...@arcor.de
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index af33f08..b4aae89 100644
--- a/Makefile
+++ b/Makefile
@@ -269,7 +269,7 @@ LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 # Add GCC lib
 ifdef USE_PRIVATE_LIBGCC
 ifeq ($(USE_PRIVATE_LIBGCC), yes)
-PLATFORM_LIBGCC = -L $(OBJTREE)/arch/$(ARCH)/lib -lgcc
+PLATFORM_LIBGCC = $(OBJTREE)/arch/$(ARCH)/lib/libgcc.o
 else
 PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
 endif
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Makefile: Fix build with USE_PRIVATE_LIBGCC

[Wolfgang Denk]

Dear Matthias Weisser,

In message 1290069309-12910-1-git-send-email-weiss...@arcor.de you wrote:
 If USE_PRIVATE_LIBGCC is set the yes building fails with a missing
 libgcc.a As we use partial linking now it is libgcc.o now.
 
 Signed-off-by: Matthias Weisser weiss...@arcor.de
 ---
  Makefile |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Unix: Some say the learning curve is steep,  but  you  only  have  to
climb it once.  - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] imx: Get fec mac address from fuse

[Stefano Babic]

On 11/18/2010 09:09 AM, Jason Liu wrote:
 The patch is to support getting FEC MAC address from fuse bank.
 
 Signed-off-by: Jason Liu r64...@freescale.com

Hi Jason,

 + for (i = 0; i  6; i++)
 + mac[i] = readl(fuse-mac_addr[i]);

This works, but implicitely converts the integer to a char. Should we
add a mask to make clear that only the LSB of the read value is taken ?

 + for (i = 0; i  6; i++)
 + mac[6-1-i] = readl(fuse-mac_addr[i]);
 ^
 |--- missing spaces

 +
 +struct iim_regs {
 + u32 stat;
 + u32 statm;
 + u32 err;
 + u32 emask;
 + u32 fctl;
 + u32 ua;
 + u32 la;
 + u32 sdat;
 + u32 prev;
 + u32 srev;
 + u32 preg_p;
 + u32 scs0;
 + u32 scs1;
 + u32 scs2;
 + u32 scs3;
 + u32 res0[0x1f1];
 + struct fuse_bank {
 + u32 fuse_regs[0x20];
 + u32 fuse_rsvd[0xe0];
 + } bank[4];

I see a discrepancy between i.mx27 and i.mx51 and it is not clear to me
if it is correct. Both processor has the same register map (at least as
meaning) until scs3. The offset for this register is for both processors
0x3c. The fuse bank0 starts for both processor at the offset 0x804, as I
see in manuals. However, you reserved in one case 0x1f0 integers and in
the other case 0x1f1. Is it correct ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-sparc.git net branch

[Mike Frysinger]

On Thursday, November 18, 2010 02:47:16 Daniel Hellstrom wrote:
   GRETH: Added extra RESET, this is needed if GRETH was stopped
 during an ethernet frame reception.

for future reference, this subject line is too long.  and summaries shouldnt 
end with periods.
-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] Pull request u-boot-blackfin.git

[Mike Frysinger]

The following changes since commit 635d1b3e1b885267de90d100402ba7748fdd9bc5:

  Makefile: Fix build with USE_PRIVATE_LIBGCC (2010-11-18 09:47:11 +0100)

are available in the git repository at:
  git://www.denx.de/git/u-boot-blackfin.git master

Mike Frysinger (2):
  Blackfin: stick ins/outs funcs into their own .text section
  Blackfin: make sure bss len is multiple of 4 bytes

 arch/blackfin/lib/ins.S|1 +
 arch/blackfin/lib/outs.S   |4 
 arch/blackfin/lib/u-boot.lds.S |1 +
 3 files changed, 6 insertions(+), 0 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Mike Frysinger]

On Wednesday, November 17, 2010 07:58:33 Wolfgang Denk wrote:
 Stephan Linz wrote:
  Am Freitag, 12. November 2010, um 12:11:42 schrieb Michal Simek:
- Network:
--

  Ben Warren has informed me that he has to give up Network
  custodianship.
  
  Hm, I'm sadly to hear about this fact. But so I think the answer to my
  question is more difficult:
  http://www.mail-archive.com/u-boot@lists.denx.de/msg42469.html
  
  Who maintains the Network in the near future (I mean short time)?
 
 As always when there is nobody else I will try and do what needs to be
 done.

patchwork should hopefully help ?  ive never used it before so i dont know of 
its capabilities.  is there a way to mark things as net ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] imx: Get fec mac address from fuse

[Jason Liu]

Hi, Stefano,

2010/11/18 Stefano Babic sba...@denx.de:
 On 11/18/2010 09:09 AM, Jason Liu wrote:
 The patch is to support getting FEC MAC address from fuse bank.

 Signed-off-by: Jason Liu r64...@freescale.com

 Hi Jason,

 +     for (i = 0; i  6; i++)
 +             mac[i] = readl(fuse-mac_addr[i]);

 This works, but implicitely converts the integer to a char. Should we
 add a mask to make clear that only the LSB of the read value is taken ?

In fact, I think it's not need to add a mask to do it. But for
clearance, I can add it per your request.

 mac[i] = readl(fuse-mac_addr[i])  0xff;


 +     for (i = 0; i  6; i++)
 +             mac[6-1-i] = readl(fuse-mac_addr[i]);
                     ^
                     |--- missing spaces

do you mean it need change to mac[6 - 1 - i] ?


 +
 +struct iim_regs {
 +     u32     stat;
 +     u32     statm;
 +     u32     err;
 +     u32     emask;
 +     u32     fctl;
 +     u32     ua;
 +     u32     la;
 +     u32     sdat;
 +     u32     prev;
 +     u32     srev;
 +     u32     preg_p;
 +     u32     scs0;
 +     u32     scs1;
 +     u32     scs2;
 +     u32     scs3;
 +     u32     res0[0x1f1];
 +     struct fuse_bank {
 +             u32     fuse_regs[0x20];
 +             u32     fuse_rsvd[0xe0];
 +     } bank[4];

 I see a discrepancy between i.mx27 and i.mx51 and it is not clear to me
 if it is correct. Both processor has the same register map (at least as
 meaning) until scs3. The offset for this register is for both processors
 0x3c. The fuse bank0 starts for both processor at the offset 0x804, as I
 see in manuals. However, you reserved in one case 0x1f0 integers and in
 the other case 0x1f1. Is it correct ?

I think that the original mx27 code should be wrong. I will fix it.
Thank you for your review.


 Best regards,
 Stefano Babic

 --
 =
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
 =
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Add 'led' command

[Mike Frysinger]

On Saturday, November 13, 2010 18:31:39 Mike Frysinger wrote:
 On Friday, November 12, 2010 09:42:52 Jason Kridner wrote:
  On Tue, Nov 9, 2010 at 8:52 AM, Mike Frysinger wrote:
   On Friday, November 05, 2010 01:50:36 Jason Kridner wrote:
   + if (strcmp(argv[2], off) == 0) {
   + state = 0;
   + } else if (strcmp(argv[2], on) == 0) {
   + state = 1;
   
   i could have sworn we had a helper somewhere to handle boolean
   strings ...
  
  common/cmd_cache.c has an internal on_off function.  All other places
  seem to do individual strcmp.  Let me know if you find such a helper.
  Is there value to putting this in a function like the one in
  cmd_cache.c?
 
 i think there's value in moving this to generalizing and moving to common
 code.  there are other places where we handle env vars which could have the
 value on or off.

ah, i found what i was thinking of.  there is a getenv_yesno helper.  
obviously not the same as on/off, but should be a good model for a new 
str_onoff helper.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] imx: Get fec mac address from fuse

[Stefano Babic]

On 11/18/2010 11:33 AM, Jason Liu wrote:

 + for (i = 0; i  6; i++)
 + mac[6-1-i] = readl(fuse-mac_addr[i]);
 ^
 |--- missing spaces
 
 do you mean it need change to mac[6 - 1 - i] ?

Yes, this is a coding style issue.

 I think that the original mx27 code should be wrong.

I come with the same conclusion.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Exclude drivers/qe/fdt.c without CONFIG_QE

[Sebastien Carlier]

Previously with archive libraries fdt.o was compiled and included in
qe.a and then discarded by the linker.  With partial linking this
results in unresolved symbols, which this commit fixes.

This commit also cleans up a now-useless conditional in fdt.c.

Signed-off-by: Sebastien Carlier sebastien.carl...@gmail.com
---
 drivers/qe/Makefile |2 +-
 drivers/qe/fdt.c|2 --
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/qe/Makefile b/drivers/qe/Makefile
index 8e9a035..ef4bdf8 100644
--- a/drivers/qe/Makefile
+++ b/drivers/qe/Makefile
@@ -24,7 +24,7 @@ include $(TOPDIR)/config.mk
 
 LIB	:= $(obj)libqe.o
 
-COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
+COBJS-$(and $(CONFIG_QE),$(CONFIG_OF_LIBFDT)) += fdt.o
 COBJS-$(CONFIG_QE) += qe.o uccf.o uec.o uec_phy.o
 
 COBJS	:= $(COBJS-y)
diff --git a/drivers/qe/fdt.c b/drivers/qe/fdt.c
index d7c7d13..73e9060 100644
--- a/drivers/qe/fdt.c
+++ b/drivers/qe/fdt.c
@@ -74,7 +74,6 @@ error:
 
 void ft_qe_setup(void *blob)
 {
-#ifdef CONFIG_QE
 	do_fixup_by_prop_u32(blob, device_type, qe, 4,
 		bus-frequency, gd-qe_clk, 1);
 	do_fixup_by_prop_u32(blob, device_type, qe, 4,
@@ -88,5 +87,4 @@ void ft_qe_setup(void *blob)
 	do_fixup_by_compat_u32(blob, fsl,qe-gtm,
 		clock-frequency, gd-qe_clk / 2, 1);
 	fdt_fixup_qe_firmware(blob);
-#endif
 }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Stefano Babic]

On 11/18/2010 10:41 AM, Mike Frysinger wrote:

 patchwork should hopefully help ?  ive never used it before so i dont know of 
 its capabilities.  is there a way to mark things as net ?

I never used, too. I have seen there is the possibility to set a filter
for incoming patches, and at least if net is in the subject, we get a
short list. No idea if there are some other ways.

Anyway, are there some hints for the maintainers how to work with
patchwork ? Should we already mark ourself as delegate for the patches
we think we have to manage ?

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Mike Frysinger]

On Thursday, November 18, 2010 06:22:44 Stefano Babic wrote:
 On 11/18/2010 10:41 AM, Mike Frysinger wrote:
  patchwork should hopefully help ?  ive never used it before so i dont
  know of its capabilities.  is there a way to mark things as net ?
 
 I never used, too. I have seen there is the possibility to set a filter
 for incoming patches, and at least if net is in the subject, we get a
 short list. No idea if there are some other ways.

too bad many people dont prefix their patch summaries accordingly :(

 Anyway, are there some hints for the maintainers how to work with
 patchwork ?

i looked, but couldnt find any actual documents

 Should we already mark ourself as delegate for the patches
 we think we have to manage ?

i think so ... seems like a pretty organic setup rather than a few people 
whose job it is to monitor/update.  set the delegates for patches that lack 
them, and update patch statuses for ones you know have been 
accepted/superseded/whatever.
-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] Blackfin: dnp5370: new board port

[Mike Frysinger]

From: Andreas Schallenberg andreas.schallenb...@3alitydigital.de

Info about the hardware can be found here:
http://www.dilnetpc.com/dnp0086.htm

Signed-off-by: Andreas Schallenberg andreas.schallenb...@3alitydigital.de
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
 board/dnp5370/Makefile|   54 
 board/dnp5370/config.mk   |   29 +++
 board/dnp5370/dnp5370.c   |  104 +++
 boards.cfg|1 +
 doc/README.dnp5370|   67 +
 include/configs/dnp5370.h |  119 +
 6 files changed, 374 insertions(+), 0 deletions(-)
 create mode 100644 board/dnp5370/Makefile
 create mode 100644 board/dnp5370/config.mk
 create mode 100644 board/dnp5370/dnp5370.c
 create mode 100644 doc/README.dnp5370
 create mode 100644 include/configs/dnp5370.h

diff --git a/board/dnp5370/Makefile b/board/dnp5370/Makefile
new file mode 100644
index 000..bfeaf79
--- /dev/null
+++ b/board/dnp5370/Makefile
@@ -0,0 +1,54 @@
+#
+# U-boot - Makefile
+#
+# Copyright (c) 2005-2007 Analog Device Inc.
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y:= $(BOARD).o
+
+SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/dnp5370/config.mk b/board/dnp5370/config.mk
new file mode 100644
index 000..8227506
--- /dev/null
+++ b/board/dnp5370/config.mk
@@ -0,0 +1,29 @@
+#
+# Copyright (c) 2005-2008 Analog Device Inc.
+#
+# (C) Copyright 2001
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+# This is not actually used for Blackfin boards so do not change it
+#TEXT_BASE = do-not-use-me
+
+CONFIG_BFIN_CPU = bf537-0.3
diff --git a/board/dnp5370/dnp5370.c b/board/dnp5370/dnp5370.c
new file mode 100644
index 000..da9eb5f
--- /dev/null
+++ b/board/dnp5370/dnp5370.c
@@ -0,0 +1,104 @@
+/*
+ * U-boot - main board file
+ *
+ * (C) Copyright 2010 3ality Digital Systems
+ *
+ * Copyright (c) 2005-2008 Analog Devices Inc.
+ *
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * 

[U-Boot] [PATCH v6 1/1] imx: Get fec mac address from fuse

[Jason Liu]

The patch is to support getting FEC MAC address from fuse bank.

Signed-off-by: Jason Liu r64...@freescale.com

---
Changes for v2:
 - correct the mac address byte order according to review comments
 - add memset(edev, 0. sizeof(*edev)) when do fec_probe,
 - fix some code comments
Changes for v3:
 - rebase
 - address the comments of Stefano, make the imx_get_mac_from_fuse(),
   declared independently inside each imx-regs.h to make it specific
   for each processor, because it accesses to different structures.
 - address the comments of Wolfgang and Stefano, use struct to access
   mac_addr fuse.
Changes for v4:
 - Address the comments of Wolfgang, use fuse_regs instead of bank addres
   and change from fuse1_6 to fuse0_5 naming convention and use fuse_bank0_regs
   instead of fuse_bank0 to kill misleading.
Changes for v5:
 - Fix the typo error of fuse5_31[0x11] as Wolfgang point out
 - Change the print message got MAC address from EEPROM to
   got MAC address from fuse which comply with this commit title.
Changes for v6:
 - Fix the mx27 res0 array size issue
 - Fix one coding style issue
 - use 0xff mask to clear that only the LSB of the read value is taken
---
 arch/arm/cpu/arm926ejs/mx25/generic.c |   12 ++
 arch/arm/cpu/arm926ejs/mx27/generic.c |   12 ++
 arch/arm/cpu/armv7/mx5/soc.c  |   14 
 arch/arm/include/asm/arch-mx25/imx-regs.h |   19 +--
 arch/arm/include/asm/arch-mx27/imx-regs.h |   20 +++--
 arch/arm/include/asm/arch-mx5/imx-regs.h  |   34 +
 drivers/net/fec_mxc.c |   17 +
 7 files changed, 98 insertions(+), 30 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index b80a389..c6e1146 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -260,4 +260,16 @@ void mx25_fec_init_pins (void)
writel (outpadctl, padctl-pad_fec_tdata1);
 
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = iim-bank[0];
+   struct fuse_bank0_regs *fuse =
+   (struct fuse_bank0_regs *)bank-fuse_regs;
+
+   for (i = 0; i  6; i++)
+   mac[i] = readl(fuse-mac_addr[i])  0xff;
+}
 #endif /* CONFIG_FEC_MXC */
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c 
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index ae2ce58..27642bf 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -313,6 +313,18 @@ void mx27_fec_init_pins(void)
for (i = 0; i  ARRAY_SIZE(mode); i++)
imx_gpio_mode(mode[i]);
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = iim-bank[0];
+   struct fuse_bank0_regs *fuse =
+   (struct fuse_bank0_regs *)bank-fuse_regs;
+
+   for (i = 0; i  6; i++)
+   mac[6 - 1 - i] = readl(fuse-mac_addr[i])  0xff;
+}
 #endif /* CONFIG_FEC_MXC */
 
 #ifdef CONFIG_MXC_MMC
diff --git a/arch/arm/cpu/armv7/mx5/soc.c b/arch/arm/cpu/armv7/mx5/soc.c
index 7c7a565..2900119 100644
--- a/arch/arm/cpu/armv7/mx5/soc.c
+++ b/arch/arm/cpu/armv7/mx5/soc.c
@@ -100,6 +100,20 @@ int cpu_eth_init(bd_t *bis)
return rc;
 }
 
+#if defined(CONFIG_FEC_MXC)
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = iim-bank[1];
+   struct fuse_bank1_regs *fuse =
+   (struct fuse_bank1_regs *)bank-fuse_regs;
+
+   for (i = 0; i  6; i++)
+   mac[i] = readl(fuse-mac_addr[i])  0xff;
+}
+#endif
+
 /*
  * Initializes on-chip MMC controllers.
  * to override, implement board_mmc_init()
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index f5a2929..55ad115 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -36,6 +36,7 @@
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_FEC_MXC
 extern void mx25_fec_init_pins(void);
+extern void imx_get_mac_from_fuse(unsigned char *mac);
 #endif
 
 /* Clock Control Module (CCM) registers */
@@ -129,12 +130,17 @@ struct iim_regs {
u32 iim_srev;
u32 iim_prog_p;
u32 res1[0x1f5];
-   u32 iim_bank_area0[0x20];
-   u32 res2[0xe0];
-   u32 iim_bank_area1[0x20];
-   u32 res3[0xe0];
-   u32 iim_bank_area2[0x20];
+   struct fuse_bank {
+   u32 fuse_regs[0x20];
+   u32 fuse_rsvd[0xe0];
+   } bank[3];
 };
+
+struct fuse_bank0_regs {
+   u32 fuse0_25[0x1a];
+   u32 mac_addr[6];
+};
+
 #endif
 
 /* AIPS 1 */
@@ -312,7 +318,4 @@ struct iim_regs {
 #define WSR_UNLOCK10x
 #define WSR_UNLOCK2

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201011180441.47800.vap...@gentoo.org you wrote:

 patchwork should hopefully help ?  ive never used it before so i dont know of 
 its capabilities.  is there a way to mark things as net ?

Patchwork should indeed help.

You (as a custodian) can delegate patches to a specific maintainer.
I. e. you would not mark them as net, but delegate them to the
network custodian.

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
Do we define evil as the absence of goodness? It seems only  logical
that shit happens--we discover this by the process of elimination.
-- Larry Wall
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201011180643.20457.vap...@gentoo.org you wrote:
 
  Anyway, are there some hints for the maintainers how to work with
  patchwork ?
 
 i looked, but couldnt find any actual documents

Indeed documentation is basicly non-existent.

  Should we already mark ourself as delegate for the patches
  we think we have to manage ?
 
 i think so ... seems like a pretty organic setup rather than a few people 
 whose job it is to monitor/update.  set the delegates for patches that lack
 them, and update patch statuses for ones you know have been 
 accepted/superseded/whatever.

Indeed. If we all cooperate doing this, everybody focussing on his own
domain, we should have worked through the list pretty quickly.  Of
copurse please also feel free to delegate and update patches that are
not in your domain, if you are sure about the results.

All custodians have the same privileges, so eveybody can help.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Good manners are the settled  medium  of  social,  as  specie  is  of
commercial, life; returns are equally expected for both.
   - Lord Chesterfield _Letters to his Son_, 25 December 1753
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [STATUS] Using Patchwork

[Wolfgang Denk]

Hello,

the U-Boot Patchwork setup is now mostly complete (except that Shinya
Kuribayashi has not registered yet).

All registered custodians have administration privileges assigned. so
you can change the state of patches and/or delegate these.

Also, a backlog of patches that was still marked as open in my list
has been added to the database.

I would hereby like to ask all custodians to start using patchwork:

- You can filter patches that have been assigned to you. Try to
  process these.
- You can grab any unassigned patches that fall into your domain.
- You can delegate patches to other custodians if it's clear who
  should be responsible for it.
- You can change the state of patches. for example, if you responded
  with questions or change requests to a patch marked as new, please
  change it's state to Changes Requested.

- for now, please do not use the archive feature.


Unfortunately there is basicly no documentation available about
Patchwork, it seems.  I tried to document what I figured out myself in
Patch Tracking at
http://www.denx.de/wiki/view/U-Boot/Patches#Patch_Tracking

If in doubt, please apply common sense and/or ask here on the list.

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 witty saying proves nothing.   - Voltaire
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] MTD/NAND: fix nand_base.c to use get_timer() correctly

[Reinhard Meyer]

This is part of the timer cleanup effort.
In the future we only use get_timer() in its intended way to
program timeout loops.
reset_timer() shall not be used anymore.

Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
 drivers/mtd/nand/nand_base.c |   15 +--
 1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 21cc5a3..3dcef97 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -439,11 +439,12 @@ void nand_wait_ready(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd-priv;
u32 timeo = (CONFIG_SYS_HZ * 20) / 1000;
+   u32 time_start;
 
-   reset_timer();
+   time_start = get_timer(0);
 
/* wait until command is processed or timeout occures */
-   while (get_timer(0)  timeo) {
+   while (get_timer(time_start)  timeo) {
if (chip-dev_ready)
if (chip-dev_ready(mtd))
break;
@@ -704,6 +705,7 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip 
*this)
 {
unsigned long   timeo;
int state = this-state;
+   u32 time_start;
 
if (state == FL_ERASING)
timeo = (CONFIG_SYS_HZ * 400) / 1000;
@@ -715,10 +717,10 @@ static int nand_wait(struct mtd_info *mtd, struct 
nand_chip *this)
else
this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
 
-   reset_timer();
+   time_start = get_timer(0);
 
while (1) {
-   if (get_timer(0)  timeo) {
+   if (get_timer(time_start)  timeo) {
printf(Timeout!);
return 0x01;
}
@@ -732,8 +734,9 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip 
*this)
}
}
 #ifdef PPCHAMELON_NAND_TIMER_HACK
-   reset_timer();
-   while (get_timer(0)  10);
+   time_start = get_timer(0);
+   while (get_timer(time_start)  10)
+   ;
 #endif /*  PPCHAMELON_NAND_TIMER_HACK */
 
return this-read_byte(mtd);
-- 
1.5.6.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Force setting of ethact

[DUNDA Matthias]

Hi all-

I've been struggeling with the ethact setting in U-Boot: I want U-Boot to load 
from eTSEC0 on our board, but it always comes up with ethact = UEC0 or FSL UEC0 
in older versions.

As ethact is not persistent, my only workaround so far was to change net/eth.c 
so that at all occasions, where ethact is set, it is set to eTSEC0 - during 
development, this was OK for me, but now I am cleaning up!

What's the intended/desired function of ethact, and how should it be 
initialized? Even using CONFIG_ETHPRIME has no effect.

From my understanding of something named ethact, I would expect, that it 
finds the (first) active ethernet device - active in a sense of connected or 
usable or whatever.

Although eTSEC0 is the only connected port on our device, it comes up with UEC0 
- so, even if this interface in on in some way, this does not help here.

How can I force ethact to be eTSEC0 (or whichever I want), without tampering 
U-Boot base files?

Thanks
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Ben Gardiner]

Hi Sugosh,

On Thu, Nov 18, 2010 at 12:26 AM, Sughosh Ganu urwithsugh...@gmail.com wrote:

 hi Ben,

 On Wed Nov 17, 2010 at 11:26:47AM -0500, Ben Gardiner wrote:
  Hi Stefano,
 
  On Wed, Nov 17, 2010 at 5:09 AM, Stefano Babic sba...@denx.de wrote:
   [...]
   diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h 
   b/arch/arm/include/asm/arch-davinci/da8xx_common.h
   deleted file mode 100644
   index 8b564f7..000
   --- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
   +++ /dev/null
   @@ -1,33 +0,0 @@
   -void irq_init(void);
   -int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
   -                                   int n_items);
   -#if defined(CONFIG_DRIVER_TI_EMAC)  
   defined(CONFIG_MACH_DAVINCI_DA850_EVM)
   -void da850_emac_mii_mode_sel(int mode_sel);
   -#endif
 
  I don't know what is the best way to proceed... I like the current
  state of this patch series. I was unable to apply the three patch
  series (Sugosh's, Yours and mine) in any order without conflicts.

  I think you would need to rebase your patch 'da850: Add RMII
  support for EMAC', on top of my patches. I had made changes in the

I agree. A respin is on the way

  include/asm/arch-davinci/hardware.h and moved the
  board/davinci/da8xxevm/common.h, both of which you are making
  changes to. Stefano's patch series should then apply on top of your
  rebased patch. Missed out your patch, else would have flagged you in
  advance. Sorry about that.

No worries.


--
Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/1] imx: Get fec mac address from fuse

[Stefano Babic]

On 11/18/2010 12:49 PM, Jason Liu wrote:
 The patch is to support getting FEC MAC address from fuse bank.
 
 Signed-off-by: Jason Liu r64...@freescale.com
 

Hi Jason,

 diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
 b/arch/arm/include/asm/arch-mx5/imx-regs.h
 index 0b6249a..d618bca 100644
 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
 +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
 @@ -205,9 +205,13 @@
  #define BOARD_REV_1_0   0x0
  #define BOARD_REV_2_0   0x1
  
 +#define IMX_IIM_BASE(IIM_BASE_ADDR)
 +
  #if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
  #include asm/types.h
  
 +extern void imx_get_mac_from_fuse(unsigned char *mac);
 +
  #define __REG(x) (*((volatile u32 *)(x)))
  #define __REG16(x)   (*((volatile u16 *)(x)))
  #define __REG8(x)(*((volatile u8 *)(x)))
 @@ -275,6 +279,36 @@ struct src {
   u32 sisr;
   u32 simr;
  };
 +
 +struct iim_regs {
 + u32 stat;

Space before tabs:

+^Iu32 ^Istat;$

You should run checkpatch on your patch. It checks for such kind of
problems.

 + u32 statm;
   ^--- Space before tabs

The same for all fields in the structure.

I applied your patch and I tested on a i.MX27 Lite board. The result
does not seem correct. According to the manual, the mac address is store
at address 0x10028814. Rather there is no stored MAC at this address on
my board, but your patch read the MAC from address 0x10028810 (I traced
the address of fuse-mac_addr).

The reported address is what we can see at 0x10028810 (Word 4 of
fusebank 0):

md 0x10028804
10028804: 0020 0081 0040 0010 ...@...
10028814:    

And u-boot reports :
Address in SROM is 00:00:00:00:00:10
Address in environment is  00:aa:dd:cc:11:22

It seems you read at a wrong address.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Reinhard Meyer]

 That removes the need to reserve memory above the stack
 and also removes the need for GENERATED_GBL_DATA_SIZE.
 Alignment is automatically right provided stack is
 aligned.
 
 Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
 ---
  arch/arm/lib/board.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index 1fd5f83..53e0f4f 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
   init_fnc_t **init_fnc_ptr;
   gd_t *id;
   ulong addr, addr_sp;
 + gd_t auto_gd;
  
   /* Pointer is writable since we allocated a register for it */
 - gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
 + gd = auto_gd;
   /* compiler optimization barrier needed for GCC = 3.4 */
 - __asm__ __volatile__(: : :memory);
 + /* __asm__ __volatile__(: : :memory); */
  
   memset ((void*)gd, 0, sizeof (gd_t));
  

Are there any objections to this patch now?
I can provide a V2 where the compiler optimization barrier stuff is
completely removed.

Tested on: at91sam9xe / arm926ejs / top9000 and at91sam9xe-ek boards.

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Force setting of ethact

[Wolfgang Denk]

Dear DUNDA Matthias,

In message 
27800_1290086146_4ce52702_27800_13178_1_3cf34b583782c147807e09365f884da42f058fd...@thsncoa06mxs02p.one-06.grp
 you wrote:
 
 I've been struggeling with the ethact setting in U-Boot: I want U-Boot to 
 load from eTSEC0 on our board, but it always comes up with ethact = UEC0 or 
 FSL UEC0 in older versions.
 
 As ethact is not persistent, my only workaround so far was to change 
 net/eth.c so that at all occasions, where ethact is set, it is set to eTSEC0 
 - during development, this was OK for me, but now I am cleaning up!

Why don't you use ethprime ?

 What's the intended/desired function of ethact, and how should it be 
 initialized? Even using CONFIG_ETHPRIME has no effect.

These variabes are documented in the README.

 From my understanding of something named ethact, I would expect, that it 
 finds the (first) active ethernet device - active in a sense of connected or 
 usable or whatever.

active as currently active, i. e. what will be used when you issue
a network command.

 Although eTSEC0 is the only connected port on our device, it comes up with 
 UEC0 - so, even if this interface in on in some way, this does not help 
 here.
 
 How can I force ethact to be eTSEC0 (or whichever I want), without tampering 
 U-Boot base files?

ethact is the wrong variable for what you are trying to do. Use
ethprime instead.

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
panic: can't find /
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Exclude drivers/qe/fdt.c without CONFIG_QE

[Wolfgang Denk]

Dear Sebastien Carlier,

In message 1290078406-23921-1-git-send-email-sebastien.carl...@gmail.com you 
wrote:
 This is a multi-part message in MIME format.
 --1.7.3.2.161.g3089c
 Content-Type: text/plain; charset=UTF-8; format=fixed
 Content-Transfer-Encoding: 8bit
 
 
 Previously with archive libraries fdt.o was compiled and included in
 qe.a and then discarded by the linker.  With partial linking this
 results in unresolved symbols, which this commit fixes.
 
 This commit also cleans up a now-useless conditional in fdt.c.
 
 Signed-off-by: Sebastien Carlier sebastien.carl...@gmail.com
 ---
  drivers/qe/Makefile |2 +-
  drivers/qe/fdt.c|2 --
  2 files changed, 1 insertions(+), 3 deletions(-)

This patch fixes building for the following boards:

MPC8308RDB, MPC8313ERDB_33, MPC8313ERDB_66, MPC8313ERDB_NAND_33,
MPC8313ERDB_NAND_66, MPC8315ERDB, MPC8315ERDB_NAND, MPC8349EMDS,
MPC8349ITX, MPC8349ITXGP, MPC8349ITX_LOWBOOT, MPC837XEMDS,
MPC837XEMDS_HOST, MPC837XERDB, MVBLM7, SIMPC8313_LP, SIMPC8313_SP,
TQM834x, mpc8308_p1m, sbc8349, sbc8349_PCI_33, sbc8349_PCI_66,
ve8313, vme8349

Tested-by: Wolfgang Denk w...@denx.de



Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, Metamorphosis, stardate 3219.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] 4 PiB left unmapped

[DUNDA Matthias]

Hi again,

my current binary of U-Boot claims, that 4 petabyte of memory are unmapped:


U-Boot 2010.09-svn314 (Nov 18 2010 - 15:09:16)

CPU:   8568E, Version: 1.1, (0x807d0011)
Core:  E500, Version: 2.2, (0x80210022)
...
DRAM:  Initializing
4 PiB left unmapped
DDR: 2 GiB (DDR2, 64-bit, CL=4, ECC off)
FLASH: 256 MiB
L2:512 KB enabled

I wish, I had that much memory! ;-)

The version 2009.11.1 we used so far does say that 0 Bytes are unmapped. What 
could that be?

Cheers
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] 4 PiB left unmapped

[Kumar Gala]

On Nov 18, 2010, at 8:41 AM, DUNDA Matthias wrote:

 Hi again,
 
 my current binary of U-Boot claims, that 4 petabyte of memory are unmapped:
 
 
 U-Boot 2010.09-svn314 (Nov 18 2010 - 15:09:16)
 
 CPU:   8568E, Version: 1.1, (0x807d0011)
 Core:  E500, Version: 2.2, (0x80210022)
 ...
 DRAM:  Initializing
 4 PiB left unmapped
DDR: 2 GiB (DDR2, 64-bit, CL=4, ECC off)
 FLASH: 256 MiB
 L2:512 KB enabled
 
 I wish, I had that much memory! ;-)
 
 The version 2009.11.1 we used so far does say that 0 Bytes are unmapped. What 
 could that be?
 
 Cheers
 Matthias

Pretty cool, how much memory do you actually have in the box?

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V3][NEXT] da850: Add RMII support for EMAC

[Ben Gardiner]

From: Sudhakar Rajashekhara sudhakar@ti.com

This patch is a port of the work by Sudhakar Rajeshekhara in commit
ab3effbcad8851cc65dc5241a01c064d2030a3b2 of
git://arago-project.org/git/people/sandeep/u-boot-davinci.git.

The da850 UI board has on it an RMII PHY which can be used if the MDC line
to the MII PHY on the baseboard is disabled and the RMII PHY is enabled by
configuring the values of some GPIO pins on the IO expander of the UI board.
This patch implements disabling that line via GPIO2[6], configuring the UI
board's IO expander and setting only the pinmux settings that are needed for
RMII operation.

Tested on da850evm by adding a define for CONFIG_DRIVER_TI_EMAC_USE_RMII.

Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Sandeep Paulraj s-paul...@ti.com
CC: Ben Warren biggerbadder...@gmail.com
CC: Mike Frysinger vap...@gentoo.org
CC: Sughosh Ganu urwithsugh...@gmail.com

---

Changes since V2:
 * rebased this patch onto the patch series by Sugosh
 * put the declaration of the the rmii_sel function in
   arch/arm/include/asm/arch-davinci/da8xx_common.h to match the changes
   made by sugosh's patch
 * reordered the RMII PHY init and EMAC init
Changes since V1:
  * Removeed spurious quote in Sandeep's CC: line
Changes since work of Sudhakar Rajashekhar:
  * rebased to 0c0892be0d93a5a892b93739c5eb3bf692fed4ff, resolved conflicts.
  * fixup uses of pinmux[x] to pinmux(x)

---
 arch/arm/include/asm/arch-davinci/da8xx_common.h |4 +
 arch/arm/include/asm/arch-davinci/hardware.h |4 +
 board/davinci/da8xxevm/common.c  |   14 +++
 board/davinci/da8xxevm/da850evm.c|  112 +-
 drivers/net/davinci_emac.c   |   41 -
 include/configs/da850evm.h   |1 +
 6 files changed, 171 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h 
b/arch/arm/include/asm/arch-davinci/da8xx_common.h
index bc3092d..e52f613 100644
--- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
+++ b/arch/arm/include/asm/arch-davinci/da8xx_common.h
@@ -30,4 +30,8 @@ void irq_init(void);
 int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
int n_items);
 
+#if defined(CONFIG_DRIVER_TI_EMAC)  defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel);
+#endif
+
 #endif /* __COMMON_H */
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h 
b/arch/arm/include/asm/arch-davinci/hardware.h
index d006ac1..4ac6906 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -150,6 +150,10 @@ typedef volatile unsigned int *dv_reg_p;
 #define DAVINCI_INTC_BASE  0xfffee000
 #define DAVINCI_BOOTCFG_BASE   0x01c14000
 
+#define GPIO_BANK2_REG_DIR_ADDR(DAVINCI_GPIO_BASE + 
0x38)
+#define GPIO_BANK2_REG_OPDATA_ADDR (DAVINCI_GPIO_BASE + 0x3c)
+#define GPIO_BANK2_REG_SET_ADDR(DAVINCI_GPIO_BASE + 
0x40)
+#define GPIO_BANK2_REG_CLR_ADDR(DAVINCI_GPIO_BASE + 
0x44)
 #endif /* CONFIG_SOC_DA8XX */
 
 /* Power and Sleep Controller (PSC) Domains */
diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c
index 36bf693..2d9a64b 100644
--- a/board/davinci/da8xxevm/common.c
+++ b/board/davinci/da8xxevm/common.c
@@ -53,3 +53,17 @@ int da8xx_configure_lpsc_items(const struct lpsc_resource 
*item,
 
return 0;
 }
+
+#if defined(CONFIG_DRIVER_TI_EMAC)  defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel)
+{
+   int val;
+
+   val = readl(davinci_syscfg_regs-cfgchip3);
+   if (mode_sel == 0)
+   val = ~(1  8);
+   else
+   val |= (1  8);
+   writel(val, davinci_syscfg_regs-cfgchip3);
+}
+#endif
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index 0420ad5..a6e2dab 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -54,6 +54,15 @@ static const struct pinmux_config uart_pins[] = {
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 static const struct pinmux_config emac_pins[] = {
+#ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
+   { pinmux(14), 8, 2 },
+   { pinmux(14), 8, 3 },
+   { pinmux(14), 8, 4 },
+   { pinmux(14), 8, 5 },
+   { pinmux(14), 8, 6 },
+   { pinmux(14), 8, 7 },
+   { pinmux(15), 8, 1 },
+#else /* ! CONFIG_DRIVER_TI_EMAC_USE_RMII */
{ pinmux(2), 8, 1 },
{ pinmux(2), 8, 2 },
{ pinmux(2), 8, 3 },
@@ -69,10 +78,10 @@ static const struct pinmux_config emac_pins[] = {
{ pinmux(3), 8, 5 },
{ pinmux(3), 8, 6 },
{ pinmux(3), 8, 7 },
+#endif /* CONFIG_DRIVER_TI_EMAC_USE_RMII */
{ pinmux(4), 8, 0 },
{ pinmux(4), 8, 1 }
 };
-#endif /* CONFIG_DRIVER_TI_EMAC */
 
 /* 

Re: [U-Boot] Force setting of ethact

[DUNDA Matthias]

 Why don't you use ethprime ?

  What's the intended/desired function of ethact, and how should it be
 initialized? Even using CONFIG_ETHPRIME has no effect.

 These variabes are documented in the README.

Yes, I read that! That's why I used CONFIG_ETHPRIME in my board header file to 
do the trick - maybe my env was corrupted, or something - I don't know, why it 
didn't show up by default... I had to setenv it by hand.

Thanks.
Matthias


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] 4 PiB left unmapped

[DUNDA Matthias]

  CPU:   8568E, Version: 1.1, (0x807d0011)
  Core:  E500, Version: 2.2, (0x80210022)
  ...
  DRAM:  Initializing
  4 PiB left unmapped
 DDR: 2 GiB (DDR2, 64-bit, CL=4, ECC off)
  FLASH: 256 MiB
  L2:512 KB enabled


 Pretty cool, how much memory do you actually have in the box?


Well, it's actually 2 Gig, just like u-boot recognizes above...

- Matthias


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] revert tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode

[Peter Tyser]

snip

 My understanding is that the SGMII link is always at 1000Mbps speed - see
 figure 1 from the app note.  Additionally look at figure 3.  My understand
 from it, and the app note's text is that SGMII auto-negotiation doesn't
 really occur - its just passing the PHY-side auto-negotiation results to
 the Freescale MAC, which software then configures.  I'm not sure what the
 purpose of the SGMII auto-negotiation is - its not really auto-
 negotiating and the same information can be read from the PHY via its MDIO
 interface, which is what is happening on X-ES boards currently.
 
 I guess the point is to save MDIO signals to the external PHY and read the
 negotiated result from the internal TBI PHY.

Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO
interface to their PHYs'?  I've never heard of a board that doesn't, and
would guess the tsec driver in U-Boot requires a PHY to be accessible
via MDIO to use the corresponding network interface.

I can forward you the email thread about SGMII auto-negotiation with
Freescale's FAE off-list if you'd like as well.

Best,
Peter

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Force setting of ethact

[Wolfgang Denk]

Dear DUNDA Matthias,

In message 
13246_1290092163_4ce53e83_13246_17888_1_3cf34b583782c147807e09365f884da42f058fe...@thsncoa06mxs02p.one-06.grp
 you wrote:

   What's the intended/desired function of ethact, and how should it be
  initialized? Even using CONFIG_ETHPRIME has no effect.
 
  These variabes are documented in the README.
 
 Yes, I read that! That's why I used CONFIG_ETHPRIME in my board header file 
 to do the trick - maybe my env was corrupted, or something - I don't know, 
 why it didn't show up by default... I had to setenv it by hand.

CONFIG_ETHPRIME affects only your _default_ envrionment, i. e. what
gets used when the normal environment is not available for some reason
(like corrupted). As long as it remains valid, installing a new U-Boot
image with additional settings in the _default_ environment will not
change anything as the default environment never gets referenced.

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
Star Trek Lives!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Albert ARIBAUD]

Le 18/11/2010 14:53, Reinhard Meyer a écrit :
 That removes the need to reserve memory above the stack
 and also removes the need for GENERATED_GBL_DATA_SIZE.
 Alignment is automatically right provided stack is
 aligned.

 Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de
 ---
   arch/arm/lib/board.c |5 +++--
   1 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index 1fd5f83..53e0f4f 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
  init_fnc_t **init_fnc_ptr;
  gd_t *id;
  ulong addr, addr_sp;
 +gd_t auto_gd;

  /* Pointer is writable since we allocated a register for it */
 -gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
 +gd =auto_gd;
  /* compiler optimization barrier needed for GCC= 3.4 */
 -__asm__ __volatile__(: : :memory);
 +/* __asm__ __volatile__(: : :memory); */

  memset ((void*)gd, 0, sizeof (gd_t));


 Are there any objections to this patch now?
 I can provide a V2 where the compiler optimization barrier stuff is
 completely removed.

 Tested on: at91sam9xe / arm926ejs / top9000 and at91sam9xe-ek boards.

I'm probably lagging behind... How do you ensure that the pre-relocation 
GD content ends up in the post-relocation GD (which cannot be that stack 
variable since the stack is going to be somewhere else)?

 Best Regards,
 Reinhard

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Detlev Zundel]

Hi Scott,

 On Wed, 17 Nov 2010 13:42:43 +0100
 Detlev Zundel d...@denx.de wrote:

  Yes, a simple C tool to take an existing PBL or RCW dump and espi-ize
  it into a PBL dump would be nice.  The user will still need to acquire
  the existing RCW manually.  This only needs to be done once on a board;
  it's not part of building a U-Boot image.
 
 @Scott: What is meant by acquiring the existing RCW?  Can't we have a
 tool that is fed with a value for RCW?

 I mean that a simple tool could take an existing RCW and modify it for
 espi boot, but it needs to take as input an RCW that is valid for other
 parameters.

 The least error prone way to do this, for a user that wants to take a
 board that's already successfully booting from NOR and make it boot
 from eSPI, is to extract the RCW they're already using from the board.

Ok, thanks for the explanation.

 Creating an RCW from scratch is more complicated, which is why we
 have that javascript tool -- though we could provide some example RCWs
 for common configs.

Just for my information - it sounds like the RCW is really complex.  If
RCW still expands to reset control word, I would expect it to be 32
bits though.  It is rather common for U-Boot porters to determine 32-bit
values for specific registers without using a javascript tool, so maybe
I'm wrong here.

  This README describes how to build an Image can be used by PBL (pre-boot
  loader), building u-boot image is the first step, then RCW, PBI
  commands, XXD dump of u-boot.bin, the tool will combine the RCW and PBI
  and XXD dump together to produce the PBL XXD file, suppose the PBL XXD
  file is saved as x.xxd, we need to run xxd -r x.xxd  pbl_image.bin to
  produce the final PBL Image. Take a look at the whole process, I see no
  way it can be scripted / automatized.
 
 I said it once before, look at how kwbimage wraps up u-boot.bin into
 such an augmented image.  If the Marvell guys can do this for their
 platform, I see no reason why this cannot be done for your platform.

 Sure, once you have a valid input RCW it should be possible to automate
 the rest.

For the supported configurations the RCW should be provided of course,
so I do not see a big problem here?

Cheers
  Detlev

-- 
Practice random senselessness and act kind of beautiful.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Using Patchwork

[Loïc Minier]

On Thu, Nov 18, 2010, Wolfgang Denk wrote:
 Unfortunately there is basicly no documentation available about
 Patchwork, it seems.  I tried to document what I figured out myself in
 Patch Tracking at
 http://www.denx.de/wiki/view/U-Boot/Patches#Patch_Tracking

 Jeremy Kerr presented Patchwork recently at Plumbers, the slides are at
 
http://www.linuxplumbersconf.org/2010/ocw//system/presentations/297/original/patchwork-lpc2010.pdf
 maybe this helps a bit?  Videos weren't uploaded yet

-- 
Loïc Minier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Kumar Gala]

 Creating an RCW from scratch is more complicated, which is why we
 have that javascript tool -- though we could provide some example RCWs
 for common configs.
 
 Just for my information - it sounds like the RCW is really complex.  If
 RCW still expands to reset control word, I would expect it to be 32
 bits though.  It is rather common for U-Boot porters to determine 32-bit
 values for specific registers without using a javascript tool, so maybe
 I'm wrong here.

On P4080 (and future devices) it is 512 bits of data so not as trivial as our 
older parts that used a simple 32-bit RCW.

 This README describes how to build an Image can be used by PBL (pre-boot
 loader), building u-boot image is the first step, then RCW, PBI
 commands, XXD dump of u-boot.bin, the tool will combine the RCW and PBI
 and XXD dump together to produce the PBL XXD file, suppose the PBL XXD
 file is saved as x.xxd, we need to run xxd -r x.xxd  pbl_image.bin to
 produce the final PBL Image. Take a look at the whole process, I see no
 way it can be scripted / automatized.
 
 I said it once before, look at how kwbimage wraps up u-boot.bin into
 such an augmented image.  If the Marvell guys can do this for their
 platform, I see no reason why this cannot be done for your platform.
 
 Sure, once you have a valid input RCW it should be possible to automate
 the rest.
 
 For the supported configurations the RCW should be provided of course,
 so I do not see a big problem here?

Agreed, we should be provide a default RCW for the boards as part of u-boot.

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC

[Kumar Gala]

Some systems need to relocate the env_addr pointer early because the
location its point to will get invalidated before env_relocate is
called.  One example is on systems that might use a L2 or L3 cache
in SRAM mode and initialize that cache from SRAM mode back to being
a cache in cpu_init_r.

We set this on the 85xx boards that have support for NAND, SPI, or
SDHC/MMC boot support as they use a secondary cache in SRAM mode and
need the env_addr pointer relocated since we change from SRAM to normal
cache mode in cpu_init_r.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/lib/board.c |   11 +++
 include/configs/MPC8536DS.h  |1 +
 include/configs/MPC8569MDS.h |1 +
 include/configs/P1_P2_RDB.h  |1 +
 4 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 2e0749d..ce51c8f 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -645,6 +645,17 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd-cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;
 #endif
 
+#ifdef CONFIG_SYS_EXTRA_ENV_RELOC
+   /*
+* Some systems need to relocate the env_addr pointer early because the
+* location its point to will get invalidated before env_relocate is
+* called.  One example is on systems that might use a L2 or L3 cache
+* in SRAM mode and initialize that cache from SRAM mode back to being
+* a cache in cpu_init_r.
+*/
+   gd-env_addr += dest_addr - CONFIG_SYS_MONITOR_BASE;
+#endif
+
 #ifdef CONFIG_SERIAL_MULTI
serial_initialize();
 #endif
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 850665a..50d282c 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -245,6 +245,7 @@
 #if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) \
|| defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH)
 #define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
 #else
 #undef CONFIG_SYS_RAMBOOT
 #endif
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h
index c7973b4..20fd672 100644
--- a/include/configs/MPC8569MDS.h
+++ b/include/configs/MPC8569MDS.h
@@ -205,6 +205,7 @@ extern unsigned long get_clock_freq(void);
 
 #if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND)
 #define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
 #else
 #undef CONFIG_SYS_RAMBOOT
 #endif
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 610f3ed..8069b55 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -204,6 +204,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
 #if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) \
|| defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH)
 #define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
 #else
 #undef CONFIG_SYS_RAMBOOT
 #endif
-- 
1.7.2.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC

[Kumar Gala]

On Nov 18, 2010, at 11:21 AM, Kumar Gala wrote:

 Some systems need to relocate the env_addr pointer early because the
 location its point to will get invalidated before env_relocate is
 called.  One example is on systems that might use a L2 or L3 cache
 in SRAM mode and initialize that cache from SRAM mode back to being
 a cache in cpu_init_r.
 
 We set this on the 85xx boards that have support for NAND, SPI, or
 SDHC/MMC boot support as they use a secondary cache in SRAM mode and
 need the env_addr pointer relocated since we change from SRAM to normal
 cache mode in cpu_init_r.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 arch/powerpc/lib/board.c |   11 +++
 include/configs/MPC8536DS.h  |1 +
 include/configs/MPC8569MDS.h |1 +
 include/configs/P1_P2_RDB.h  |1 +
 4 files changed, 14 insertions(+), 0 deletions(-)

Wolfgang,

I dont think either of us are happy with this solution but not really sure what 
else to do.  Please ack if you're grudgingly ok with this.  :)

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC

[Becky Bruce]

On Nov 18, 2010, at 11:21 AM, Kumar Gala wrote:

 Some systems need to relocate the env_addr pointer early because the
 location its point to will get invalidated before env_relocate is
 called.  One example is on systems that might use a L2 or L3 cache
 in SRAM mode and initialize that cache from SRAM mode back to being
 a cache in cpu_init_r.
 
 We set this on the 85xx boards that have support for NAND, SPI, or
 SDHC/MMC boot support as they use a secondary cache in SRAM mode and
 need the env_addr pointer relocated since we change from SRAM to normal
 cache mode in cpu_init_r.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 arch/powerpc/lib/board.c |   11 +++
 include/configs/MPC8536DS.h  |1 +
 include/configs/MPC8569MDS.h |1 +
 include/configs/P1_P2_RDB.h  |1 +
 4 files changed, 14 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
 index 2e0749d..ce51c8f 100644
 --- a/arch/powerpc/lib/board.c
 +++ b/arch/powerpc/lib/board.c
 @@ -645,6 +645,17 @@ void board_init_r (gd_t *id, ulong dest_addr)
   gd-cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;
 #endif
 
 +#ifdef CONFIG_SYS_EXTRA_ENV_RELOC
 + /*
 +  * Some systems need to relocate the env_addr pointer early because the
 +  * location its point to will get invalidated before env_relocate is
^^

Not to nitpick, but please correct this - I think you meant location it points 
to?

-B

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] OMAP4: Panda: Disable CMD_NFS

[Steve Sakoman]

This patch fixes the Panda build after commit 
6d8962e814c15807dd6ac5757904be2a02d187b8
by explicitly disabling CMD_NFS

From the commit message for Switch from archive libraries to partial linking:

This commit reveals board configurations that exclude some features but
include source files that depend these disabled features in the build,
resulting in undefined symbols.  Known such cases include:

- disabling CMD_NET but not CMD_NFS;
- enabling CONFIG_OF_LIBFDT but not CONFIG_QE.

Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---

diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index e373fe0..8715ed7 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -134,6 +134,7 @@
 
 /* Disabled commands */
 #undef CONFIG_CMD_NET
+#undef CONFIG_CMD_NFS
 #undef CONFIG_CMD_FPGA /* FPGA configuration Support   */
 #undef CONFIG_CMD_IMLS /* List all found images*/
 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i2c, mpc5xxx: add multibus support

[Heiko Schocher]

Hello Heiko,

Heiko Schocher wrote:
 Tested on upcoming hydra (mpc5200 based) board.
 
 Signed-off-by: Heiko Schocher h...@denx.de
 ---
  arch/powerpc/cpu/mpc5xxx/i2c.c |   43 
 
  1 files changed, 43 insertions(+), 0 deletions(-)

Applied to u-boot-iwc.git.

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] post, i2c: add missing curly bracket in i2c_post_test

[Heiko Schocher]

Hello Heiko,

Heiko Schocher wrote:
 If CONFIG_SYS_POST_I2C_ADDRS is not defined and CONFIG_SYS_POST_I2C
 is activated, i2c_probe() is not called in the for statement,
 because missing curly bracket.
 
 Signed-off-by: Heiko Schocher h...@denx.de
 ---
  post/drivers/i2c.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

Applied to u-boot-iwc.git.

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-i2c

[Heiko Schocher]

Hello Wolfgang,

The following changes since commit 8ad25bf8d9233eb7d0b614612108622a59069354:

  Net: clarify board/cpu_eth_init calls (2010-11-15 00:01:15 +0100)

are available in the git repository at:
  git://git.denx.de/u-boot-i2c.git master

Heiko Schocher (2):
  i2c, mpc5xxx: add multibus support
  post, i2c: add missing curly bracket in i2c_post_test

 arch/powerpc/cpu/mpc5xxx/i2c.c |   43 
 post/drivers/i2c.c |3 +-
 2 files changed, 45 insertions(+), 1 deletions(-)
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Mike Frysinger]

On Thursday, November 18, 2010 07:46:01 Wolfgang Denk wrote:
 Mike Frysinger wrote:
  patchwork should hopefully help ?  ive never used it before so i dont
  know of its capabilities.  is there a way to mark things as net ?
 
 Patchwork should indeed help.
 
 You (as a custodian) can delegate patches to a specific maintainer.
 I. e. you would not mark them as net, but delegate them to the
 network custodian.

right, but atm that is you, so there isnt much of a way to differentiate 
between the massive common patches that go to you and just network ones
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Force setting of ethact

[Mike Frysinger]

On Thursday, November 18, 2010 08:15:43 DUNDA Matthias wrote:
 Hi all-

please fix your e-mailer.  it needs to wrap long lines.

 I've been struggeling with the ethact setting in U-Boot: I want U-Boot to
 load from eTSEC0 on our board, but it always comes up with ethact = UEC0
 or FSL UEC0 in older versions.
 
 As ethact is not persistent, my only workaround so far was to change
 net/eth.c so that at all occasions, where ethact is set, it is set to
 eTSEC0 - during development, this was OK for me, but now I am cleaning up!
 
 What's the intended/desired function of ethact, and how should it be
 initialized? Even using CONFIG_ETHPRIME has no effect.

ethprime should do this.  you'll need to describe what version of u-boot 
you're actually using and why ethprime isnt working for you.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] 4 PiB left unmapped

[Timur Tabi]

On Thu, Nov 18, 2010 at 9:02 AM, DUNDA Matthias
matthias.du...@thalesgroup.com wrote:

 Well, it's actually 2 Gig, just like u-boot recognizes above...

There's something wrong with the parameter you're passing to print_size().

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201011181346.23452.vap...@gentoo.org you wrote:

  You (as a custodian) can delegate patches to a specific maintainer.
  I. e. you would not mark them as net, but delegate them to the
  network custodian.
 
 right, but atm that is you, so there isnt much of a way to differentiate 
 between the massive common patches that go to you and just network ones

That's true.  BUt it's still better if the patch is explicitly on my
todo list than it's being left unassigned.  As soon as a new net
custodian volunteers I can still re-delgate everything he is willing
to swallow.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There are two ways to write error-free programs. Only the  third  one
works.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Betreff: Stellenangebot

[contractprinting]

Guten Tag,

ELS, amerikanisches Unternehmen im Bereich luxurioser Guter, sucht 
Administrationsassistentinnen/Verkauferinnen in Deutschland, der/die von 
zuhause aus arbeiten, unser Verkaufsmannschaft verstarken und unsere 
Kundendienste aufwerten, welche fur Privatpersonen, Betriebe und Einrichtungen 
weltweit bestimmt sind.

Diese Stelle ist zustandig fur das Management von taglichen, wochentlichen und 
monatlichen Fragen und speziellen Projekten, die der Verstarkung der 
Verkaufsaktivitaten in Deutschland beitragen.

Die Hauptziele sind:
- Aufrechterhaltung der Absatzabteilung in Form spezieller Projekte, 
Dateneingabe und andere Aufgaben wie zugewiesen;
- Pflege der Tabellen fur die Kontrolle von Beschaffungen  und Abdeckungen;
- Allgemeine verwaltungsma?ige Unterstutzung inklusive Erstellung von;
Berichterstattungen Auftragsausfertigung von Bestellungen, Erstellen von 
Kosten- etc. tagliche Email-Korrespondenz

Einsatzzeiten: es ist moglich eine Teil- oder Vollzeitstelle anzunehmen. Ihr 
Arbeitszeit kann flexibel sein. Fur die Teilzeitarbeit ist es notwendig im 
Durchschnittlich 3 Stunden taglich  von Montag bis Freitag zu arbeiten.

Verdienst: Basislohn fur Teilzeitarbeit ist 1800,00 Euro monatlich plus 5% 
Kommission fur jede erfolgreich beendete Tranche mit dem Auftraggeber 
(Geschaftskunde | Auftraggeber).

Arbeitsstelle: von zuhause aus. Verbindungen wird online durchgefuhrt. In der 
Schulungs-/Arbeitsperiode ist es eventuell telefonische Unterstutzung zu 
bekommen.

Erfordernisse: man muss einen Computer mit Internetzugang haben, in Excel 
arbeiten konnen, Elementarkenntnisse in Englisch und gute Motivation haben.

Aufwande und Abgeltungen: es entstehen zu keiner Zeit Kosten fur unsere 
Mitarbeiter. Alle Zahlungen, die mit dieser Arbeit verbunden sind, werden von 
der Firma beglichen.

Weitere Anwerbungsprozedur: bitte senden Sie Ihren Resumee an die: 
carol.m...@elswork.com

In Ihrem E-Mail teilen Sie bitte mit, ob Sie sich fur eine Teil- oder 
Vollzeitarbeit interessieren. Nachdem wir alle Anmeldungen gesichtet haben, 
werden wir nur den erfolgreichen Bewerbern antworten.  Wir werden den 
erfolgreichen Bewerbern eine Stelle in unsere Firma fur eine Bewahrungszeit von 
einem Monat anbieten. Wahrend dieser Zeit werden Sie eingeschult und online 
unterstutzt, gleichzeitig arbeiten Sie schon und werden auch bezahlt. Am Ende 
der Probezeit kann der Berater eine feste Arbeitsstelle, eine Weiterbildung 
oder Kundigung empfehlen. Nach der Probezeit wird Ihr Grundlohn erhoht. 


Bitte senden Sie etwaige Fragen und Ihren Lebenslauf an die: 
carol.m...@elswork.com


Danke,
ELS-Team



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] 4 PiB left unmapped

[Kumar Gala]

On Nov 18, 2010, at 1:04 PM, Timur Tabi wrote:

 On Thu, Nov 18, 2010 at 9:02 AM, DUNDA Matthias
 matthias.du...@thalesgroup.com wrote:
 
 Well, it's actually 2 Gig, just like u-boot recognizes above...
 
 There's something wrong with the parameter you're passing to print_size().

I'm guessing its -1 or something like that.

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] OT Flashing high volume of devices

[Hamilton Vera]

Hi folks this is probably out off topic, we are happily using uboot in
our devices but I am wondering about the procedures to flash/deploy
uboot (or any bootloader) in a high scale production environment.

Are you guys aware of any documentation or procedure to do that?


Sorry about the off topic, but I am not finding useful info at google.


Thanks

-- 
Hamilton Vera
int Administrator (char Network[],char ComputationalSystems[])
http://hvera.wordpress.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC

[Kumar Gala]

Some systems need to relocate the env_addr pointer early because the
location it points to will get invalidated before env_relocate is
called.  One example is on systems that might use a L2 or L3 cache
in SRAM mode and initialize that cache from SRAM mode back to being
a cache in cpu_init_r.

We set this on the 85xx boards that have support for NAND, SPI, or
SDHC/MMC boot support as they use a secondary cache in SRAM mode and
need the env_addr pointer relocated since we change from SRAM to normal
cache mode in cpu_init_r.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Fixed comments per becky feedback

 arch/powerpc/lib/board.c |   11 +++
 include/configs/MPC8536DS.h  |1 +
 include/configs/MPC8569MDS.h |1 +
 include/configs/P1_P2_RDB.h  |1 +
 4 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 2e0749d..40d8c92 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -645,6 +645,17 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd-cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;
 #endif
 
+#ifdef CONFIG_SYS_EXTRA_ENV_RELOC
+   /*
+* Some systems need to relocate the env_addr pointer early because the
+* location it points to will get invalidated before env_relocate is
+* called.  One example is on systems that might use a L2 or L3 cache
+* in SRAM mode and initialize that cache from SRAM mode back to being
+* a cache in cpu_init_r.
+*/
+   gd-env_addr += dest_addr - CONFIG_SYS_MONITOR_BASE;
+#endif
+
 #ifdef CONFIG_SERIAL_MULTI
serial_initialize();
 #endif
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 850665a..50d282c 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -245,6 +245,7 @@
 #if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) \
|| defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH)
 #define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
 #else
 #undef CONFIG_SYS_RAMBOOT
 #endif
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h
index c7973b4..20fd672 100644
--- a/include/configs/MPC8569MDS.h
+++ b/include/configs/MPC8569MDS.h
@@ -205,6 +205,7 @@ extern unsigned long get_clock_freq(void);
 
 #if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND)
 #define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
 #else
 #undef CONFIG_SYS_RAMBOOT
 #endif
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 610f3ed..8069b55 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -204,6 +204,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
 #if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) \
|| defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH)
 #define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
 #else
 #undef CONFIG_SYS_RAMBOOT
 #endif
-- 
1.7.2.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OT Flashing high volume of devices

[Wolfgang Denk]

Dear Hamilton Vera,

In message aanlktim-w-ijinppmsmum++9mwwsxbontodpb5hh6...@mail.gmail.com you 
wrote:
 Hi folks this is probably out off topic, we are happily using uboot in
 our devices but I am wondering about the procedures to flash/deploy
 uboot (or any bootloader) in a high scale production environment.

What sort of boot device are you using?  NOR flash? NAND flash?

For high volumes, you can get pre-programmed flash chips, so you have
a running system when the boards come from assembly.


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
Computers are not intelligent.  They only think they are.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Reinhard Meyer]

Dear Albert ARIBAUD,
 Le 18/11/2010 14:53, Reinhard Meyer a écrit :
 That removes the need to reserve memory above the stack
 and also removes the need for GENERATED_GBL_DATA_SIZE.
 Alignment is automatically right provided stack is
 aligned.

 Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de
 ---
 arch/arm/lib/board.c | 5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index 1fd5f83..53e0f4f 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
 init_fnc_t **init_fnc_ptr;
 gd_t *id;
 ulong addr, addr_sp;
 + gd_t auto_gd;

 /* Pointer is writable since we allocated a register for it */
 - gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
 + gd =auto_gd;
 /* compiler optimization barrier needed for GCC= 3.4 */
 - __asm__ __volatile__(: : :memory);
 + /* __asm__ __volatile__(: : :memory); */

 memset ((void*)gd, 0, sizeof (gd_t));


 Are there any objections to this patch now?
 I can provide a V2 where the compiler optimization barrier stuff is
 completely removed.

 Tested on: at91sam9xe / arm926ejs / top9000 and at91sam9xe-ek boards.

 I'm probably lagging behind... How do you ensure that the pre-relocation GD 
 content ends up in the post-relocation GD (which cannot be that stack 
 variable since the stack is going to be somewhere else)?

Check the function yourself:
there is a memcpy of this GD to an area in SDRAM at the end...

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OT Flashing high volume of devices

[Peter Barada]

On 11/18/2010 03:39 PM, Wolfgang Denk wrote:
 Dear Hamilton Vera,

 In messageaanlktim-w-ijinppmsmum++9mwwsxbontodpb5hh6...@mail.gmail.com  you 
 wrote:

 Hi folks this is probably out off topic, we are happily using uboot in
 our devices but I am wondering about the procedures to flash/deploy
 uboot (or any bootloader) in a high scale production environment.
  
 What sort of boot device are you using?  NOR flash? NAND flash?

 For high volumes, you can get pre-programmed flash chips, so you have
 a running system when the boards come from assembly.

Indeed, pre-programing flash used in the board assembly is the way to 
go.  Most manufacturers make the initial image a self-test program that 
initially exercise all I/O (the board is initially powered up attached 
to a test/burn-in fixture), and if the test succeeds, then re-burns the 
flash with the production image(u-boot/Linux/rootfs or otherwise) that 
is part of the test-image.  If the test fails, then the board is 
rejected and reworked to diagnose/fix found issues (cold-solder, lifted 
pins, etc).

Speed of testing/initial burn-in can be increased by running more than 
one fixture in parallel.

-- 
Peter Barada
pet...@logicpd.com

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Albert ARIBAUD]

Le 18/11/2010 21:43, Reinhard Meyer a écrit :

 I'm probably lagging behind... How do you ensure that the pre-relocation GD 
 content ends up in the post-relocation GD (which cannot be that stack 
 variable since the stack is going to be somewhere else)?

 Check the function yourself:
 there is a memcpy of this GD to an area in SDRAM at the end...

Apologies: I *was* indeed lagging behind.

 Best Regards,
 Reinhard

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OT Flashing high volume of devices

[Hamilton Vera]

Dear Wolfgang, thanks for your reply.

Actually we are using NAND, since NAND usually comes with some bad
blocks from the provider I am worried about the procedure and best
practices.

Thank you a lot.

Hamilton Vera



On Thu, Nov 18, 2010 at 6:39 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Hamilton Vera,

 In message aanlktim-w-ijinppmsmum++9mwwsxbontodpb5hh6...@mail.gmail.com you 
 wrote:
 Hi folks this is probably out off topic, we are happily using uboot in
 our devices but I am wondering about the procedures to flash/deploy
 uboot (or any bootloader) in a high scale production environment.

 What sort of boot device are you using?  NOR flash? NAND flash?

 For high volumes, you can get pre-programmed flash chips, so you have
 a running system when the boards come from assembly.


 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
 Computers are not intelligent.  They only think they are.




-- 
Hamilton Vera
int Administrator (char Network[],char ComputationalSystems[])
http://hvera.wordpress.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHWORK] 71715 - Not applicable.

[Albert ARIBAUD]

Yay, my first todo in patchwork! :)

http://patchwork.ozlabs.org/patch/71715/

It was discussed there:

http://www.mail-archive.com/u-boot@lists.denx.de/msg28003.html

AIUI, the discussion was about asm-generic/unaligned.h rather than about 
the patch itself. Personally I think that the patch could have been 
applied, and *then* asm-generic/unaligned.h could have been brought in 
sync with its Linux counterpart.

Anyway this patch requires a rebase now as the whole arch organization 
has moved around. Ergo: not applicable; if the patch is needed, I'd like 
it to be resubmitted based on current master.

Note: I am posting this to the list because we're only starting using 
patchwork, so maybe we should share our experience for the moment; I 
don't know yet what patchwork action is worthy of a post on the list and 
what is not. For all I know, maybe patchwork itself is going to post 
something right after I set the not applicable status...

In any case, *do not* blindly take this message as the Right Way To Do 
Things With Patchwork! I don't want to start a wrong habit.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Wolfgang Denk]

Dear Sebastien Carlier,

In message 20101117133056.gb23...@safe.home.local you wrote:
 
  MPC8xx boards break with long lists of multiple definitions of
  symbols, like that:
  
  Configuring for FPS860L board...
  lib/libgeneric.o: In function `vsprintf':
  /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of 
  `vsprintf'
  ...
  
  Have you seen that, too?
 
 Unfortunately I have not been able to reproduce these errors with the
 toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
 emdebian squeeze packages).  Can you please point me to the toolchain
 you are using?

Are you sure this doesn't happen with your tool chain?

I found out why this happens, and I think the effect should be
independent of the used tool chain:

For example, in board/tqc/tqm8xx/u-boot.lds we arrange to have the
environment located in one of the small NOR flash sectors:

...
 53   .text  :
 54   {
 55 /* WARNING - the following is hand-optimized to fit within  */
 56 /* the sector layout of our flash chips!XXX FIXME XXX   */
 57
 58 arch/powerpc/cpu/mpc8xx/start.o (.text)
 59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
 60 common/dlmalloc.o   (.text)
 61 arch/powerpc/lib/ppcstring.o(.text)
 62 lib/vsprintf.o  (.text)
 63 lib/crc32.o (.text)
 64 lib/zlib.o  (.text)
 65 arch/powerpc/lib/cache.o(.text)
 66
 67 . = DEFINED(env_offset) ? env_offset : .;
 68 common/env_embedded.o   (.ppcenv)
 69
 70 *(.text)
 71 *(.got1)
...

That means, the linker script pulls in certain object files directly.
Before, when linking with libraries, this was no problem, as the
linker would pull only (so far) unresolved symbols from the libraries
specified on the command line.  Now, we include these individual
object files through the linker script, and then again when specifying
the library objects on the command line - which necessarily results
in multiple definition errors.

Unfortunately I don't know how to solve this yet.  Does anybody know of
a way how to manually arrange the objects (or symbols) in the linked
image?


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
My challenge to the goto-less programmer  is  to  recode  tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch). - W. R. Stevens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Ben Gardiner]

Hi Stefano,

Sorry for the long delay. I thought rebasing my patch onto Sugosh's
series would be a good start to getting all of our patches applied
together. What I didn't realize was I that I still did not have the
order of patches you listed below.

On Wed, Nov 17, 2010 at 11:47 AM, Stefano Babic sba...@denx.de wrote:
 [...]
 6a1b17dd5cdaeb4c Davinci: add support for the ea20 board
 5195253f20d5bedb Davinci 8xx: Move common functions to share code
 8e6ed317d74b3b4d da850: Add RMII support for EMAC
 9c1455c63dafc292 Move and rename common headers from under board/davinci.
 4ccdfedb55b65f30 da850: Enable SPI Flash
 0aacad5f81caac89 da8xx: Add cpu_is_da8xx macros
 8ad25bf8d9233eb7 Net: clarify board/cpu_eth_init calls
   ^
   |--- this is actual u-boot TOT

The problem was that I was applying my RMII patch on top of Sugosh's
patches without your SPI flash patches underneath. Another RMII
version patch is coming.

Still, there were some merge conflicts due to the fact that you were
basing your ea20 patches off of only 1 of Sugosh's patches. here is
the 'git log --format=%s -- %Cgreen%an %aE %Cred%ai
u-boot/master^..HEAD' output after all the merging.

Davinci: add support for the ea20 board -- Stefano Babic
sba...@denx.de 2010-11-17 11:09:05 +0100
Davinci 8xx: Move common functions to share code -- Stefano Babic
sba...@denx.de 2010-11-17 11:09:04 +0100
[PATCH V4][NEXT] da850: Add RMII support for EMAC -- Sudhakar
Rajashekhara sudhakar@ti.com 2010-11-18 09:59:37 -0500
Add board support for hawkboard -- Sughosh Ganu
urwithsugh...@gmail.com 2010-11-01 23:30:34 +0530
Remove board_init_f function from nand_boot.c -- Sughosh Ganu
urwithsugh...@gmail.com 2010-11-01 23:29:27 +0530
Move and rename common headers from under board/davinci. -- Sughosh
Ganu urwithsugh...@gmail.com 2010-11-01 23:28:38 +0530
da850: Enable SPI Flash -- Stefano Babic sba...@denx.de 2010-11-11
15:38:02 +0100
da8xx: Add cpu_is_da8xx macros -- Sudhakar Rajashekhara
sudhakar@ti.com 2010-11-11 15:38:01 +0100
Net: clarify board/cpu_eth_init calls -- Ben Warren
biggerbadder...@gmail.com 2010-08-31 23:05:04 -0700

You didn't have Add board support for hawkboard and Remove
board_init_f function from nand_boot.c applied.

I hope you don't mind that I merged them and pushed the result to
branch testing-ea20-plus of
git://github.com/BenGardiner/u-boot-bg.git . I hope that saves us some
time.

I will be sending a V4 of the RMII patch -- as can be seen from that
series -- to the list. I hope you can use the merged patches in the
branch I pushed to send your updated patches.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHWORK] 71715 - Not applicable.

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message 4ce59b4e.90...@free.fr you wrote:
 
 Note: I am posting this to the list because we're only starting using 
 patchwork, so maybe we should share our experience for the moment; I 
 don't know yet what patchwork action is worthy of a post on the list and 
 what is not. For all I know, maybe patchwork itself is going to post 
 something right after I set the not applicable status...

No, I don't think so. Patchwork does not send any e-mails by itself.
When you change the state to Changes Required or Not Applicable or
such you are supposed to post a followup on the mailinglist and inform
the submitter of your action.  Patchwork does not replace the mailing
list, it just helps keeping an overview over the patches, and who is
doing what.

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
Overdrawn?  But I still have checks left!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OT Flashing high volume of devices

[Grant Edwards]

On 2010-11-18, Hamilton Vera hamilton.lis...@gmail.com wrote:
 Hi folks this is probably out off topic, we are happily using uboot in
 our devices but I am wondering about the procedures to flash/deploy
 uboot (or any bootloader) in a high scale production environment.

 Are you guys aware of any documentation or procedure to do that?

Send the hex file to the flash distributor and have them do it.

-- 
Grant Edwards   grant.b.edwardsYow! I'm meditating on
  at   the FORMALDEHYDE and the
  gmail.comASBESTOS leaking into my
   PERSONAL SPACE!!

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V4][NEXT] da850: Add RMII support for EMAC

[Ben Gardiner]

From: Sudhakar Rajashekhara sudhakar@ti.com

This patch is a port of the work by Sudhakar Rajeshekhara in commit
ab3effbcad8851cc65dc5241a01c064d2030a3b2 of
git://arago-project.org/git/people/sandeep/u-boot-davinci.git.

The da850 UI board has on it an RMII PHY which can be used if the MDC line
to the MII PHY on the baseboard is disabled and the RMII PHY is enabled by
configuring the values of some GPIO pins on the IO expander of the UI board.
This patch implements disabling that line via GPIO2[6], configuring the UI
board's IO expander and setting only the pinmux settings that are needed for
RMII operation.

Tested on da850evm by adding a define for CONFIG_DRIVER_TI_EMAC_USE_RMII.

Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Sandeep Paulraj s-paul...@ti.com
CC: Mike Frysinger vap...@gentoo.org
CC: Sughosh Ganu urwithsugh...@gmail.com

---

Changes since V3:
 * removed Ben Warren from the CC since he isn't the net custodian anymore
 * rebased ontop of Stefano's SPI patches and Sugosh's hawkboard patches; 
current commits look like:
[PATCH V4][NEXT] da850: Add RMII support for EMAC -- Sudhakar Rajashekhara 
sudhakar@ti.com 2010-11-18 09:59:37 -0500
Add board support for hawkboard -- Sughosh Ganu urwithsugh...@gmail.com 
2010-11-01 23:30:34 +0530
Remove board_init_f function from nand_boot.c -- Sughosh Ganu 
urwithsugh...@gmail.com 2010-11-01 23:29:27 +0530
Move and rename common headers from under board/davinci. -- Sughosh Ganu 
urwithsugh...@gmail.com 2010-11-01 23:28:38 +0530
da850: Enable SPI Flash -- Stefano Babic sba...@denx.de 2010-11-11 15:38:02 
+0100
da8xx: Add cpu_is_da8xx macros -- Sudhakar Rajashekhara sudhakar@ti.com 
2010-11-11 15:38:01 +0100
Net: clarify board/cpu_eth_init calls -- Ben Warren biggerbadder...@gmail.com 
2010-08-31 23:05:04 -0700
Changes since V2:
 * rebased this patch onto the patch series by Sugosh
 * put the declaration of the the rmii_sel function in
   arch/arm/include/asm/arch-davinci/da8xx_common.h to match the changes
   made by sugosh's patch
 * reordered the RMII PHY init and EMAC init
Changes since V1:
  * Removeed spurious quote in Sandeep's CC: line
Changes since work of Sudhakar Rajashekhar:
  * rebased to 0c0892be0d93a5a892b93739c5eb3bf692fed4ff, resolved conflicts.
  * fixup uses of pinmux[x] to pinmux(x)

---
 arch/arm/include/asm/arch-davinci/da8xx_common.h |4 +
 arch/arm/include/asm/arch-davinci/hardware.h |4 +
 board/davinci/da8xxevm/common.c  |   14 +++
 board/davinci/da8xxevm/da850evm.c|  112 +-
 drivers/net/davinci_emac.c   |   41 -
 include/configs/da850evm.h   |1 +
 6 files changed, 171 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h 
b/arch/arm/include/asm/arch-davinci/da8xx_common.h
index bc3092d..e52f613 100644
--- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
+++ b/arch/arm/include/asm/arch-davinci/da8xx_common.h
@@ -30,4 +30,8 @@ void irq_init(void);
 int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
int n_items);
 
+#if defined(CONFIG_DRIVER_TI_EMAC)  defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel);
+#endif
+
 #endif /* __COMMON_H */
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h 
b/arch/arm/include/asm/arch-davinci/hardware.h
index ef616c1..b95fa97 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -152,6 +152,10 @@ typedef volatile unsigned int *dv_reg_p;
 #define DAVINCI_BOOTCFG_BASE   0x01c14000
 #define JTAG_ID_REG(DAVINCI_BOOTCFG_BASE + 0x18)
 
+#define GPIO_BANK2_REG_DIR_ADDR(DAVINCI_GPIO_BASE + 
0x38)
+#define GPIO_BANK2_REG_OPDATA_ADDR (DAVINCI_GPIO_BASE + 0x3c)
+#define GPIO_BANK2_REG_SET_ADDR(DAVINCI_GPIO_BASE + 
0x40)
+#define GPIO_BANK2_REG_CLR_ADDR(DAVINCI_GPIO_BASE + 
0x44)
 #endif /* CONFIG_SOC_DA8XX */
 
 /* Power and Sleep Controller (PSC) Domains */
diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c
index 36bf693..2d9a64b 100644
--- a/board/davinci/da8xxevm/common.c
+++ b/board/davinci/da8xxevm/common.c
@@ -53,3 +53,17 @@ int da8xx_configure_lpsc_items(const struct lpsc_resource 
*item,
 
return 0;
 }
+
+#if defined(CONFIG_DRIVER_TI_EMAC)  defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel)
+{
+   int val;
+
+   val = readl(davinci_syscfg_regs-cfgchip3);
+   if (mode_sel == 0)
+   val = ~(1  8);
+   else
+   val |= (1  8);
+   writel(val, davinci_syscfg_regs-cfgchip3);
+}
+#endif
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index 0420ad5..a6e2dab 

Re: [U-Boot] [PATCHWORK] 71715 - Not applicable.

[Mike Frysinger]

On Thursday, November 18, 2010 16:31:58 Albert ARIBAUD wrote:
 Yay, my first todo in patchwork! :)
 
 http://patchwork.ozlabs.org/patch/71715/
 
 It was discussed there:
 
 http://www.mail-archive.com/u-boot@lists.denx.de/msg28003.html
 
 AIUI, the discussion was about asm-generic/unaligned.h rather than about
 the patch itself. Personally I think that the patch could have been
 applied, and *then* asm-generic/unaligned.h could have been brought in
 sync with its Linux counterpart.
 
 Anyway this patch requires a rebase now as the whole arch organization
 has moved around. Ergo: not applicable; if the patch is needed, I'd like
 it to be resubmitted based on current master.

it's trivial to rebase the patch yourself.  you're the arm maintainer, and 
this patch is for the core arm.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Albert ARIBAUD]

Le 18/11/2010 22:44, Wolfgang Denk a écrit :
 Dear Sebastien Carlier,

 In message20101117133056.gb23...@safe.home.local  you wrote:

 MPC8xx boards break with long lists of multiple definitions of
 symbols, like that:

 Configuring for FPS860L board...
 lib/libgeneric.o: In function `vsprintf':
 /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of 
 `vsprintf'
 ...

 Have you seen that, too?

 Unfortunately I have not been able to reproduce these errors with the
 toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
 emdebian squeeze packages).  Can you please point me to the toolchain
 you are using?

 Are you sure this doesn't happen with your tool chain?

 I found out why this happens, and I think the effect should be
 independent of the used tool chain:

 For example, in board/tqc/tqm8xx/u-boot.lds we arrange to have the
 environment located in one of the small NOR flash sectors:

 
   53   .text  :
   54   {
   55 /* WARNING - the following is hand-optimized to fit within  */
   56 /* the sector layout of our flash chips!XXX FIXME XXX   */
   57
   58 arch/powerpc/cpu/mpc8xx/start.o (.text)
   59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
   60 common/dlmalloc.o   (.text)
   61 arch/powerpc/lib/ppcstring.o(.text)
   62 lib/vsprintf.o  (.text)
   63 lib/crc32.o (.text)
   64 lib/zlib.o  (.text)
   65 arch/powerpc/lib/cache.o(.text)
   66
   67 . = DEFINED(env_offset) ? env_offset : .;
   68 common/env_embedded.o   (.ppcenv)
   69
   70 *(.text)
   71 *(.got1)
 

 That means, the linker script pulls in certain object files directly.
 Before, when linking with libraries, this was no problem, as the
 linker would pull only (so far) unresolved symbols from the libraries
 specified on the command line.  Now, we include these individual
 object files through the linker script, and then again when specifying
 the library objects on the command line - which necessarily results
 in multiple definition errors.

Are you sure of this? From 
http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics,
 
specifying a file name in the linker file *and* on the command line 
should not lead to a double inclusion of the object file:

When you use a file name which is not an `archive:file' specifier and 
does not contain any wild card characters, the linker will first see if 
you also specified the file name on the linker command line or in an 
INPUT command. If you did not, the linker will attempt to open the file 
as an input file, as though it appeared on the command line.

 Unfortunately I don't know how to solve this yet.  Does anybody know of
 a way how to manually arrange the objects (or symbols) in the linked
 image?


 Best regards,

 Wolfgang Denk

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHWORK] 71715 - Not applicable.

[Albert ARIBAUD]

Le 18/11/2010 23:00, Mike Frysinger a écrit :

 Anyway this patch requires a rebase now as the whole arch organization
 has moved around. Ergo: not applicable; if the patch is needed, I'd like
 it to be resubmitted based on current master.

 it's trivial to rebase the patch yourself.  you're the arm maintainer, and
 this patch is for the core arm.
 -mike

Yes, it is trivial, and yes, I am the arm maintainer (well, technically 
not until the next release is out), and as the arm maintainer I see 
patch which has been left dormant since january without adverse effects 
and without a ping (at least, none that I could see), which makes me 
wonder how strongly it is really wished for; a resubmit will be a sign 
that it is.

Besides, about half the archs do not use asm-generic/unaligned, and half 
do; a resubmit on the list will be the occasion, for example, to discuss 
whether all arches should use it.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message 4ce5a3f1.50...@free.fr you wrote:

58 arch/powerpc/cpu/mpc8xx/start.o (.text)
59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
60 common/dlmalloc.o   (.text)
61 arch/powerpc/lib/ppcstring.o(.text)
62 lib/vsprintf.o  (.text)
63 lib/crc32.o (.text)
64 lib/zlib.o  (.text)
65 arch/powerpc/lib/cache.o(.text)
66
67 . = DEFINED(env_offset) ? env_offset : .;
68 common/env_embedded.o   (.ppcenv)
...
 Are you sure of this? From 
 http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics,
  
 specifying a file name in the linker file *and* on the command line 
 should not lead to a double inclusion of the object file:

I'm sure that I see the errors.

I see two possible reasons: 1) whay you describe is a new feature in
binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the
linker does not realize it because it's actually different file names:
for example, vsprintf() gets included in the linker script directly
through lib/vsprintf.o, and throught he command line as
lib/libgeneric.o == two different file names.

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
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
-- S. Beckett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHWORK] 71715 - Not applicable.

[Mike Frysinger]

On Thursday, November 18, 2010 17:21:49 Albert ARIBAUD wrote:
 Besides, about half the archs do not use asm-generic/unaligned, and half
 do

that's because half the arches implemented unaligned.h whilst only thinking of 
themselves.  the other half benefited from my work of thinking of everyone.

 a resubmit on the list will be the occasion

i dont use/care about arm.  i wrote the patch because i wanted to be nice.  if 
you cant be bothered to clean up arm cruft, then feel free to mark the patch 
as pending due to maintainer laziness.

 for example, to discuss whether all arches should use it.

all arches should use it.  whether the maintainers can be bothered to fix 
their headers is a different question.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Wed, 2010-11-17 at 16:08 -0600, Scott Wood wrote:
 On Wed, 17 Nov 2010 22:40:49 +0100
 Wolfgang Denk w...@denx.de wrote:
 
  Dear Steve Sakoman,
  
  In message aanlktimrfq5+awfdfy_fuetmh=x=xrkazgntk8fis...@mail.gmail.com 
  you wrote:
  
   readenv: offset = 24
   readenv: nand_read failure = -117
   *** Warning - readenv() failed, using default environment
   
   I then immediately tried to use the nand read command to read the same
   block, and it was successful!
  
  Hm... any chance that - for example - your timers are not working
  correctly before relocation (maybe because they try to write to the
  not yet available data segment) ? This could cause timeouts or delays
  to be too short, so the NAND driver is misbehaving?
 
 The NAND driver only works after relocation.
 
 It looks like the problem is that -EUCLEAN is a non-fatal error
 (indicates a correctable ECC error).  The code invoked by the nand
 read command succeeds if nand_read() returns either 0 or -EUCLEAN, but
 readenv() is missing this check.

Changing readenv to use nand_read_skip_bad eliminated the -117 (EUCLEAN) 
failures.

Now I am getting just the -74 (EBADMSG) errors for fw_setenv written 
environments.

It seems that fw_printenv can always read u-boot written environments, but 99.9%
of the time I get a -74 (EBADMSG) error in u-boot for environments written by 
fw_setenv:

NAND read from offset 24 failed -74
*** Warning - readenv() failed, using default environment

If I try to read the environment using the nand read tool I get the same error.

Using fw_printenv always seems to work -- whether u-boot or fw_setenv was the 
writer.

The code generating both errors is in the nand_do_read_ops function in 
nand_base.c:

   if (mtd-ecc_stats.failed - stats.failed)
   return -EBADMSG;

   return  mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
}

I understand that the -EUCLEAN error indicates a correctable ECC error.  What 
does the -EBADMSG error indicate?

This condition doesn't seem to bother the linux driver, but u-boot doesn't like 
it at all!

Steve


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Scott Wood]

On Thu, 18 Nov 2010 16:13:52 -0800
Steve Sakoman st...@sakoman.com wrote:

 The code generating both errors is in the nand_do_read_ops function in 
 nand_base.c:
 
if (mtd-ecc_stats.failed - stats.failed)
return -EBADMSG;
 
return  mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
 }
 
 I understand that the -EUCLEAN error indicates a correctable ECC error.  What 
 does the -EBADMSG error indicate?

An uncorrectable ECC error (or other failure).

 This condition doesn't seem to bother the linux driver, but u-boot doesn't 
 like it at all!

Check whether the ECC layout and code is the same for this driver in
both U-Boot and Linux.

-Scott

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Thu, 2010-11-18 at 18:20 -0600, Scott Wood wrote:
 On Thu, 18 Nov 2010 16:13:52 -0800
 Steve Sakoman st...@sakoman.com wrote:
 
  The code generating both errors is in the nand_do_read_ops function in 
  nand_base.c:
  
 if (mtd-ecc_stats.failed - stats.failed)
 return -EBADMSG;
  
 return  mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
  }
  
  I understand that the -EUCLEAN error indicates a correctable ECC error.  
  What does the -EBADMSG error indicate?
 
 An uncorrectable ECC error (or other failure).
 
  This condition doesn't seem to bother the linux driver, but u-boot doesn't 
  like it at all!
 
 Check whether the ECC layout and code is the same for this driver in
 both U-Boot and Linux.

Since fw_printenv in Linux always can successfully read an environment
written by U-boot (aqs well as those written by fw_setenv), wouldn't
this indicate that they are using the same ECC layout?  If they were
different I would expect that compatibility in both directions would be
broken.

This is not my area of expertise, so perhaps I am just ignorant of how
things work.

Steve


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] AT91RM9200: fix AT91_PMC_MCKR_MDIV_* defines for this CPU

[cla...@gmail.com]

The AT91RM9200 has a different bit assignment in PMC MCKR register than
it's successors (verified by Atmel's manuals on AT91RM9200 and AT91SAM926).
AT91RM9200 supports the additional divider of 3.

Signed-off-by: Guido Classen cla...@gmail.com

--- u-boot-git/arch/arm/include/asm/arch-at91/at91_pmc.h2010-11-12 
18:30:31.0 +0100
+++ u-boot-ccm2200/arch/arm/include/asm/arch-at91/at91_pmc.h2010-11-16 
22:00:56.0 +0100
@@ -91,10 +91,19 @@
  #define AT91_PMC_MCKR_PRES_64 0x0018
  #define AT91_PMC_MCKR_PRES_MASK   0x001C

+#ifdef CONFIG_AT91RM9200
+#define AT91_PMC_MCKR_MDIV_1   0x
+#define AT91_PMC_MCKR_MDIV_2   0x0100
+#define AT91_PMC_MCKR_MDIV_3   0x0200
+#define AT91_PMC_MCKR_MDIV_4   0x0300
+#define AT91_PMC_MCKR_MDIV_MASK0x0300
+#else
  #define AT91_PMC_MCKR_MDIV_1  0x
  #define AT91_PMC_MCKR_MDIV_2  0x0100
  #define AT91_PMC_MCKR_MDIV_4  0x0200
  #define AT91_PMC_MCKR_MDIV_MASK   0x0300
+#endif

  #define AT91_PMC_MCKR_PLLADIV_1   0x1000
  #define AT91_PMC_MCKR_PLLADIV_2   0x2000
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/1] imx: Get fec mac address from fuse

[Jason Liu]

Hi, Stefano,

2010/11/18 Stefano Babic sba...@denx.de:
 On 11/18/2010 12:49 PM, Jason Liu wrote:
 The patch is to support getting FEC MAC address from fuse bank.

 Signed-off-by: Jason Liu r64...@freescale.com


 Hi Jason,

 I applied your patch and I tested on a i.MX27 Lite board. The result
 does not seem correct. According to the manual, the mac address is store
 at address 0x10028814. Rather there is no stored MAC at this address on
 my board, but your patch read the MAC from address 0x10028810 (I traced
 the address of fuse-mac_addr).

 The reported address is what we can see at 0x10028810 (Word 4 of
 fusebank 0):

 md 0x10028804
 10028804: 0020 0081 0040 0010     ...@...
 10028814:        

 And u-boot reports :
 Address in SROM is         00:00:00:00:00:10
 Address in environment is  00:aa:dd:cc:11:22

 It seems you read at a wrong address.

I think you are right. I did not have the mx27 board to do test.
Thanks for test.

I only test it on mx51babbage board, the following is the output:

Net:   got MAC address from fuse: 00:04:9f:00:f7:78
which is the same as the MAC address programmed on the board.


 Best regards,
 Stefano Babic

 --
 =
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
 =
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Thu, Nov 18, 2010 at 4:20 PM, Scott Wood scottw...@freescale.com wrote:
 On Thu, 18 Nov 2010 16:13:52 -0800
 Steve Sakoman st...@sakoman.com wrote:

 The code generating both errors is in the nand_do_read_ops function in 
 nand_base.c:

        if (mtd-ecc_stats.failed - stats.failed)
                return -EBADMSG;

        return  mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
 }

 I understand that the -EUCLEAN error indicates a correctable ECC error.  
 What does the -EBADMSG error indicate?

 An uncorrectable ECC error (or other failure).

 This condition doesn't seem to bother the linux driver, but u-boot doesn't 
 like it at all!

 Check whether the ECC layout and code is the same for this driver in
 both U-Boot and Linux.

Well, the mystery is solved.

The strange behavior was a combination of the -EUCLEAN issue in u-boot
and the following bizarre bug that crept into the Linux OMAP NAND
driver in 2.6.26:

http://article.gmane.org/gmane.linux.ports.arm.omap/46545

I will submit a patch to deal with the u-boot issue tomorrow, and it
seems that a fix is already queued for Linux 2.6.37.

Thanks to Scott Wood for helping with the -EUCLEAN issue and Scott
Ellis for noticing that what might be the same issue was being
discussed on both the u-boot and linux lists today.

Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

[Macpaul Lin]

This patch add generic header files support for nds32 architecture.
Cache, ptregs, data type and other definitions are included.

NDS32 is a new 32-bit RISC architecture invented by andestech.com.

NDS32 also provide N9, N10, N12 different CPU core families for soft-core
and hard-core SoC design.

Note:
  Empty headers such as config.h, memory.h, processor.h are necessary for
  compiling some device drivers.
  Otherwise those drivers won't be build.

Signed-off-by: Macpaul Lin macp...@andestech.com
---
Changes for v1:
   - First commit of nds32 arch to u-boot, add SoC ag101, adp-ag101 into u-boot.
Changes for v2:
   - Clean up coding style.
   - Reorganize code of SoC ag101 from a320.
Changes for v3:
   - Clean up coding style.
   - Reordering and reduce the size and patches.
Changes for v4:
   - Clear up for Patch v3.
   - Remove code that haven't used in the system.
   - Commit header files only for easier code review.
Changes for v5:
   - Update changes against the change after master tree (v2010.12-rc1).
   - Fix upper case definitions in cache.h.
   - Support GD_FLG_ENV_READY and env_buf vars in nds32 global_data.h.
   - Add readsb, writesb functions into io.h.

 arch/nds32/include/asm/bitops.h   |  150 
 arch/nds32/include/asm/byteorder.h|   36 +++
 arch/nds32/include/asm/cache.h|   51 
 arch/nds32/include/asm/config.h   |   26 ++
 arch/nds32/include/asm/global_data.h  |   82 +++
 arch/nds32/include/asm/io.h   |  408 +
 arch/nds32/include/asm/mach-types.h   |   29 +++
 arch/nds32/include/asm/memory.h   |   19 ++
 arch/nds32/include/asm/posix_types.h  |   84 +++
 arch/nds32/include/asm/processor.h|   25 ++
 arch/nds32/include/asm/ptrace.h   |   22 ++
 arch/nds32/include/asm/ptregs.h   |   82 +++
 arch/nds32/include/asm/string.h   |   57 +
 arch/nds32/include/asm/types.h|   67 ++
 arch/nds32/include/asm/u-boot-nds32.h |   47 
 arch/nds32/include/asm/u-boot.h   |   69 ++
 arch/nds32/include/asm/unaligned.h|   31 +++
 17 files changed, 1285 insertions(+), 0 deletions(-)
 create mode 100644 arch/nds32/include/asm/bitops.h
 create mode 100644 arch/nds32/include/asm/byteorder.h
 create mode 100644 arch/nds32/include/asm/cache.h
 create mode 100644 arch/nds32/include/asm/config.h
 create mode 100644 arch/nds32/include/asm/global_data.h
 create mode 100644 arch/nds32/include/asm/io.h
 create mode 100644 arch/nds32/include/asm/mach-types.h
 create mode 100644 arch/nds32/include/asm/memory.h
 create mode 100644 arch/nds32/include/asm/posix_types.h
 create mode 100644 arch/nds32/include/asm/processor.h
 create mode 100644 arch/nds32/include/asm/ptrace.h
 create mode 100644 arch/nds32/include/asm/ptregs.h
 create mode 100644 arch/nds32/include/asm/string.h
 create mode 100644 arch/nds32/include/asm/types.h
 create mode 100644 arch/nds32/include/asm/u-boot-nds32.h
 create mode 100644 arch/nds32/include/asm/u-boot.h
 create mode 100644 arch/nds32/include/asm/unaligned.h

diff --git a/arch/nds32/include/asm/bitops.h b/arch/nds32/include/asm/bitops.h
new file mode 100644
index 000..f658a03
--- /dev/null
+++ b/arch/nds32/include/asm/bitops.h
@@ -0,0 +1,150 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ *
+ * Copyright (C) 2010 Andes Technology Corporation
+ * Shawn Lin, Andes Technology Corporation nobuh...@andestech.com
+ *
+ * bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
+ *
+ * Please note that the code in this file should never be included
+ * from user space.  Many of these are not implemented in assembler
+ * since they would be too costly.  Also, they require priviledged
+ * instructions (which are not available from user mode) to ensure
+ * that they are atomic.
+ */
+
+#ifndef __ASM_NDS_BITOPS_H
+#define __ASM_NDS_BITOPS_H
+
+#ifdef __KERNEL__
+
+#define smp_mb__before_clear_bit() do { } while (0)
+#define smp_mb__after_clear_bit()  do { } while (0)
+
+/*
+ * Function prototypes to keep gcc -Wall happy.
+ */
+extern void set_bit(int nr, volatile void * addr);
+
+static inline void __set_bit(int nr, volatile void *addr)
+{
+   ((unsigned char *) addr)[nr  3] |= (1U  (nr  7));
+}
+
+extern void clear_bit(int nr, volatile void * addr);
+
+static inline void __clear_bit(int nr, volatile void *addr)
+{
+   ((unsigned char *) addr)[nr  3] = ~(1U  (nr  7));
+}
+
+extern void change_bit(int nr, volatile void * addr);
+
+static inline void __change_bit(int nr, volatile void *addr)
+{
+   ((unsigned char *) addr)[nr  3] ^= (1U  (nr  7));
+}
+
+extern int test_and_set_bit(int nr, volatile void * addr);
+
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+   unsigned int mask = 1  (nr  7);
+   unsigned int oldval;
+
+   oldval = ((unsigned char *) addr)[nr  3];
+   ((unsigned char *) addr)[nr  3] = oldval | mask;
+   return oldval  

Re: [U-Boot] [PATCH] revert tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode

[Li Yang]

snip

 My understanding is that the SGMII link is always at 1000Mbps speed -
 see figure 1 from the app note.  Additionally look at figure 3.  My
 understand from it, and the app note's text is that SGMII
 auto-negotiation doesn't really occur - its just passing the PHY-side
 auto-negotiation results to the Freescale MAC, which software then
 configures.  I'm not sure what the purpose of the SGMII
 auto-negotiation is - its not really auto- negotiating and the same
 information can be read from the PHY via its MDIO interface, which is
what is happening on X-ES boards currently.

 I guess the point is to save MDIO signals to the external PHY and read
 the negotiated result from the internal TBI PHY.

Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO interface
to their PHYs'?  I've never heard of a board that doesn't, and would guess
the tsec driver in U-Boot requires a PHY to be accessible via MDIO to use
the corresponding network interface.

I'm not sure which specific silicon omits the MDIO signal.  But quoting from
the app note you mentioned:

 Depending on the PowerQUICC part used, some eTSEC’s may or may not
provide an external
MDIO management interface. However, the TBI block for each eTSEC is
associated in a one to one
manner, even if that eTSEC does not have an external MDIO connection.

The auto-negotiation mechanism between TBI PHY and real PHY does make
it possible
to save external MDIO signals if only SGMII interface is used.


I can forward you the email thread about SGMII auto-negotiation with
Freescale's FAE off-list if you'd like as well.

Yes, please.  Thanks

- Leo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHWORK] 71715 - Not applicable.

[Albert ARIBAUD]

Le 19/11/2010 00:13, Mike Frysinger a écrit :
 On Thursday, November 18, 2010 17:21:49 Albert ARIBAUD wrote:
 Besides, about half the archs do not use asm-generic/unaligned, and half
 do

 that's because half the arches implemented unaligned.h whilst only thinking of
 themselves.  the other half benefited from my work of thinking of everyone.

 a resubmit on the list will be the occasion

 i dont use/care about arm.  i wrote the patch because i wanted to be nice.  if
 you cant be bothered to clean up arm cruft, then feel free to mark the patch
 as pending due to maintainer laziness.

 for example, to discuss whether all arches should use it.

 all arches should use it.  whether the maintainers can be bothered to fix
 their headers is a different question.
 -mike

My question was about the technical merits of the patch: why should all 
arches use it? What does it improve at a performance, maintenability, or 
other technical level ?

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/2] nds32: add NDS32 support into common header file

[Macpaul Lin]

Add NDS32 support into common header file.

Signed-off-by: Macpaul Lin macp...@andestech.com
---
Changes for v2:
   - This files has no change.

 include/common.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/common.h b/include/common.h
index 189ad81..d7c452a 100644
--- a/include/common.h
+++ b/include/common.h
@@ -273,6 +273,10 @@ intsetenv   (char *, char *);
 #ifdef CONFIG_I386 /* x86 version to be fixed! */
 # include asm/u-boot-i386.h
 #endif /* CONFIG_I386 */
+#ifdef CONFIG_NDS32
+# include asm/mach-types.h
+# include asm/u-boot-nds32.h /* NDS32 version to be fixed! */
+#endif /* CONFIG_NDS32 */
 
 #ifdef CONFIG_AUTO_COMPLETE
 int env_complete(char *var, int maxv, char *cmdv[], int maxsz, char *buf);
-- 
1.7.3.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] nds32/Core_N1213: add N1213 cpu core support for NDS32 arch

[Macpaul Lin]

Add N1213 cpu core support for NDS32 arch.
Included lowlevel_init procedures, and linker scripts.

NDS32 Core N1213 has the following features.

Core:
 - 16-/32-bit mixable instruction format
 - 32 general-purpose 32-bit registers
 - 8-stage pipeline
 - Dynamic branch prediction
 - 32/64/128/256 BTB
 - Return address stack (RAS)
 - Vector interrupts for internal/external
 - 3 HW-level nested interruptions
 - User and super-user mode support
 - Memory-mapped I/O
 - Address space up to 4GB

Memory Management Unit:
 - TLB
 - Optional hardware page table walker
 - Two groups of page size support

Memory Subsystem:
 - I  D cache
 - I  D local memory (LM)

Bus Interface:
 - Synchronous/Asynchronous AHB bus: 0, 1 or 2 ports

Note:
1. start.S will start up the CPU core at first,
 then jump to SoC dependent lowlevel_init.S and
 watchdog.S to configure peripheral devices.

2. Replace old TEXT_BASE with new CONFIG_SYS_TEXT_BASE
 into Start.S

Signed-off-by: Macpaul Lin macp...@andestech.com
---
Changes for v2:
   - Add descriptions for other SoC used core N1213 to 
 organize their lowlevel_init.S and start.S.
   - Replace old TEXT_BASE with new CONFIG_SYS_TEXT_BASE
 against the master tree.
   - Fix upper case varible declartions used in asm/cache.h.

 arch/nds32/cpu/n1213/Makefile   |   50 +
 arch/nds32/cpu/n1213/start.S|  449 +++
 arch/nds32/cpu/n1213/u-boot.lds |   68 ++
 3 files changed, 567 insertions(+), 0 deletions(-)
 create mode 100644 arch/nds32/cpu/n1213/Makefile
 create mode 100644 arch/nds32/cpu/n1213/start.S
 create mode 100644 arch/nds32/cpu/n1213/u-boot.lds

diff --git a/arch/nds32/cpu/n1213/Makefile b/arch/nds32/cpu/n1213/Makefile
new file mode 100644
index 000..3b81924
--- /dev/null
+++ b/arch/nds32/cpu/n1213/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2010 Andes Technology Corporation
+# Shawn Lin, Andes Technology Corporation nobuh...@andestech.com
+# Macpaul Lin, Andes Technology Corporation macp...@andestech.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(CPU).o
+
+START  = start.o
+
+SRCS   := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+START  := $(addprefix $(obj),$(START))
+
+all:   $(obj).depend $(START) $(LIB)
+
+$(LIB):$(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/nds32/cpu/n1213/start.S b/arch/nds32/cpu/n1213/start.S
new file mode 100644
index 000..9549fb2
--- /dev/null
+++ b/arch/nds32/cpu/n1213/start.S
@@ -0,0 +1,449 @@
+/*
+ * Andesboot - Startup Code for Whitiger core
+ *
+ * Copyright (C) 2006  Andes Technology Corporation
+ * Copyright (C) 2006  Shawn Lin nobuh...@andestech.com
+ * Copyright (C) 2010  Macpaul macp...@andestech.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include common.h
+#include version.h
+
+!
+! Jump vector table for EVIC mode
+!
+
+#define 

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Stefano Babic]

On 11/18/2010 10:50 PM, Ben Gardiner wrote:
 Hi Stefano,


Hi Ben,

 Sorry for the long delay.

No problem at all !

 The problem was that I was applying my RMII patch on top of Sugosh's
 patches without your SPI flash patches underneath. Another RMII
 version patch is coming.
 
 Still, there were some merge conflicts due to the fact that you were
 basing your ea20 patches off of only 1 of Sugosh's patches.

Right. Sugosh pointed me out to this patch and I have not seen that the
patches for the hawkboard change something in common code, too.

 
 You didn't have Add board support for hawkboard and Remove
 board_init_f function from nand_boot.c applied.
 
 I hope you don't mind that I merged them and pushed the result to
 branch testing-ea20-plus of
 git://github.com/BenGardiner/u-boot-bg.git . I hope that saves us some
 time.

Thank you for doing that - we have already a working tree !

 
 I will be sending a V4 of the RMII patch -- as can be seen from that
 series -- to the list. I hope you can use the merged patches in the
 branch I pushed to send your updated patches.

I will test today on ea20, but it seems all what I have to do is only to
send them to the ML - thank you again for your work !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Albert ARIBAUD]

Le 18/11/2010 23:33, Wolfgang Denk a écrit :
 Dear Albert ARIBAUD,

 In message4ce5a3f1.50...@free.fr  you wrote:

58 arch/powerpc/cpu/mpc8xx/start.o (.text)
59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
60 common/dlmalloc.o   (.text)
61 arch/powerpc/lib/ppcstring.o(.text)
62 lib/vsprintf.o  (.text)
63 lib/crc32.o (.text)
64 lib/zlib.o  (.text)
65 arch/powerpc/lib/cache.o(.text)
66
67 . = DEFINED(env_offset) ? env_offset : .;
68 common/env_embedded.o   (.ppcenv)
 
 Are you sure of this? From
 http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics,
 specifying a file name in the linker file *and* on the command line
 should not lead to a double inclusion of the object file:

 I'm sure that I see the errors.

 I see two possible reasons: 1) whay you describe is a new feature in
 binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the
 linker does not realize it because it's actually different file names:
 for example, vsprintf() gets included in the linker script directly
 through lib/vsprintf.o, and throught he command line as
 lib/libgeneric.o ==  two different file names.

Most probably 2); mentioning a file in the linker script either with or 
without mentioning it on the command line has certainly been done for 
some time, so I doubt the feature is new; and certainly the doc is about 
files, not symbols in different files.

And, to get back to possible solutions, I don't know that the linker can 
map selected symbols onto specific regions; it can only place whole 
object files.

The simplest, though not cleanest, way I can think of is to put 
conditionals to not compile vsprintf() in lib/generic, and set those 
conditions from the board config file -- and same for anything else. 
Ugly, but it will work.

A second solution, a bit more intrusive, would be to split lib/generic 
in two files; a small one which could be mapped in the small area, and 
the rest, which would map with the rest of the image.

 Best regards,

 Wolfgang Denk


Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/1] imx: Get fec mac address from fuse

[Jason Liu]

Hi, Stefano,

2010/11/19 Jason Liu liu.h.ja...@gmail.com:
 Hi, Stefano,

 2010/11/18 Stefano Babic sba...@denx.de:
 On 11/18/2010 12:49 PM, Jason Liu wrote:
 The patch is to support getting FEC MAC address from fuse bank.

 Signed-off-by: Jason Liu r64...@freescale.com


 Hi Jason,

 I applied your patch and I tested on a i.MX27 Lite board. The result
 does not seem correct. According to the manual, the mac address is store
 at address 0x10028814. Rather there is no stored MAC at this address on
 my board, but your patch read the MAC from address 0x10028810 (I traced
 the address of fuse-mac_addr).

 The reported address is what we can see at 0x10028810 (Word 4 of
 fusebank 0):

 md 0x10028804
 10028804: 0020 0081 0040 0010     ...@...
 10028814:        

 And u-boot reports :
 Address in SROM is         00:00:00:00:00:10
 Address in environment is  00:aa:dd:cc:11:22

 It seems you read at a wrong address.

 I think you are right. I did not have the mx27 board to do test.
 Thanks for test.

 I only test it on mx51babbage board, the following is the output:

 Net:   got MAC address from fuse: 00:04:9f:00:f7:78
 which is the same as the MAC address programmed on the board.


Do you have any other comments about this patch?

BR,
Jason



 Best regards,
 Stefano Babic

 --
 =
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
 =
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHWORK] 71715 - Not applicable.

[Mike Frysinger]

On Friday, November 19, 2010 00:59:47 Albert ARIBAUD wrote:
 Le 19/11/2010 00:13, Mike Frysinger a écrit :
  On Thursday, November 18, 2010 17:21:49 Albert ARIBAUD wrote:
  Besides, about half the archs do not use asm-generic/unaligned, and half
  do
  
  that's because half the arches implemented unaligned.h whilst only
  thinking of themselves.  the other half benefited from my work of
  thinking of everyone.
  
  a resubmit on the list will be the occasion
  
  i dont use/care about arm.  i wrote the patch because i wanted to be
  nice.  if you cant be bothered to clean up arm cruft, then feel free to
  mark the patch as pending due to maintainer laziness.
  
  for example, to discuss whether all arches should use it.
  
  all arches should use it.  whether the maintainers can be bothered to fix
  their headers is a different question.
 
 My question was about the technical merits of the patch: why should all
 arches use it? What does it improve at a performance, maintenability, or
 other technical level ?

obviously maintenance is improved since only one header needs to be maintained 
and it isnt an arm one
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Sughosh Ganu]

hi Ben,

On Thu Nov 18, 2010 at 04:50:30PM -0500, Ben Gardiner wrote:

 Davinci: add support for the ea20 board -- Stefano Babic
 sba...@denx.de 2010-11-17 11:09:05 +0100
 Davinci 8xx: Move common functions to share code -- Stefano Babic
 sba...@denx.de 2010-11-17 11:09:04 +0100
 [PATCH V4][NEXT] da850: Add RMII support for EMAC -- Sudhakar
 Rajashekhara sudhakar@ti.com 2010-11-18 09:59:37 -0500
 Add board support for hawkboard -- Sughosh Ganu
 urwithsugh...@gmail.com 2010-11-01 23:30:34 +0530
 Remove board_init_f function from nand_boot.c -- Sughosh Ganu
 urwithsugh...@gmail.com 2010-11-01 23:29:27 +0530
 Move and rename common headers from under board/davinci. -- Sughosh
 Ganu urwithsugh...@gmail.com 2010-11-01 23:28:38 +0530
 da850: Enable SPI Flash -- Stefano Babic sba...@denx.de 2010-11-11
 15:38:02 +0100
 da8xx: Add cpu_is_da8xx macros -- Sudhakar Rajashekhara
 sudhakar@ti.com 2010-11-11 15:38:01 +0100
 Net: clarify board/cpu_eth_init calls -- Ben Warren
 biggerbadder...@gmail.com 2010-08-31 23:05:04 -0700
 
 You didn't have Add board support for hawkboard and Remove
 board_init_f function from nand_boot.c applied.
 
 I hope you don't mind that I merged them and pushed the result to
 branch testing-ea20-plus of
 git://github.com/BenGardiner/u-boot-bg.git . I hope that saves us some
 time.

  Thanks for all the work. I will be able to test these changes only
  next week. I will test them on hawkboard and update you. Thanks.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/1] imx: Get fec mac address from fuse

[Stefano Babic]

On 11/19/2010 07:44 AM, Jason Liu wrote:
 I think you are right. I did not have the mx27 board to do test.
 Thanks for test.

 I only test it on mx51babbage board, the following is the output:

 Net:   got MAC address from fuse: 00:04:9f:00:f7:78
 which is the same as the MAC address programmed on the board.
 
 
 Do you have any other comments about this patch?

As I have not seen any other comments in the ML, I have tried to apply
the patch and to test myself. From my point of view we have to be sure
that the patch is working for all supported processors, and I can test
it for i.MX27. As you already test it on i.MX51, can you test it on
i.MX25 ? Or at least check with tracing if the address is correct for
this processor, too ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Sebastien Carlier]

Dear Wolfgang,

On 2010-11-18 22:44:48, Wolfgang Denk wrote:
  
  Unfortunately I have not been able to reproduce these errors with the
  toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
  emdebian squeeze packages).  Can you please point me to the toolchain
  you are using?
 
 Are you sure this doesn't happen with your tool chain?

Weird, I tried the FPS860L configuration again and now I can see these
errors with my toolchain.  Not sure what I did wrong the first time
around.

 I found out why this happens, and I think the effect should be
 independent of the used tool chain:

Great!  I have been quite busy for the last couple days, sorry I hadn't
been able to check it out yet.

 Unfortunately I don't know how to solve this yet.  Does anybody know of
 a way how to manually arrange the objects (or symbols) in the linked
 image?

Sounds difficult once object files have been linked into a new partial
object...  I do not know if it would be practical to use sections
instead, it depends what needs to be achieved.

It looks like the purpose is to optimally fill a flash sector with
definitions, is this accurate?  Why is this needed?  Beside the obvious
(reset vectors, startup code), is there any reason to prefer any given
definition to go into the sector being filled?

Regards,
-- 
Sebastien
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot