[U-Boot] [PATCH] OMAP3: add CM-T35 board

2010-11-23 Thread Mike Rapoport
This patch adds support for CM-T35 board

Signed-off-by: Mike Rapoport 
---
 MAINTAINERS  |4 +
 MAKEALL  |1 +
 board/cm_t35/Makefile|   47 ++
 board/cm_t35/cm_t35.c|  222 
 board/cm_t35/cm_t35.h|  184 +++
 board/cm_t35/config.mk   |   30 
 boards.cfg   |1 +
 doc/README.omap3 |   16 ++-
 include/configs/cm_t35.h |  364 ++
 9 files changed, 867 insertions(+), 2 deletions(-)
 create mode 100644 board/cm_t35/Makefile
 create mode 100644 board/cm_t35/cm_t35.c
 create mode 100644 board/cm_t35/cm_t35.h
 create mode 100644 board/cm_t35/config.mk
 create mode 100644 include/configs/cm_t35.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9258cb1..b44b843 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -750,6 +750,10 @@ Stelian Pop 
at91sam9263ek   ARM926EJS (AT91SAM9263 SoC)
at91sam9rlekARM926EJS (AT91SAM9RL SoC)
 
+Mike Rapoport 
+
+   cm_t35  ARM ARMV7 (OMAP3xx SoC)
+
 Tom Rix 
 
omap3_zoom2 ARM ARMV7 (OMAP3xx SoC)
diff --git a/MAKEALL b/MAKEALL
index c54c6e8..e0fe12f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -412,6 +412,7 @@ LIST_ARM11="\
 LIST_ARMV7="   \
am3517_evm  \
ca9x4_ct_vxp\
+   cm_t35  \
devkit8000  \
igep0020\
igep0030\
diff --git a/board/cm_t35/Makefile b/board/cm_t35/Makefile
new file mode 100644
index 000..320a817
--- /dev/null
+++ b/board/cm_t35/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# 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  := cm_t35.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
new file mode 100644
index 000..21e8762
--- /dev/null
+++ b/board/cm_t35/cm_t35.c
@@ -0,0 +1,222 @@
+/*
+ * (C) Copyright 2010
+ * CompuLab, Ltd. 
+ *
+ * Author: Mike Rapoport 
+ *
+ * Derived from omap3evm and Beagle Board by
+ * Manikandan Pillai 
+ * Richard Woodruff 
+ * Syed Mohammed Khasim 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cm_t35.h"
+
+static u32 gpmc_net_config[GPMC_MAX_REG] = {
+   NET_GPMC_CONFIG1,
+   NET_GPMC_CONFIG2,
+   NET_GPMC_CONFIG3,
+   NET_GPMC_CONFIG4,
+   NET_GPMC_CONFIG5,
+   NET_GPMC_CONFIG6,
+   0
+};
+
+static u32 gpmc_nand_config[GPMC_MAX_REG] = {
+   SMNAND_GPMC_CONFIG1,
+   SMNAND_GPMC_CONFIG2,
+   SMNAND_GPMC_CONFIG3,
+   SMNAND_GPMC_CONFIG4,
+   SMNAND_GPMC_CONFIG5,
+   SMNAND_GPMC_CONFIG6,
+   0,
+};
+
+/*
+ * Routine: board_init
+ * Description: Early hardware init.
+ */
+int board_init(void)
+{
+   DECLARE_GLOBAL_DATA_PTR;
+
+   gpmc_init

Re: [U-Boot] [PATCH] ARM: S3C64XX: fix clock setup

2010-11-23 Thread Minkyu Kang
Dear Darius Augulis,

On 23 November 2010 02:44, Darius Augulis  wrote:
> Hi,
>
> On 11/22/2010 10:48 AM, Minkyu Kang wrote:
>>
>> Dear Darius Augulis,
>>
>> On 19 November 2010 17:54, Darius Augulis
>>  wrote:
>>>
>>> Hi,
>>>
>>> On Fri, Nov 19, 2010 at 10:32 AM, Minkyu Kang  wrote:

 Dear Darius Augulis,

 On 13 November 2010 03:05, Darius Augulis
  wrote:
>
> Fix pll divider values to standard ones described
> in "S3C6410X RISC Microprocessor User's Manual,
> Revision 1.20", p. 3-21.
>
> Signed-off-by: Darius Augulis
> ---
>  arch/arm/include/asm/arch-s3c64xx/s3c6400.h |   17 ++---
>  1 files changed, 6 insertions(+), 11 deletions(-)
>

 Hm, no..
 Please consider s3c6400.
 Those values are fit with s3c6400.
>>>
>>> does s3c6400 have different clock controller compared to s3c6410?
>>> I have only old manual of s3c6400 and it has the same equation for pll
>>> clock setting.
>>> Please take a look into arch/arm/cpu/arm1176/s3c64xx/speed.c. There
>>> are common functions for both CPU's and
>>> they work ok. So i guess my patch should not break s3c6400 operation.
>>
>> According to the TRM...
>
> what does this abbreviation mean?
>
>> Equations are same. but, recommended values are different.
>
> you are wrong. There is table in s3c6400 manual, but it doesn't contain
> recommended values, only examples how to calculate. Please find default
> values in APLL_CON, MPLL_CON and EPLL_CON0 registers. After reset, default
> frequency of APLL/MPLL for both s3c6400 and s3c6410 are 400MHz/133MHz
> respectively. But values in table in s3c6400 manual do not fit default
> register values for these frequencies. And recommended values in s3c6410
> manual do. Therefore I suggest to use values from s3c6410 manual.

It's not clear.
I didn't said that your patch is wrong.
I just asked you please consider s3c6400.
If you or someone else do test your patch on s3c6400 then I'll accept
your patch.
Or, if you separate setup values from s3c6400 then I'll accept your patch.
In this case, when somebody test your patch, then we can share values
between s3c6400 and s3c6410.

>
>> Your patch is no guarantee with s3c6400.
>> Did you tested with s3c6400?
>
> no. please see next comment below.
>
>>
>>> Btw, we don't have any working s3c6400 board in main line and it seems
>>> nobody is interested to have one.
>>
>> We have the SMDK6400.
>
> you are wrong there again. it does not compile at all. for a long time
> enough.

So we should drop this board?
No. I don't think so.
We (me or you or someone else) must fix it.

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] MACHINE ID

2010-11-23 Thread Bedia, Vaibhav
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On 
Behalf Of Marek Vasut
Sent: Tuesday, November 23, 2010 7:49 AM
To: linux-...@lists.infradead.org
Cc: u-boot@lists.denx.de; hong zhang; Oliver Schneidewind
Subject: Re: [U-Boot] MACHINE ID

On Sunday 21 November 2010 07:47:07 hong zhang wrote:
> --- On Sat, 11/20/10, Oliver Schneidewind  wrote:
> > From: Oliver Schneidewind 
> > Subject: Re: MACHINE ID
> > To: linux-...@lists.infradead.org
> > Date: Saturday, November 20, 2010, 1:58 PM
> > On 19.11.2010 23:40, Russell King -
> > 
> > ARM Linux wrote:
> > > On Fri, Nov 19, 2010 at 01:16:48PM -0800, hong zhang
> > 
> > wrote:
> > >   
> > >
> > >> Uncompressing Linux... done, booting the kernel.
> > >> 
> > >> Error: unrecognized/unsupported machine ID (r1 =
> > 
> > 0x07d9).
> > 
> > >> Available machine support:
> > >> 
> > >> ID (hex)NAME
> > >> 0af0ti8168evm
> > >> 
> > >> Please check your kernel config and/or
> > 
> > bootloader.
> > 

Hi,

This error is due to an incorrect machid being passed to the kernel.

This can be fixed using the following commands:

TI8168_EVM# setenv machid af0
TI8168_EVM# saveenv
TI8168_EVM# reset

Next time the EVM boots, correct machid will be passed to the kernel and this 
issue will go away.

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


[U-Boot] [rft 45] : real estate agents optin e mail marketing list

2010-11-23 Thread manzanita
100% optin lists, Unlimited use rights
Special List Pricing only until Friday:


[ HEALTHCARE ]
Any 4 lists below $319 - Individual List Price: $115 ea

* Complete US Physicians Database
* Chiropractic Doctors in the USA
* American Holistic Medicine Providers/Clinics
* General Dentists in the USA
* Dentists with Specialties 
* American Veterinarians & Veterinary Clinics
* US Hospitals 
* Nursing Homes int the US 
* Pharmaceutical Company Employees
* Physical/Occupational Therapy Clinics and Therapists in the US
* Oncology Physicians in the US
* US Surgery Centers
* Massage Therapists/Therapy Clinics in America
* Acupuncturists/clinics in the US
* Medical Equipment Suppliers(USA)
* Mental Health Counselors (USA)
* Optometrists/Clinics (USA)
* Psychologists (USA)

[ BUSINESS LISTS ]
Any 3 lists below: $329 - Individual lists: $129 ea

* Hotels in the USA
* Realtors in the USA 
* USA Business Database 
* Manufacturer Database (USA)
* Financial Planner Database (USA)
* Finance & Professionals Database (USA)
* Insurance Agents (USA)
* Canadian Businesses
* United Kingdom Business Database
* Media Outlet Contacts (USA)

[ CONSUMER LISTS ]
$105 each

* USA Consumer Database 
* Credit Inquiries Database (USA)
* American Homeowners

[ PROFESSIONALS LISTS ]
$115 each

* USA Lawyers Database 
* Criminal Attorneys in the US


Contact me by email at this address for counts, breakdowns and sample 
spreadsheets: morele...@gmx.com

Should your email be returned, please call 1-206-339-1860 instead.

  




Send us an email to forgetmyem...@gmx.com we will discontinue from the list
  





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


[U-Boot] Mathematics operation on uboot variables

2010-11-23 Thread Eran Y

Hi

Is there any way to use mathematics operation on uboot environment or  uboot
local variables?
since $varA+$varB and $(varA+varB) just save the string. 
-- 
View this message in context: 
http://old.nabble.com/Mathematics-operation-on-uboot-variables-tp30283797p30283797.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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


Re: [U-Boot] [PATCH 7/7] 4xx: Cleanup for partial linking and --gc-sections

2010-11-23 Thread Stefan Roese
Hi Wolfgang,

On Sunday 21 November 2010 22:03:40 Wolfgang Denk wrote:
> This commit adapts 4xx boards for partial linking with --gc-sections.

Thanks. One comment below.


 
> diff --git a/arch/powerpc/cpu/ppc4xx/Makefile
> b/arch/powerpc/cpu/ppc4xx/Makefile index d97ca20..93ebf89 100644
> --- a/arch/powerpc/cpu/ppc4xx/Makefile
> +++ b/arch/powerpc/cpu/ppc4xx/Makefile
> @@ -37,9 +37,9 @@ COBJS   := 40x_spd_sdram.o
>  ifndef CONFIG_NAND_SPL
>  ifndef CONFIG_NAND_U_BOOT
>  COBJS+= 44x_spd_ddr.o
> +COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
>  endif
>  endif
> -COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o

This change introduces the problem with the kilauea/haleakala NAND booting 
images. Yes, I am aware that without this change, canyonlands_nand fails to 
build. I noticed this too right now. I'll send another patch to fix this 
canyonlands_nand build problem shortly.

Cheers,
Stefan

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


[U-Boot] [PATCH] ppc4xx: Fix build problems of IBM DDR2 NAND booting targets

2010-11-23 Thread Stefan Roese
This change is needed to compile the PPC4xx NAND booting targets
equipped with the IBM DDR2 SDRAM controller.

Signed-off-by: Stefan Roese 
Cc: Wolfgang Denk 
---
Wolfgang, this patch is needed to build the 44x NAND booting targets.
Its based on top of your patchset "[PATCH 0/7] Address partial linking
issues". How should we best handle these patches to make this git
bisectable? Feel free to squash this patch into your patches to make
this easier.

Thanks,
Stefan

 arch/powerpc/cpu/ppc4xx/Makefile |2 +-
 board/amcc/canyonlands/canyonlands.c |   12 
 2 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/cpu/ppc4xx/Makefile b/arch/powerpc/cpu/ppc4xx/Makefile
index 93ebf89..d97ca20 100644
--- a/arch/powerpc/cpu/ppc4xx/Makefile
+++ b/arch/powerpc/cpu/ppc4xx/Makefile
@@ -37,9 +37,9 @@ COBJS := 40x_spd_sdram.o
 ifndef CONFIG_NAND_SPL
 ifndef CONFIG_NAND_U_BOOT
 COBJS  += 44x_spd_ddr.o
-COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
 endif
 endif
+COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
 COBJS-$(CONFIG_PPC4xx_DDR_AUTOCALIBRATION) += 4xx_ibm_ddr2_autocalib.o
 COBJS  += 4xx_pci.o
 COBJS  += 4xx_pcie.o
diff --git a/board/amcc/canyonlands/canyonlands.c 
b/board/amcc/canyonlands/canyonlands.c
index faa3720..80e2739 100644
--- a/board/amcc/canyonlands/canyonlands.c
+++ b/board/amcc/canyonlands/canyonlands.c
@@ -363,18 +363,6 @@ int checkboard(void)
 }
 #endif /* !defined(CONFIG_ARCHES) */
 
-#if defined(CONFIG_NAND_U_BOOT)
-/*
- * NAND booting U-Boot version uses a fixed initialization, since the whole
- * I2C SPD DIMM autodetection/calibration doesn't fit into the 4k of boot
- * code.
- */
-phys_size_t initdram(int board_type)
-{
-   return CONFIG_SYS_MBYTES_SDRAM << 20;
-}
-#endif
-
 #if defined(CONFIG_PCI)
 int board_pcie_first(void)
 {
-- 
1.7.3.2

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


[U-Boot] [PATCH] Fix NAND booting make target

2010-11-23 Thread Stefan Roese
Without this fix, the NAND_SPL target (in nand_spl/) is not built
at all.

Signed-off-by: Stefan Roese 
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index b4aae89..e9797d6 100644
--- a/Makefile
+++ b/Makefile
@@ -287,7 +287,7 @@ LDPPFLAGS += \
$(shell $(LD) --version | \
  sed -ne 's/GNU ld version 
\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
 
-ifeq ($(CONFIG_NAND_U_BOOT),y)
+ifeq ($(CONFIG_NAND_U_BOOT),"y")
 NAND_SPL = nand_spl
 U_BOOT_NAND = $(obj)u-boot-nand.bin
 endif
-- 
1.7.3.2

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


[U-Boot] [PATCH] ppc4xx: Fix NAND SPL linker scripts

2010-11-23 Thread Stefan Roese
Without this patch, the resulting NAND SPL image (nand_spl/u-boot-spl)
will be empty. We need to "keep" the resetvec with the new compiler/
linker options (--gc-sections and -ffunction-sections -fdata-sections).

Signed-off-by: Stefan Roese 
---
 nand_spl/board/amcc/acadia/u-boot.lds  |2 +-
 nand_spl/board/amcc/bamboo/u-boot.lds  |2 +-
 nand_spl/board/amcc/canyonlands/u-boot.lds |2 +-
 nand_spl/board/amcc/kilauea/u-boot.lds |2 +-
 nand_spl/board/amcc/sequoia/u-boot.lds |4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/nand_spl/board/amcc/acadia/u-boot.lds 
b/nand_spl/board/amcc/acadia/u-boot.lds
index b89cd80..5695465 100644
--- a/nand_spl/board/amcc/acadia/u-boot.lds
+++ b/nand_spl/board/amcc/acadia/u-boot.lds
@@ -26,7 +26,7 @@ SECTIONS
 {
   .resetvec 0xf8004ffc :
   {
-*(.resetvec)
+KEEP(*(.resetvec))
   } = 0x
 
   .text  :
diff --git a/nand_spl/board/amcc/bamboo/u-boot.lds 
b/nand_spl/board/amcc/bamboo/u-boot.lds
index d171269..8a9e6e9 100644
--- a/nand_spl/board/amcc/bamboo/u-boot.lds
+++ b/nand_spl/board/amcc/bamboo/u-boot.lds
@@ -26,7 +26,7 @@ SECTIONS
 {
   .resetvec 0x00800FFC :
   {
-*(.resetvec)
+KEEP(*(.resetvec))
   } = 0x
 
   .text  :
diff --git a/nand_spl/board/amcc/canyonlands/u-boot.lds 
b/nand_spl/board/amcc/canyonlands/u-boot.lds
index e676e0c..73190cd 100644
--- a/nand_spl/board/amcc/canyonlands/u-boot.lds
+++ b/nand_spl/board/amcc/canyonlands/u-boot.lds
@@ -26,7 +26,7 @@ SECTIONS
 {
   .resetvec 0xE3003FFC :
   {
-*(.resetvec)
+KEEP(*(.resetvec))
   } = 0x
 
   .text  :
diff --git a/nand_spl/board/amcc/kilauea/u-boot.lds 
b/nand_spl/board/amcc/kilauea/u-boot.lds
index 5a586fc..9894a10 100644
--- a/nand_spl/board/amcc/kilauea/u-boot.lds
+++ b/nand_spl/board/amcc/kilauea/u-boot.lds
@@ -26,7 +26,7 @@ SECTIONS
 {
   .resetvec 0x00800FFC :
   {
-*(.resetvec)
+KEEP(*(.resetvec))
   } = 0x
 
   .text  :
diff --git a/nand_spl/board/amcc/sequoia/u-boot.lds 
b/nand_spl/board/amcc/sequoia/u-boot.lds
index 1601c36..c81ce68 100644
--- a/nand_spl/board/amcc/sequoia/u-boot.lds
+++ b/nand_spl/board/amcc/sequoia/u-boot.lds
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2006
+ * (C) Copyright 2006-2010
  * Stefan Roese, DENX Software Engineering, s...@denx.de.
  *
  * See file CREDITS for list of people who contributed to this
@@ -26,7 +26,7 @@ SECTIONS
 {
   .resetvec 0xE0013FFC :
   {
-*(.resetvec)
+KEEP(*(.resetvec))
   } = 0x
 
   .text  :
-- 
1.7.3.2

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


[U-Boot] [PATCH] ppc4xx/NAND: Reduce size of NAND SPL image

2010-11-23 Thread Stefan Roese
This is needed for the canyonlands_nand build target. Without it
the resulting image won't fit into 4k.

Signed-off-by: Stefan Roese 
Cc: Scott Wood 
---
Scott, I would like to push this patch via my repository.
Please let me know if this is ok with you.

Thanks.

 drivers/mtd/nand/ndfc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 3ca13a9..0729e0c 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -201,6 +201,8 @@ int board_nand_init(struct nand_chip *nand)
 #ifndef CONFIG_NAND_SPL
nand->write_buf  = ndfc_write_buf;
nand->verify_buf = ndfc_verify_buf;
+
+   chip++;
 #else
/*
 * Setup EBC (CS0 only right now)
@@ -211,7 +213,5 @@ int board_nand_init(struct nand_chip *nand)
mtebc(PB0AP, CONFIG_SYS_EBC_PB0AP);
 #endif
 
-   chip++;
-
return 0;
 }
-- 
1.7.3.2

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


[U-Boot] [PATCH] ppc4xx: Remove bogus comment from start.S

2010-11-23 Thread Stefan Roese
Signed-off-by: Stefan Roese 
---
 arch/powerpc/cpu/ppc4xx/start.S |   17 +++--
 1 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S
index 65195f5..c36c13b 100644
--- a/arch/powerpc/cpu/ppc4xx/start.S
+++ b/arch/powerpc/cpu/ppc4xx/start.S
@@ -48,21 +48,10 @@
  
*---
  */
 
-/*  U-Boot - Startup Code for AMCC 4xx PowerPC based Embedded Boards
- *
- *
- *  The processor starts at 0xfffc and the code is executed
- *  from flash/rom.
- *  in memory, but as long we don't jump around before relocating.
- *  board_init lies at a quite high address and when the cpu has
- *  jumped there, everything is ok.
- *  This works because the cpu gives the FLASH (CS0) the whole
- *  address space at startup, and board_init lies as a echo of
- *  the flash somewhere up there in the memorymap.
- *
- *  board_init will change CS0 to be positioned at the correct
- *  address and (s)dram will be positioned at address 0
+/*
+ * Startup code for IBM/AMCC PowerPC 4xx (PPC4xx) based boards
  */
+
 #include 
 #include 
 #include 
-- 
1.7.3.2

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


[U-Boot] [PATCH v4] Seagate FreeAgent DockStar support

2010-11-23 Thread Eric Cooper
start with sheevaplug configuration
add modifications by Alexander Holler 
change RAM definitions to one bank (128 MB)
change ident string and prompt
change environment to 0xA
define MTD partitions and default environment variables
add support for LEDs

Signed-off-by: Eric Cooper 
---
Changes for v2:
  - rebased on master, post ARM and kirkwood relocation changes
  - squashed into single commit

Changes for v3:
  - moved files to board/Seagate/dockstar/ and updated copyright notices
  - removed dockstar entry from MAKEALL
  - moved CONFIG_SYS_TEXT_BASE from config.mk to include/configs/dockstar.h
  - corrected comment in  board/Seagate/dockstar/kwbimage.cfg

Changes for v4:
  - moved dockstar entry in boards.cfg to conform to intended sort order
(other entries to be re-ordered in a subsequent patch)

 MAINTAINERS |4 +
 board/Seagate/dockstar/Makefile |   54 +++
 board/Seagate/dockstar/dockstar.c   |  181 +++
 board/Seagate/dockstar/dockstar.h   |   44 +
 board/Seagate/dockstar/kwbimage.cfg |  165 +++
 boards.cfg  |1 +
 include/configs/dockstar.h  |  125 
 7 files changed, 574 insertions(+), 0 deletions(-)
 create mode 100644 board/Seagate/dockstar/Makefile
 create mode 100644 board/Seagate/dockstar/dockstar.c
 create mode 100644 board/Seagate/dockstar/dockstar.h
 create mode 100644 board/Seagate/dockstar/kwbimage.cfg
 create mode 100644 include/configs/dockstar.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9258cb1..9bf52fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -591,6 +591,10 @@ Po-Yu Chuang 
 
a320evb FA526 (ARM920T-like) (a320 SoC)
 
+Eric Cooper 
+
+   dockstarARM926EJS (Kirkwood SoC)
+
 George G. Davis 
 
assabet SA1100
diff --git a/board/Seagate/dockstar/Makefile b/board/Seagate/dockstar/Makefile
new file mode 100644
index 000..bfcc6d9
--- /dev/null
+++ b/board/Seagate/dockstar/Makefile
@@ -0,0 +1,54 @@
+#
+# Copyright (C) 2010  Eric C. Cooper 
+#
+# Based on sheevaplug/Makefile originally written by
+# Prafulla Wadaskar 
+# (C) Copyright 2009
+# Marvell Semiconductor 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := dockstar.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/Seagate/dockstar/dockstar.c 
b/board/Seagate/dockstar/dockstar.c
new file mode 100644
index 000..cab3a83
--- /dev/null
+++ b/board/Seagate/dockstar/dockstar.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (C) 2010  Eric C. Cooper 
+ *
+ * Based on sheevaplug.c originally written by
+ * Prafulla Wadaskar 
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "dockstar.h"
+
+DECLARE_GLOBAL_DATA_

Re: [U-Boot] [PATCH 3/7] Add support for third program loader

2010-11-23 Thread Haiying Wang
On Mon, 2010-11-22 at 21:58 -0700, Wolfgang Denk wrote:
> Dear haiying.w...@freescale.com,
> 
> In message
> <1290462446-1459-3-git-send-email-haiying.w...@freescale.com> you
> wrote:
> > From: Haiying Wang 
> >
> > This patch introduces the third program loader(TPL) to load the
> final uboot
> > image after the spl code. Once the CONFIG_SYS_TPL_BOOT is defined,
> > the CONFIG_TPL_BOOT is enabled to generate the u-boot-tpl.bin. There
> are two
> 
> This makes no sense to me.  Why do you need an additional variable
> CONFIG_TPL_BOOT when you already have CONFIG_SYS_TPL_BOOT ?
> 
> Please use only one such name (CONFIG_SYS_TPL_BOOT).
CONFIG_SYS_TPL_BOOT is used as CONFIG_NAND_U_BOOT in Makefile and header
file.
CONFIG_TPL_BOOT is used as CONFIG_NAND_SPL in header file.

Does CONFIG_TPL_UBOOT make sense to you if I replace CONFIG_SYS_TPL_BOOT
with it?

Thanks.

Haiying



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


Re: [U-Boot] [PATCH v4] Seagate FreeAgent DockStar support

2010-11-23 Thread Eric Cooper
Sorry, please disregard -- I sent this before committing Prafulla's other
suggested change.

-- 
Eric Cooper e c c @ c m u . e d u
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v5] Seagate FreeAgent DockStar support

2010-11-23 Thread Eric Cooper
start with sheevaplug configuration
add modifications by Alexander Holler 
change RAM definitions to one bank (128 MB)
change ident string and prompt
define MTD partitions and default environment variables
add support for LEDs

Signed-off-by: Eric Cooper 
---
Changes for v2:
  - rebased on master, post ARM and kirkwood relocation changes
  - squashed into single commit

Changes for v3:
  - moved files to board/Seagate/dockstar/ and updated copyright notices
  - removed dockstar entry from MAKEALL
  - moved CONFIG_SYS_TEXT_BASE from config.mk to include/configs/dockstar.h
  - corrected comment in board/Seagate/dockstar/kwbimage.cfg

Changes for v4:
  - moved dockstar entry in boards.cfg to conform to intended sort order
(other entries to be re-ordered in a subsequent patch)

Changes for v5:
  - changed environment address to 0x6

 MAINTAINERS |4 +
 board/Seagate/dockstar/Makefile |   54 +++
 board/Seagate/dockstar/dockstar.c   |  181 +++
 board/Seagate/dockstar/dockstar.h   |   44 +
 board/Seagate/dockstar/kwbimage.cfg |  165 +++
 boards.cfg  |1 +
 include/configs/dockstar.h  |  125 
 7 files changed, 574 insertions(+), 0 deletions(-)
 create mode 100644 board/Seagate/dockstar/Makefile
 create mode 100644 board/Seagate/dockstar/dockstar.c
 create mode 100644 board/Seagate/dockstar/dockstar.h
 create mode 100644 board/Seagate/dockstar/kwbimage.cfg
 create mode 100644 include/configs/dockstar.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9258cb1..9bf52fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -591,6 +591,10 @@ Po-Yu Chuang 
 
a320evb FA526 (ARM920T-like) (a320 SoC)
 
+Eric Cooper 
+
+   dockstarARM926EJS (Kirkwood SoC)
+
 George G. Davis 
 
assabet SA1100
diff --git a/board/Seagate/dockstar/Makefile b/board/Seagate/dockstar/Makefile
new file mode 100644
index 000..bfcc6d9
--- /dev/null
+++ b/board/Seagate/dockstar/Makefile
@@ -0,0 +1,54 @@
+#
+# Copyright (C) 2010  Eric C. Cooper 
+#
+# Based on sheevaplug/Makefile originally written by
+# Prafulla Wadaskar 
+# (C) Copyright 2009
+# Marvell Semiconductor 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := dockstar.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/Seagate/dockstar/dockstar.c 
b/board/Seagate/dockstar/dockstar.c
new file mode 100644
index 000..cab3a83
--- /dev/null
+++ b/board/Seagate/dockstar/dockstar.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (C) 2010  Eric C. Cooper 
+ *
+ * Based on sheevaplug.c originally written by
+ * Prafulla Wadaskar 
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "dockstar.h

Re: [U-Boot] [PATCH] ppc4xx/NAND: Reduce size of NAND SPL image

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 14:32:48 +0100
Stefan Roese  wrote:

> This is needed for the canyonlands_nand build target. Without it
> the resulting image won't fit into 4k.
> 
> Signed-off-by: Stefan Roese 
> Cc: Scott Wood 
> ---
> Scott, I would like to push this patch via my repository.
> Please let me know if this is ok with you.

Acked-by: Scott Wood 

-Scott

___
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

2010-11-23 Thread sughosh ganu
hi Ben,

On Fri, Nov 19, 2010 at 3:20 AM, Ben Gardiner wrote:

>
> 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
>  2010-11-17 11:09:05 +0100
> Davinci 8xx: Move common functions to share code -- Stefano Babic
>  2010-11-17 11:09:04 +0100
> [PATCH V4][NEXT] da850: Add RMII support for EMAC -- Sudhakar
> Rajashekhara  2010-11-18 09:59:37 -0500
> Add board support for hawkboard -- Sughosh Ganu
>  2010-11-01 23:30:34 +0530
> Remove board_init_f function from nand_boot.c -- Sughosh Ganu
>  2010-11-01 23:29:27 +0530
> Move and rename common headers from under board/davinci. -- Sughosh
> Ganu  2010-11-01 23:28:38 +0530
> da850: Enable SPI Flash -- Stefano Babic  2010-11-11
> 15:38:02 +0100
> da8xx: Add cpu_is_da8xx macros -- Sudhakar Rajashekhara
>  2010-11-11 15:38:01 +0100
> Net: clarify board/cpu_eth_init calls -- Ben Warren
>  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.
>
>
Tested on hawkboard with u-boot and nand_spl images built from Ben's tree.

Tested-by: Sughosh Ganu 

I guess i will have to send an updated version from Ben's tree, as he has
fixed some merge issues in "Add board support for hawkboard" patch. The
patches would have to be committed in the same order as mentioned above.

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


Re: [U-Boot] [PATCH] Fix NAND booting make target

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 14:32:20 +0100
Stefan Roese  wrote:

> Without this fix, the NAND_SPL target (in nand_spl/) is not built
> at all.
> 
> Signed-off-by: Stefan Roese 

It builds for me without it, on mpc8315erdb (I tried some 4xx boards
but they don't build at all), as of current master branch
(fa722ea76be565de6823ca04c107cc4fbd96b776).  Applying this change stops
it from building.

-Scott

___
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

2010-11-23 Thread Stefano Babic
On 11/23/2010 05:55 PM, sughosh ganu wrote:

Hi,

> Tested on hawkboard with u-boot and nand_spl images built from Ben's tree.
> 
> Tested-by: Sughosh Ganu  >
> 
> I guess i will have to send an updated version from Ben's tree, as he
> has fixed some merge issues in "Add board support for hawkboard" patch.

Yes, I did the same for mine as Ben has rebased my patches and they are
different as the ones I send to ML.

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] [PATCHv2] mpc83xx: Make it boot again

2010-11-23 Thread Joakim Tjernlund
Could we have an ACK before relese please?

> After the removal of COLD/WARM start flags my mpc8321
> board didn't boot anymore.
> Trial and error suggests that map/remap_flash_by_xxx needs
> to wait after updating LBLAWAR1 to make sure the the change has
> reached the HW before continuing with the code that depends on it.
> Final fix suggested by Scott Wood.
>
> Signed-off-by: Joakim Tjernlund 
> ---
>
>  v2: Final adjustmenst based on inpt from Scott Wood.
>  arch/powerpc/cpu/mpc83xx/start.S |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/cpu/mpc83xx/start.S 
> b/arch/powerpc/cpu/mpc83xx/start.S
> index e8b1ebc..5a9b790 100644
> --- a/arch/powerpc/cpu/mpc83xx/start.S
> +++ b/arch/powerpc/cpu/mpc83xx/start.S
> @@ -1191,6 +1191,10 @@ map_flash_by_law1:
> bne 1b
>
> stw r4, LBLAWAR1(r3) /* LBLAWAR1 <= 8MB Flash Size */
> +   /* Wait for HW to catch up */
> +   lwz r4, LBLAWAR1(r3)
> +   twi 0,r4,0
> +   isync
> blr
>
> /* Though all the LBIU Local Access Windows and LBC Banks will be
> @@ -1229,5 +1233,9 @@ remap_flash_by_law0:
> xor r4, r4, r4
> stw r4, LBLAWBAR1(r3)
> stw r4, LBLAWAR1(r3) /* Off LBIU LAW1 */
> +   /* Wait for HW to catch up */
> +   lwz r4, LBLAWAR1(r3)
> +   twi 0,r4,0
> +   isync
> blr
>  #endif /* CONFIG_SYS_FLASHBOOT */
> --
> 1.7.2.2
>
> ___
> 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] [PATCH] Fix NAND booting make target

2010-11-23 Thread Stefan Roese
Hi Scott,

On Tuesday 23 November 2010 18:27:08 Scott Wood wrote:
> > Without this fix, the NAND_SPL target (in nand_spl/) is not built
> > at all.
> > 
> > Signed-off-by: Stefan Roese 
> 
> It builds for me without it, on mpc8315erdb (I tried some 4xx boards
> but they don't build at all), as of current master branch
> (fa722ea76be565de6823ca04c107cc4fbd96b776).  Applying this change stops
> it from building.

Yes, current git head fails to build an many 4xx boards. My patch is on top of 
Wolfgangs patchset "[PATCH 0/7] Address partial linking issues" from 
2010-11-21 which fixes most of the 4xx problems. But without this patch, no 
object was built in the nand_spl directory at all. Not sure if I overlooked 
something though.

Cheers,
Stefan

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


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

2010-11-23 Thread Paulraj, Sandeep

> 
> On 11/23/2010 05:55 PM, sughosh ganu wrote:
> 
> Hi,
> 
> > Tested on hawkboard with u-boot and nand_spl images built from Ben's
> tree.
> >
> > Tested-by: Sughosh Ganu  > >
> >
> > I guess i will have to send an updated version from Ben's tree, as he
> > has fixed some merge issues in "Add board support for hawkboard" patch.
> 
> Yes, I did the same for mine as Ben has rebased my patches and they are
> different as the ones I send to ML.
> 
> Stefano
> 

Hello All,

I have been tracking this e-mail chain for some time now and I have lost track 
of which patches to apply in which order.

Can someone please give me the correct order and the correct version of the 
patches?

Regards,
Sandeep
___
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

2010-11-23 Thread Ben Gardiner
Hi Sandeep,

On Tue, Nov 23, 2010 at 1:25 PM, Paulraj, Sandeep  wrote:
> I have been tracking this e-mail chain for some time now and I have lost 
> track of which patches to apply in which order.
>
> Can someone please give me the correct order and the correct version of the 
> patches?

The correct order and correct versions of the patches can be found in
branch "testing-ea20-plus" of
git://github.com/BenGardiner/u-boot-bg.git. The commit messages there
do not include Sugosh's Tested-by: tag on the hawkboard patches, nor
has he re-sent them to the ML yet.

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


[U-Boot] [PATCH] mpc83xx: remove some dead code, saving space

2010-11-23 Thread Joakim Tjernlund

Signed-off-by: Joakim Tjernlund 
---
 arch/powerpc/cpu/mpc83xx/start.S |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index f7da14b..121c276 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -967,13 +967,6 @@ relocate_code:
 30:li r3, 0
blr
 
-2: slwir0,r0,2 /* re copy in reverse order ... y do we needed it? */
-   add r8,r4,r0
-   add r7,r3,r0
-3: lwzur0,-4(r8)
-   stwur0,-4(r7)
-   bdnz3b
-
 /*
  * Now flush the cache: note that we must start from a cache aligned
  * address. Otherwise we might miss one cache line.
-- 
1.7.2.2

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


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

2010-11-23 Thread Paulraj, Sandeep


> 
> Hi Sandeep,
> 
> On Tue, Nov 23, 2010 at 1:25 PM, Paulraj, Sandeep 
> wrote:
> > I have been tracking this e-mail chain for some time now and I have lost
> track of which patches to apply in which order.
> >
> > Can someone please give me the correct order and the correct version of
> the patches?
> 
> The correct order and correct versions of the patches can be found in
> branch "testing-ea20-plus" of
> git://github.com/BenGardiner/u-boot-bg.git. The commit messages there
> do not include Sugosh's Tested-by: tag on the hawkboard patches, nor
> has he re-sent them to the ML yet.

I tried to access that page but failed.

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


Re: [U-Boot] [PATCHv2] mpc83xx: Make it boot again

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 19:16:01 +0100
Joakim Tjernlund  wrote:

> Could we have an ACK before relese please?
> 
> > After the removal of COLD/WARM start flags my mpc8321
> > board didn't boot anymore.
> > Trial and error suggests that map/remap_flash_by_xxx needs
> > to wait after updating LBLAWAR1 to make sure the the change has
> > reached the HW before continuing with the code that depends on it.
> > Final fix suggested by Scott Wood.
> >
> > Signed-off-by: Joakim Tjernlund 
> > ---
> >
> >  v2: Final adjustmenst based on inpt from Scott Wood.
> >  arch/powerpc/cpu/mpc83xx/start.S |8 
> >  1 files changed, 8 insertions(+), 0 deletions(-)

ACK

-Scott

___
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

2010-11-23 Thread Paulraj, Sandeep


> 
> 
> 
> >
> > Hi Sandeep,
> >
> > On Tue, Nov 23, 2010 at 1:25 PM, Paulraj, Sandeep 
> > wrote:
> > > I have been tracking this e-mail chain for some time now and I have
> lost
> > track of which patches to apply in which order.
> > >
> > > Can someone please give me the correct order and the correct version
> of
> > the patches?
> >
> > The correct order and correct versions of the patches can be found in
> > branch "testing-ea20-plus" of
> > git://github.com/BenGardiner/u-boot-bg.git. The commit messages there
> > do not include Sugosh's Tested-by: tag on the hawkboard patches, nor
> > has he re-sent them to the ML yet.
> 
> I tried to access that page but failed.

I am able to clone the tree but I am unable to access it on the web
___
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

2010-11-23 Thread Ben Gardiner
On Tue, Nov 23, 2010 at 1:38 PM, Paulraj, Sandeep  wrote:
> I tried to access that page but failed.

Oh. Sorry, Sandeep. The webpage for the repo can be found at
http://github.com/BenGardiner/u-boot-bg -- that page contains three
URL variants for access to the repo.

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] Fix NAND booting make target

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 19:16:47 +0100
Stefan Roese  wrote:

> Hi Scott,
> 
> On Tuesday 23 November 2010 18:27:08 Scott Wood wrote:
> > > Without this fix, the NAND_SPL target (in nand_spl/) is not built
> > > at all.
> > > 
> > > Signed-off-by: Stefan Roese 
> > 
> > It builds for me without it, on mpc8315erdb (I tried some 4xx boards
> > but they don't build at all), as of current master branch
> > (fa722ea76be565de6823ca04c107cc4fbd96b776).  Applying this change stops
> > it from building.
> 
> Yes, current git head fails to build an many 4xx boards. My patch is on top 
> of 
> Wolfgangs patchset "[PATCH 0/7] Address partial linking issues" from 
> 2010-11-21 which fixes most of the 4xx problems. But without this patch, no 
> object was built in the nand_spl directory at all. Not sure if I overlooked 
> something though.

Perhaps it has to do with the 4xx boards having NAND_U_BOOT directly in
boards.cfg, while the Freescale boards typically have NAND there, and
define NAND_U_BOOT in the makefile.

I think the proper fix is to figure out how those quotes are being
injected into the make variable.

-Scott

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


[U-Boot] [PATCH 0/6] RFC: True PIC on 83xx

2010-11-23 Thread Joakim Tjernlund
Here goes my attempt to revive true PIC on ppc, starting with 83xx.
This uses a a new gcc option(which I have just impl.) to add
msingle-pic-base also save a lot of code:
before:
   textdata bss dec hex filename
 222728   14336   24228  261292   3fcac u-boot
after:
   textdata bss dec hex filename
 2185566580   24228  249364   3ce14 u-boot

As can seen, I only have to add two LINK_OFF calls in early C code to
pull this off.

Oh, this is based on the last u-boot release so it migth not apply
without minor mods. It depends on 2 other patches which I have already
sent.

Anyhow, if this is an acceptable approach I will clean it up once
the ongoing release is out.

Joakim Tjernlund (6):
  mpc83xx: Add relocation support for -fpic
  mpc83xx: Make start.S true PIC
  mpc83xx: Add link vs. load address calculation
  mpc83xx: Add support form -msingle-pic-base
  mpc83xx: Add true PIC support.
  powerpc: Add LINK_OFF calls in early C-code.

 arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
 arch/powerpc/cpu/mpc83xx/start.S|  107 +--
 arch/powerpc/cpu/mpc83xx/u-boot.lds |5 +-
 arch/powerpc/lib/board.c|2 +-
 include/common.h|5 +
 nand_spl/board/freescale/mpc8313erdb/u-boot.lds |4 +-
 nand_spl/board/freescale/mpc8315erdb/u-boot.lds |4 +-
 7 files changed, 114 insertions(+), 15 deletions(-)

-- 
1.7.2.2

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


[U-Boot] [PATCH 1/6] mpc83xx: Add relocation support for -fpic

2010-11-23 Thread Joakim Tjernlund
By rearranging the linker script we get support for
relocation of -fpic for free.
---
 arch/powerpc/cpu/mpc83xx/u-boot.lds |5 +++--
 nand_spl/board/freescale/mpc8313erdb/u-boot.lds |4 +++-
 nand_spl/board/freescale/mpc8315erdb/u-boot.lds |4 +++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/u-boot.lds 
b/arch/powerpc/cpu/mpc83xx/u-boot.lds
index 0b74a13..877f298 100644
--- a/arch/powerpc/cpu/mpc83xx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc83xx/u-boot.lds
@@ -67,13 +67,14 @@ SECTIONS
   PROVIDE (erotext = .);
   .reloc   :
   {
-*(.got)
 _GOT2_TABLE_ = .;
 *(.got2)
+*(.got)
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
 _FIXUP_TABLE_ = .;
 *(.fixup)
   }
-  __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
+  __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
   __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
 
   .data:
diff --git a/nand_spl/board/freescale/mpc8313erdb/u-boot.lds 
b/nand_spl/board/freescale/mpc8313erdb/u-boot.lds
index 853b2de..7c5a40f 100644
--- a/nand_spl/board/freescale/mpc8313erdb/u-boot.lds
+++ b/nand_spl/board/freescale/mpc8313erdb/u-boot.lds
@@ -40,8 +40,10 @@ SECTIONS
*(.sdata*)
_GOT2_TABLE_ = .;
*(.got2)
+   *(.got)
+   PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
}
-   __got2_entries = (. - _GOT2_TABLE_) >> 2;
+   __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
 
. = ALIGN(8);
__bss_start = .;
diff --git a/nand_spl/board/freescale/mpc8315erdb/u-boot.lds 
b/nand_spl/board/freescale/mpc8315erdb/u-boot.lds
index 853b2de..7c5a40f 100644
--- a/nand_spl/board/freescale/mpc8315erdb/u-boot.lds
+++ b/nand_spl/board/freescale/mpc8315erdb/u-boot.lds
@@ -40,8 +40,10 @@ SECTIONS
*(.sdata*)
_GOT2_TABLE_ = .;
*(.got2)
+   *(.got)
+   PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
}
-   __got2_entries = (. - _GOT2_TABLE_) >> 2;
+   __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
 
. = ALIGN(8);
__bss_start = .;
-- 
1.7.2.2

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


[U-Boot] [PATCH 2/6] mpc83xx: Make start.S true PIC

2010-11-23 Thread Joakim Tjernlund
Remove dependencies on link address. Use GOT and
add an new function to calculate the actual address.
---
 arch/powerpc/cpu/mpc83xx/start.S |   36 
 1 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index 09c5eac..3cac147 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -69,12 +69,12 @@
  */
START_GOT
GOT_ENTRY(_GOT2_TABLE_)
+   GOT_ENTRY(_start)
GOT_ENTRY(__bss_start)
GOT_ENTRY(_end)
 
 #ifndef CONFIG_NAND_SPL
GOT_ENTRY(_FIXUP_TABLE_)
-   GOT_ENTRY(_start)
GOT_ENTRY(_start_of_vectors)
GOT_ENTRY(_end_of_vectors)
GOT_ENTRY(transfer_to_handler)
@@ -240,10 +240,12 @@ boot_warm: /* time t 5 */
/* there and deflate the flash size back to minimal size  */
/**/
bl map_flash_by_law1
-   lis r4, (CONFIG_SYS_MONITOR_BASE)@h
-   ori r4, r4, (CONFIG_SYS_MONITOR_BASE)@l
-   addi r5, r4, in_flash - _start + EXC_OFF_SYS_RESET
-   mtlr r5
+
+   bl  1f
+1: mflrr3   /* get current address */
+   addir3, r3, in_flash - 1b
+   bl  add_flash_base
+   mtlr r3
blr
 in_flash:
 #if 1 /* Remapping flash with LAW0. */
@@ -833,10 +835,12 @@ relocate_code:
mr  r10, r5 /* Save copy of Destination Address */
 
GET_GOT
-   mr  r3,  r5 /* Destination Address */
-   lis r4, config_sys_monitor_b...@h   /* Source  Address 
*/
-   ori r4, r4, config_sys_monitor_b...@l
+
+   lwz r4, GOT(_start) /* Source Address */
+   addir4, r4, -EXC_OFF_SYS_RESET
lwz r5, GOT(__bss_start)
+   mr  r3, r10 /* Destination Address */
+
sub r5, r5, r4
li  r6, CONFIG_SYS_CACHELINE_SIZE   /* Cache Line Size */
 
@@ -1128,6 +1132,21 @@ unlock_ram_in_cache:
 #endif /* CONFIG_SYS_INIT_RAM_LOCK */
 
 #ifdef CONFIG_SYS_FLASHBOOT
+
+add_flash_base:
+   /* Check if already inside flash address space. */
+   /* if so, do not add CONFIG_SYS_FLASH_BASE */
+   lis r4, (CONFIG_SYS_FLASH_BASE)@h
+   ori r4, r4, (CONFIG_SYS_FLASH_BASE)@l
+   cmplw   cr0, r3, r4
+   ble cr0, 2f /* r3 < r4 ? */
+   lis r6, 
(CONFIG_SYS_FLASH_BASE+(CONFIG_SYS_FLASH_SIZE*1024*1024-1))@h
+   ori r6, r6, 
(CONFIG_SYS_FLASH_BASE+(CONFIG_SYS_FLASH_SIZE*1024*1024-1))@l
+   cmplw   cr0, r3, r6
+   blelr   cr0  /* r3 < r6 ? */
+2: add r3,r3,r4
+   blr
+
 map_flash_by_law1:
/* When booting from ROM (Flash or EPROM), clear the  */
/* Address Mask in OR0 so ROM appears everywhere  */
@@ -1179,6 +1198,7 @@ map_flash_by_law1:
 */
 remap_flash_by_law0:
/* Initialize the BR0 with the boot ROM starting address. */
+   lis r3, (CONFIG_SYS_IMMR)@h  /* r3 <= CONFIG_SYS_IMMR*/
lwz r4, BR0(r3)
li  r5, 0x7FFF
and r4, r4, r5
-- 
1.7.2.2

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


[U-Boot] [PATCH 3/6] mpc83xx: Add link vs. load address calculation

2010-11-23 Thread Joakim Tjernlund
link_off calculates the difference between link address and
actila load address. This is a must for true PIC u-boot.
---
 arch/powerpc/cpu/mpc83xx/start.S |   25 +
 include/common.h |5 +
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index 3cac147..ec65f40 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -427,6 +427,31 @@ _end_of_vectors:
 
. = 0x3000
 
+   .globl  link_off /* const void * link_off(const void * ptr) */
+   .type   link_off, @function
+   /*
+* Calculates the offset between link address and load address
+* and subtracs the offset to from its argument(r3)
+* This function must be where _GOT2_TABLE_ is defined
+*/
+link_off:
+   /* GOT hand coded as we cannot clobber r12 */
+   mflrr4
+   bl  1f
+   .text   2
+0: .long   .LCTOC1-1f
+   .text
+1: mflrr6
+   lwz r0,0b-1b(r6)
+   add r6,r0,r6
+   mtlrr4
+   la  r4,.L__GOT2_TABLE_(r6) /* addi  r4,r6,.L__GOT2_TABLE_ */
+   lwz r5,.L__GOT2_TABLE_(r6)
+   sub r4,r5,r4 /* r4 - r5 */
+   sub r3,r3,r4 /* r4 - r3 */
+   blr
+   .size   link_off, .-link_off
+
 /*
  * This code finishes saving the registers to the exception frame
  * and jumps to the appropriate handler for the exception.
diff --git a/include/common.h b/include/common.h
index 8bca04f..f257ea4 100644
--- a/include/common.h
+++ b/include/common.h
@@ -94,6 +94,9 @@ typedef volatile unsigned charvu_char;
 #ifdef CONFIG_MPC83xx
 #include 
 #include 
+const void * link_off(const void *);
+#else
+#define link_off(x) ((const void *)(x))
 #endif
 #ifdef CONFIG_4xx
 #include 
@@ -111,6 +114,8 @@ typedef volatile unsigned char  vu_char;
 #include 
 #endif
 
+#define LINK_OFF(x) ((__typeof__(x))link_off(x))
+
 #include 
 #include 
 #include 
-- 
1.7.2.2

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


[U-Boot] [PATCH 4/6] mpc83xx: Add support form -msingle-pic-base

2010-11-23 Thread Joakim Tjernlund
singel-pic-base is pending inclusinon in gcc and is useful
for reducing code size and impl. true PIC.
---
 arch/powerpc/cpu/mpc83xx/start.S |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index ec65f40..3d4e288 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -298,7 +298,11 @@ in_flash:
/*--*/
 
GET_GOT /* initialize GOT access*/
-
+#if defined(__pic__) && __pic__ == 1
+   /* Needed for upcoming -msingle-pic-base */
+   bl  _global_offset_tab...@local-4
+   mflrr30
+#endif
/* r3: IMMR */
lis r3, config_sys_i...@h
/* run low-level CPU init code (in Flash)*/
@@ -860,7 +864,11 @@ relocate_code:
mr  r10, r5 /* Save copy of Destination Address */
 
GET_GOT
-
+#if defined(__pic__) && __pic__ == 1
+   /* Needed for upcoming -msingle-pic-base */
+   bl  _global_offset_tab...@local-4
+   mflrr30
+#endif
lwz r4, GOT(_start) /* Source Address */
addir4, r4, -EXC_OFF_SYS_RESET
lwz r5, GOT(__bss_start)
-- 
1.7.2.2

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


[U-Boot] [PATCH 5/6] mpc83xx: Add true PIC support.

2010-11-23 Thread Joakim Tjernlund
By copying the GOT to the end of the INIT_RAM(dcache)
and relocating it there, it is much esier to
support true PIC on u-boot. This cannot handle
FIXUP so C code that depends on fixups before relocation to RAM
must use LINK_OFF to calculate the difference.

This depends on the upcoming single-pic-base option
to gcc.
---
 arch/powerpc/cpu/mpc83xx/start.S |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index 3d4e288..b24a89a 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -302,6 +302,34 @@ in_flash:
/* Needed for upcoming -msingle-pic-base */
bl  _global_offset_tab...@local-4
mflrr30
+#ifdef CONFIG_SYS_TRUE_PIC
+   /*
+* Copy GOT to cache and relocate it
+* This assumes there is enough space at the end
+* INIT_RAM to hold a copy of the GOT.
+*/
+   li r3,0
+   bl link_off /* r3 holds link offset at return */
+   lis r9, (CONFIG_SYS_INIT_RAM_ADDR+CONFIG_SYS_INIT_RAM_END)@h
+   ori r9,r9,(CONFIG_SYS_INIT_RAM_ADDR+CONFIG_SYS_INIT_RAM_END)@l
+   lwz r11,GOT(_GOT2_TABLE_)
+   add r11,r11,r3
+
+   li r4, __got2_entr...@sectoff@l
+   mtctr r4
+   slwi r5,r4,2 /* r4 * 4 */
+   subf r9,r5,r9 /* r9 - r5 */
+
+   subf r10,r9,r11 /* r11 - r9 */
+   subf r30,r10,r30 /* r30 - r10, point PIC(r30) to new GOT */
+   addi r11,r11,-4
+   addi r9,r9,-4
+1: /* copy GOT and add link offset */
+   lwzu r0,4(r11)
+   add r0,r0,r3
+   stwu r0,4(r9)
+   bdnz 1b
+#endif
 #endif
/* r3: IMMR */
lis r3, config_sys_i...@h
@@ -869,9 +897,17 @@ relocate_code:
bl  _global_offset_tab...@local-4
mflrr30
 #endif
+#ifdef CONFIG_SYS_TRUE_PIC
+   li  r3, 0
+   bl  link_off /* const void * link_off(const void *) */
+#endif
lwz r4, GOT(_start) /* Source Address */
addir4, r4, -EXC_OFF_SYS_RESET
lwz r5, GOT(__bss_start)
+#ifdef CONFIG_SYS_TRUE_PIC
+   add r4, r4, r3 /* Add link offset */
+   add r5, r5, r3 /* Add link offset */
+#endif
mr  r3, r10 /* Destination Address */
 
sub r5, r5, r4
-- 
1.7.2.2

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


[U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Joakim Tjernlund
Only these 2 call sites depends on fixups for my mpc8321 based
board.
---
 arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
 arch/powerpc/lib/board.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index f3b67ae..0437b49 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -534,7 +534,7 @@ int prt_83xx_rsr(void)
sep = " ";
for (i = 0; i < n; i++)
if (rsr & bits[i].mask) {
-   printf("%s%s", sep, bits[i].desc);
+   printf("%s%s", sep, LINK_OFF(bits[i].desc));
sep = ", ";
}
puts("\n");
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 7b09fb5..9fa99dc 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -386,7 +386,7 @@ void board_init_f (ulong bootflag)
 #endif
 
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
-   if ((*init_fnc_ptr) () != 0) {
+   if ((LINK_OFF(*init_fnc_ptr)) () != 0) {
hang ();
}
}
-- 
1.7.2.2

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


Re: [U-Boot] [PATCH] Fix NAND booting make target

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 12:45:04 -0600
Scott Wood  wrote:

> On Tue, 23 Nov 2010 19:16:47 +0100
> Stefan Roese  wrote:
> 
> > Hi Scott,
> > 
> > On Tuesday 23 November 2010 18:27:08 Scott Wood wrote:
> > > > Without this fix, the NAND_SPL target (in nand_spl/) is not built
> > > > at all.
> > > > 
> > > > Signed-off-by: Stefan Roese 
> > > 
> > > It builds for me without it, on mpc8315erdb (I tried some 4xx boards
> > > but they don't build at all), as of current master branch
> > > (fa722ea76be565de6823ca04c107cc4fbd96b776).  Applying this change stops
> > > it from building.
> > 
> > Yes, current git head fails to build an many 4xx boards. My patch is on top 
> > of 
> > Wolfgangs patchset "[PATCH 0/7] Address partial linking issues" from 
> > 2010-11-21 which fixes most of the 4xx problems. But without this patch, no 
> > object was built in the nand_spl directory at all. Not sure if I overlooked 
> > something though.
> 
> Perhaps it has to do with the 4xx boards having NAND_U_BOOT directly in
> boards.cfg, while the Freescale boards typically have NAND there, and
> define NAND_U_BOOT in the makefile.
> 
> I think the proper fix is to figure out how those quotes are being
> injected into the make variable.

Try removing the "=y" in boards.cfg.  tools/scripts/define2mk.sed will
add quotes to things that aren't numbers, but it has special handling
to turn empty defines (or the number 1) into an unquoted y.

-Scott

___
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

2010-11-23 Thread Ben Gardiner
On Tue, Nov 23, 2010 at 1:44 PM, Paulraj, Sandeep  wrote:
> I am able to clone the tree but I am unable to access it on the web

I'm very sorry for the trouble you've had accessing that repo -- I
will happily switch to any other public git hosting service of your
choosing for future merged series.

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 1/2][NEXT] Davinci 8xx: Move common functions to share code

2010-11-23 Thread Paulraj, Sandeep


> 
> On Tue, Nov 23, 2010 at 1:44 PM, Paulraj, Sandeep 
> wrote:
> > I am able to clone the tree but I am unable to access it on the web
> 
> I'm very sorry for the trouble you've had accessing that repo -- I
> will happily switch to any other public git hosting service of your
> choosing for future merged series.


Not an issue at all.

In this case because of some major changes and multiple patch versions I lost 
track. Usually I pick it from the mailing list.

After Wolfgang accept my previous pull request, I'll get on with the program of 
merging these patches.

Thanks,
Sandeep
___
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

2010-11-23 Thread Ben Gardiner
On Tue, Nov 23, 2010 at 1:57 PM, Paulraj, Sandeep  wrote:
> Not an issue at all.
>
> In this case because of some major changes and multiple patch versions I lost 
> track. Usually I pick it from the mailing list.
>
> After Wolfgang accept my previous pull request, I'll get on with the program 
> of merging these patches.

That is very exciting news! Thank you, Sandeep.

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] Fix NAND booting make target

2010-11-23 Thread Stefan Roese
On Tuesday 23 November 2010 19:51:14 Scott Wood wrote:
> > > Yes, current git head fails to build an many 4xx boards. My patch is on
> > > top of Wolfgangs patchset "[PATCH 0/7] Address partial linking issues"
> > > from 2010-11-21 which fixes most of the 4xx problems. But without this
> > > patch, no object was built in the nand_spl directory at all. Not sure
> > > if I overlooked something though.
> > 
> > Perhaps it has to do with the 4xx boards having NAND_U_BOOT directly in
> > boards.cfg, while the Freescale boards typically have NAND there, and
> > define NAND_U_BOOT in the makefile.
> > 
> > I think the proper fix is to figure out how those quotes are being
> > injected into the make variable.
> 
> Try removing the "=y" in boards.cfg.  tools/scripts/define2mk.sed will
> add quotes to things that aren't numbers, but it has special handling
> to turn empty defines (or the number 1) into an unquoted y.

Yes, this works as well. I'll send an updated patch tomorrow.

Thanks.
 
Cheers,
Stefan

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


Re: [U-Boot] [PATCH 3/6] mpc83xx: Add link vs. load address calculation

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 19:48:48 +0100
Joakim Tjernlund  wrote:

> diff --git a/include/common.h b/include/common.h
> index 8bca04f..f257ea4 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -94,6 +94,9 @@ typedef volatile unsigned char  vu_char;
>  #ifdef CONFIG_MPC83xx
>  #include 
>  #include 
> +const void * link_off(const void *);
> +#else
> +#define link_off(x) ((const void *)(x))
>  #endif

What is special about 83xx?

If it's just that 83xx is the only one that this type of relocation has
been enabled on so far, define a symbol for that.

-Scott

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


Re: [U-Boot] MACHINE ID

2010-11-23 Thread Wolfgang Denk
Dear "Bedia, Vaibhav",

In message  you 
wrote:
>
> This error is due to an incorrect machid being passed to the kernel.
> 
> This can be fixed using the following commands:
> 
> TI8168_EVM# setenv machid af0

Note that is is a workaround at best, not a fix. For a fix the
incorrect value needs to be substituted in the board config file.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The explanation requiring the fewest assumptions is the  most  likely
to be correct.-- William of Occam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 7/7] 4xx: Cleanup for partial linking and --gc-sections

2010-11-23 Thread Wolfgang Denk
Dear Stefan Roese,

In message <201011231431.18905...@denx.de> you wrote:
> 
> > --- a/arch/powerpc/cpu/ppc4xx/Makefile
> > +++ b/arch/powerpc/cpu/ppc4xx/Makefile
> > @@ -37,9 +37,9 @@ COBJS := 40x_spd_sdram.o
> >  ifndef CONFIG_NAND_SPL
> >  ifndef CONFIG_NAND_U_BOOT
> >  COBJS  += 44x_spd_ddr.o
> > +COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
> >  endif
> >  endif
> > -COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
> 
> This change introduces the problem with the kilauea/haleakala NAND booting 
> images. Yes, I am aware that without this change, canyonlands_nand fails to 
> build. I noticed this too right now. I'll send another patch to fix this 
> canyonlands_nand build problem shortly.

Without this, kilauea/haleakala NAND boot configurations load the
44x_spd_ddr2 init code, which you said was not the correct thing.

So which is correct?

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
Inside every old person is a young person wondering what happened.
  - Terry Pratchett, _Moving Pictures_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ppc4xx: Remove bogus comment from start.S

2010-11-23 Thread Wolfgang Denk
Dear Stefan Roese,

In message <1290519180-6764-1-git-send-email...@denx.de> you wrote:
> Signed-off-by: Stefan Roese 
> ---
>  arch/powerpc/cpu/ppc4xx/start.S |   17 +++--
>  1 files changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S
> index 65195f5..c36c13b 100644
> --- a/arch/powerpc/cpu/ppc4xx/start.S
> +++ b/arch/powerpc/cpu/ppc4xx/start.S
> @@ -48,21 +48,10 @@
>   
> *---
>   */
>  
> -/*  U-Boot - Startup Code for AMCC 4xx PowerPC based Embedded Boards
> - *
> - *
> - *  The processor starts at 0xfffc and the code is executed
> - *  from flash/rom.
> - *  in memory, but as long we don't jump around before relocating.
> - *  board_init lies at a quite high address and when the cpu has
> - *  jumped there, everything is ok.
> - *  This works because the cpu gives the FLASH (CS0) the whole
> - *  address space at startup, and board_init lies as a echo of
> - *  the flash somewhere up there in the memorymap.
> - *
> - *  board_init will change CS0 to be positioned at the correct
> - *  address and (s)dram will be positioned at address 0
> +/*
> + * Startup code for IBM/AMCC PowerPC 4xx (PPC4xx) based boards
>   */

It appears that the old comment contained some information about how
booting and especially address resolution works on 4xx.  Is there some
way to keep this (non-obvious, at least to me) information, instead of
just deleting it?

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
He who hesitates is not only lost, but miles from the next exit.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/6] mpc83xx: Add link vs. load address calculation

2010-11-23 Thread Joakim Tjernlund
Scott Wood  wrote on 2010/11/23 20:32:32:
> On Tue, 23 Nov 2010 19:48:48 +0100
> Joakim Tjernlund  wrote:
>
> > diff --git a/include/common.h b/include/common.h
> > index 8bca04f..f257ea4 100644
> > --- a/include/common.h
> > +++ b/include/common.h
> > @@ -94,6 +94,9 @@ typedef volatile unsigned char   vu_char;
> >  #ifdef CONFIG_MPC83xx
> >  #include 
> >  #include 
> > +const void * link_off(const void *);
> > +#else
> > +#define link_off(x) ((const void *)(x))
> >  #endif
>
> What is special about 83xx?

Nothing, just it is the first one.
>
> If it's just that 83xx is the only one that this type of relocation has
> been enabled on so far, define a symbol for that.

there is a
#define LINK_OFF(x) ((__typeof__(x))link_off(x))
already but I am guessing you mean something else.
Perhaps a dummy link_off for other targets? Don't think
that is any better.

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


Re: [U-Boot] [PATCH 3/6] mpc83xx: Add link vs. load address calculation

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 21:08:37 +0100
Joakim Tjernlund  wrote:

> Scott Wood  wrote on 2010/11/23 20:32:32:
> > On Tue, 23 Nov 2010 19:48:48 +0100
> > Joakim Tjernlund  wrote:
> >
> > > diff --git a/include/common.h b/include/common.h
> > > index 8bca04f..f257ea4 100644
> > > --- a/include/common.h
> > > +++ b/include/common.h
> > > @@ -94,6 +94,9 @@ typedef volatile unsigned char   vu_char;
> > >  #ifdef CONFIG_MPC83xx
> > >  #include 
> > >  #include 
> > > +const void * link_off(const void *);
> > > +#else
> > > +#define link_off(x) ((const void *)(x))
> > >  #endif
> >
> > What is special about 83xx?
> 
> Nothing, just it is the first one.
> >
> > If it's just that 83xx is the only one that this type of relocation has
> > been enabled on so far, define a symbol for that.
> 
> there is a
> #define LINK_OFF(x) ((__typeof__(x))link_off(x))
> already but I am guessing you mean something else.
> Perhaps a dummy link_off for other targets? Don't think
> that is any better.

I mean instead of this:

#ifdef CONFIG_MPC83xx
...unrelated stuff...
const void *link_off(const void *ptr);
#else
#define link_off(x) ((const void *)(x));
#endif

do something like this:

#ifdef CONFIG_RELOC_PIC
const void *link_off(const void *ptr);
#else
#define link_off(x) ((const void *)(x));
#endif

...with CONFIG_RELOC_PIC defined in a board config file and also
controlling whether this mechanism is enabled at all.  Boards could
enable it as they verify that they have the proper manual relocations
(or just leave it off, if they don't think it's worth it) -- including
non-83xx targets if they provide link_off() and do whatever else is
required.

-Scott

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


Re: [U-Boot] [PATCH 3/6] mpc83xx: Add link vs. load address calculation

2010-11-23 Thread Joakim Tjernlund
Scott Wood  wrote on 2010/11/23 21:17:12:
>
> On Tue, 23 Nov 2010 21:08:37 +0100
> Joakim Tjernlund  wrote:
>
> > Scott Wood  wrote on 2010/11/23 20:32:32:
> > > On Tue, 23 Nov 2010 19:48:48 +0100
> > > Joakim Tjernlund  wrote:
> > >
> > > > diff --git a/include/common.h b/include/common.h
> > > > index 8bca04f..f257ea4 100644
> > > > --- a/include/common.h
> > > > +++ b/include/common.h
> > > > @@ -94,6 +94,9 @@ typedef volatile unsigned char   vu_char;
> > > >  #ifdef CONFIG_MPC83xx
> > > >  #include 
> > > >  #include 
> > > > +const void * link_off(const void *);
> > > > +#else
> > > > +#define link_off(x) ((const void *)(x))
> > > >  #endif
> > >
> > > What is special about 83xx?
> >
> > Nothing, just it is the first one.
> > >
> > > If it's just that 83xx is the only one that this type of relocation has
> > > been enabled on so far, define a symbol for that.
> >
> > there is a
> > #define LINK_OFF(x) ((__typeof__(x))link_off(x))
> > already but I am guessing you mean something else.
> > Perhaps a dummy link_off for other targets? Don't think
> > that is any better.
>
> I mean instead of this:
>
> #ifdef CONFIG_MPC83xx
> ...unrelated stuff...
> const void *link_off(const void *ptr);
> #else
> #define link_off(x) ((const void *)(x));
> #endif
>
> do something like this:
>
> #ifdef CONFIG_RELOC_PIC
> const void *link_off(const void *ptr);
> #else
> #define link_off(x) ((const void *)(x));
> #endif
>
> ...with CONFIG_RELOC_PIC defined in a board config file and also
> controlling whether this mechanism is enabled at all.  Boards could
> enable it as they verify that they have the proper manual relocations
> (or just leave it off, if they don't think it's worth it) -- including
> non-83xx targets if they provide link_off() and do whatever else is
> required.

Ah yes, will be in my cleanup later on.

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 19:48:51 +0100
Joakim Tjernlund  wrote:

> Only these 2 call sites depends on fixups for my mpc8321 based
> board.
> ---
>  arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
>  arch/powerpc/lib/board.c|2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
> b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> index f3b67ae..0437b49 100644
> --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
> +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> @@ -534,7 +534,7 @@ int prt_83xx_rsr(void)
>   sep = " ";
>   for (i = 0; i < n; i++)
>   if (rsr & bits[i].mask) {
> - printf("%s%s", sep, bits[i].desc);
> + printf("%s%s", sep, LINK_OFF(bits[i].desc));
>   sep = ", ";
>   }
>   puts("\n");
> diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
> index 7b09fb5..9fa99dc 100644
> --- a/arch/powerpc/lib/board.c
> +++ b/arch/powerpc/lib/board.c
> @@ -386,7 +386,7 @@ void board_init_f (ulong bootflag)
>  #endif
>  
>   for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> - if ((*init_fnc_ptr) () != 0) {
> + if ((LINK_OFF(*init_fnc_ptr)) () != 0) {
>   hang ();
>   }
>   }

"Only these" that you've found so far, for the board you've tried --
is it worth adding another pre-relocation landmine to shrink the image
by 5%?  I don't miss the manual fixups we had to do under the old
relocation scheme.

Please document the specific circumstances in which one would need
to use this (any data-segment pointer before relocation?).

Is a missing LINK_OFF likely to result in a crash, or silent bad
behavior?  Will LINK_OFF be a no-op after relocation?

-Scott

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


Re: [U-Boot] [PATCH 0/6] RFC: True PIC on 83xx

2010-11-23 Thread Wolfgang Denk
Dear Joakim Tjernlund,

In message <1290538131-12383-1-git-send-email-joakim.tjernl...@transmode.se> 
you wrote:
> Here goes my attempt to revive true PIC on ppc, starting with 83xx.
> This uses a a new gcc option(which I have just impl.) to add
> msingle-pic-base also save a lot of code:

Is my inderstanding correct that this is a private, all new gcc
extension?  Do you have plans to submit it upstream?

I appreciate your work, and I, too, would like to be able to do what
this patch series seems to acchieve, but I think we should not add
this to mainline when neither mainline gcc nor any of the "common"
tool chains (say, OE/Yocto/LF, Linaro, CodeSourcery, ...) supports it.

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
Successful and fortunate crime is called virtue. - Seneca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/7] Add support for third program loader

2010-11-23 Thread Wolfgang Denk
Dear Haiying Wang,

In message <1290525198.1932.3.ca...@haiying-laptop> you wrote:
>
> > Please use only one such name (CONFIG_SYS_TPL_BOOT).
> CONFIG_SYS_TPL_BOOT is used as CONFIG_NAND_U_BOOT in Makefile and header
> file.
> CONFIG_TPL_BOOT is used as CONFIG_NAND_SPL in header file.

I'm sorry, but I have to admit that I don;t understand what you are
trying to tell me.

Why do you need XXX when you use it as YYY? Why don't you use YYY
directly?

> Does CONFIG_TPL_UBOOT make sense to you if I replace CONFIG_SYS_TPL_BOOT
> with it?

I cannot answer this. Don't understand any of this.

Maybe you can re-think this again and try to make it less complex, and
the add a description of the then used new variables to the README.
We need this documentation anyway.  Maybe I can understand this
documentation then, and provide better comment.  Sorry,

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.   - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Joakim Tjernlund
Scott Wood  wrote on 2010/11/23 21:46:51:
> On Tue, 23 Nov 2010 19:48:51 +0100
> Joakim Tjernlund  wrote:
>
> > Only these 2 call sites depends on fixups for my mpc8321 based
> > board.
> > ---
> >  arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
> >  arch/powerpc/lib/board.c|2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
> > b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> > index f3b67ae..0437b49 100644
> > --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
> > +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> > @@ -534,7 +534,7 @@ int prt_83xx_rsr(void)
> > sep = " ";
> > for (i = 0; i < n; i++)
> >if (rsr & bits[i].mask) {
> > - printf("%s%s", sep, bits[i].desc);
> > + printf("%s%s", sep, LINK_OFF(bits[i].desc));
> >   sep = ", ";
> >}
> > puts("\n");
> > diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
> > index 7b09fb5..9fa99dc 100644
> > --- a/arch/powerpc/lib/board.c
> > +++ b/arch/powerpc/lib/board.c
> > @@ -386,7 +386,7 @@ void board_init_f (ulong bootflag)
> >  #endif
> >
> > for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > -  if ((*init_fnc_ptr) () != 0) {
> > +  if ((LINK_OFF(*init_fnc_ptr)) () != 0) {
> >   hang ();
> >}
> > }
>
> "Only these" that you've found so far, for the board you've tried --

Yes, that is what I wrote. The previous try had LINK_OFF calls all over the
place just for my board.

> is it worth adding another pre-relocation landmine to shrink the image
> by 5%?  I don't miss the manual fixups we had to do under the old
> relocation scheme.

-msingle-pic-base does not require LINK_OFF per se. It will shrink the image
significantly for free. It enables impl. of true PIC and if you want to have
that too you need LINK_OFF.

> Please document the specific circumstances in which one would need
> to use this (any data-segment pointer before relocation?).

Any ptr needing fixups:
char *sptr = "hi";
Same for static initialized function ptrs too.

> Is a missing LINK_OFF likely to result in a crash, or silent bad
> behavior?  Will LINK_OFF be a no-op after relocation?

Either crash or garbage printed on the port.
LINK_OFF is a NOP after relocation. It will be a NOP
if link address == load address too.

 Jocke

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


Re: [U-Boot] [PATCH 0/6] RFC: True PIC on 83xx

2010-11-23 Thread Joakim Tjernlund
Wolfgang Denk  wrote on 2010/11/23 21:52:11:
>
> Dear Joakim Tjernlund,
>
> In message <1290538131-12383-1-git-send-email-joakim.tjernl...@transmode.se> 
> you wrote:
> > Here goes my attempt to revive true PIC on ppc, starting with 83xx.
> > This uses a a new gcc option(which I have just impl.) to add
> > msingle-pic-base also save a lot of code:
>
> Is my inderstanding correct that this is a private, all new gcc
> extension?  Do you have plans to submit it upstream?
>
> I appreciate your work, and I, too, would like to be able to do what
> this patch series seems to acchieve, but I think we should not add
> this to mainline when neither mainline gcc nor any of the "common"
> tool chains (say, OE/Yocto/LF, Linaro, CodeSourcery, ...) supports it.

-msingle-pic-base already exist for ARM. I impl. it for PowerPC too.
I have submitted it upstream and I hope it will be accepted, it is ongoing
but slowly as there are very few ppc maintainers.

 Jocke

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Joakim Tjernlund
>
> Scott Wood  wrote on 2010/11/23 21:46:51:
> > On Tue, 23 Nov 2010 19:48:51 +0100
> > Joakim Tjernlund  wrote:
> > Please document the specific circumstances in which one would need
> > to use this (any data-segment pointer before relocation?).
>
> Any ptr needing fixups:
> char *sptr = "hi";
> Same for static initialized function ptrs too.

Clarification, the above is for ptrs used before relocation to RAM.

 Jocke

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 22:03:36 +0100
Joakim Tjernlund  wrote:

> Scott Wood  wrote on 2010/11/23 21:46:51:
> > "Only these" that you've found so far, for the board you've tried --
> 
> Yes, that is what I wrote.

Yes, I was just emphasizing that. :-)

> > is it worth adding another pre-relocation landmine to shrink the image
> > by 5%?  I don't miss the manual fixups we had to do under the old
> > relocation scheme.
> 
> -msingle-pic-base does not require LINK_OFF per se. It will shrink the image
> significantly for free. It enables impl. of true PIC and if you want to have
> that too you need LINK_OFF.

What is "true PIC" versus the rest of what -msingle-pic-base does, and
what are the advantages?

> > Is a missing LINK_OFF likely to result in a crash, or silent bad
> > behavior?  Will LINK_OFF be a no-op after relocation?
> 
> Either crash or garbage printed on the port.

Garbage possibly being empty strings that aren't noticed?

Or possibly bad values changing program flow in nonobvious ways?

> LINK_OFF is a NOP after relocation. It will be a NOP
> if link address == load address too.

"load address" being pre-relocation?  Currently these must be equal
(which doesn't seem particularly burdensome).

Seems like there would be a high risk for a developer of board A to add
new code that affects board B, and needs a manual relocation, but board
A doesn't use this or loads at the link address, so it doesn't show up.
Seems like a maintenance headache.

-Scott

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


Re: [U-Boot] [PATCH 3/7] Add support for third program loader

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 21:57:04 +0100
Wolfgang Denk  wrote:

> Dear Haiying Wang,
> 
> In message <1290525198.1932.3.ca...@haiying-laptop> you wrote:
> >
> > > Please use only one such name (CONFIG_SYS_TPL_BOOT).
> > CONFIG_SYS_TPL_BOOT is used as CONFIG_NAND_U_BOOT in Makefile and header
> > file.
> > CONFIG_TPL_BOOT is used as CONFIG_NAND_SPL in header file.
> 
> I'm sorry, but I have to admit that I don;t understand what you are
> trying to tell me.
> 
> Why do you need XXX when you use it as YYY? Why don't you use YYY
> directly?

CONFIG_NAND_U_BOOT indicates that there is a NAND SPL involved, and is
set in both build stages.

CONFIG_NAND_SPL is set only when building the SPL code itself.

When Haiying said "used as CONFIG_NAND_...", I believe she meant that
the difference between these two symbols is analagous to the difference
between the two NAND symbols -- not that they can be used
interchangeably.

I think the names need to be differentiated by more than just "_SYS",
though.

-Scott

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


Re: [U-Boot] [PATCH 0/6] RFC: True PIC on 83xx

2010-11-23 Thread Graeme Russ
On Wed, Nov 24, 2010 at 8:08 AM, Joakim Tjernlund
 wrote:
> Wolfgang Denk  wrote on 2010/11/23 21:52:11:
>>
>> Dear Joakim Tjernlund,
>>
>> In message <1290538131-12383-1-git-send-email-joakim.tjernl...@transmode.se> 
>> you wrote:
>> > Here goes my attempt to revive true PIC on ppc, starting with 83xx.
>> > This uses a a new gcc option(which I have just impl.) to add
>> > msingle-pic-base also save a lot of code:
>>
>> Is my inderstanding correct that this is a private, all new gcc
>> extension?  Do you have plans to submit it upstream?
>>
>> I appreciate your work, and I, too, would like to be able to do what
>> this patch series seems to acchieve, but I think we should not add
>> this to mainline when neither mainline gcc nor any of the "common"
>> tool chains (say, OE/Yocto/LF, Linaro, CodeSourcery, ...) supports it.
>
> -msingle-pic-base already exist for ARM. I impl. it for PowerPC too.
> I have submitted it upstream and I hope it will be accepted, it is ongoing
> but slowly as there are very few ppc maintainers.
>

I'm still trying to get my head around exactly what the end benifit of
having this functionality is.

I implemented fully position independent image support for warm-boot (i.e.
bootstraped from pre-initialised memory for build-load-test) for x86. But
x86 is out of line with other arches in that it initialises memory and
relocates into RAM _before_ exectuting any of the init sequence. It is
the relocation prior to executing any other core U-Boot code which allows
full PIC on x86 to work.

Now I'm in the process of aligning x86 with the other arches (create a
temporary stack, run init sequence, init RAM, relocate) and I am going
to lose my full PIC functionality. Now while not ideal, it is not a game
breaker for me (especially now that I can easily specify a secondary
board with a different TEXT_BASE trivially in boards.cfg)

Is there any real benifit to be gained from diverging the feature sets
and implementation details at the architecture level when we have been
spending so much time and effort aligning them (ELF Relocation etc)

Regards,

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Joakim Tjernlund
Scott Wood  wrote on 2010/11/23 22:20:58:
>
> On Tue, 23 Nov 2010 22:03:36 +0100
> Joakim Tjernlund  wrote:
>
> > Scott Wood  wrote on 2010/11/23 21:46:51:
> > > "Only these" that you've found so far, for the board you've tried --
> >
> > Yes, that is what I wrote.
>
> Yes, I was just emphasizing that. :-)
>
> > > is it worth adding another pre-relocation landmine to shrink the image
> > > by 5%?  I don't miss the manual fixups we had to do under the old
> > > relocation scheme.
> >
> > -msingle-pic-base does not require LINK_OFF per se. It will shrink the image
> > significantly for free. It enables impl. of true PIC and if you want to have
> > that too you need LINK_OFF.
>
> What is "true PIC" versus the rest of what -msingle-pic-base does, and
> what are the advantages?

Being able to load the same image to any address.
msingle-pic-base simple skips the PIC prologue and assumes the R30 is
already setup correctly. I a self contained env. like uboot this
is true for -fpic.
I use that property to copy the GOT to dcache,
relocate it there and point R30 to the GOT in dcache.

>
> > > Is a missing LINK_OFF likely to result in a crash, or silent bad
> > > behavior?  Will LINK_OFF be a no-op after relocation?
> >
> > Either crash or garbage printed on the port.
>
> Garbage possibly being empty strings that aren't noticed?
>
> Or possibly bad values changing program flow in nonobvious ways?

Impossible to say, I guess anything can happen.

>
> > LINK_OFF is a NOP after relocation. It will be a NOP
> > if link address == load address too.
>
> "load address" being pre-relocation?  Currently these must be equal
> (which doesn't seem particularly burdensome).

Yes, but in our case we update the boot in the field and we want to
make that safer by having two uboot areas but we don't want to carry around
two u-boot images.

I think Wolfgang had some other uses in mind too.

>
> Seems like there would be a high risk for a developer of board A to add
> new code that affects board B, and needs a manual relocation, but board
> A doesn't use this or loads at the link address, so it doesn't show up.
> Seems like a maintenance headache.

yes, it is a risk. One that can be minimized the more uses this function.

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Scott Wood
On Tue, 23 Nov 2010 23:14:06 +0100
Joakim Tjernlund  wrote:

> Scott Wood  wrote on 2010/11/23 22:20:58:
> > "load address" being pre-relocation?  Currently these must be equal
> > (which doesn't seem particularly burdensome).
> 
> Yes, but in our case we update the boot in the field and we want to
> make that safer by having two uboot areas but we don't want to carry around
> two u-boot images.

How about playing with BATs before entering C code, so that the image
always appears at the same effective address?

In fact, we could probably do something similar when copying to RAM as
well, and not need any sort of link relocation.

-Scott

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Wolfgang Denk
Dear Scott Wood,

In message <20101123163204.4f843...@udp111988uds.am.freescale.net> you wrote:
>
> How about playing with BATs before entering C code, so that the image
> always appears at the same effective address?

Not all systems have BATs.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Every program has at least one bug and can be shortened by  at  least
one  instruction  --  from  which,  by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Scott Wood
On Wed, 24 Nov 2010 00:03:13 +0100
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <20101123163204.4f843...@udp111988uds.am.freescale.net> you wrote:
> >
> > How about playing with BATs before entering C code, so that the image
> > always appears at the same effective address?
> 
> Not all systems have BATs.

I was speaking in the context of what he wanted to do with an 83xx board
-- but the concept applies to any hardware with an MMU that isn't too
painful to set up that early.

If someone wants to do this kind of thing on hardware that doesn't
meet that description, that's another matter -- if the the hardware
doesn't provide a nicer bank switching mechanism (e.g. p4080ds lets you
rotate the flash banks' physical addresses, rather than change the
reset vector), or an SRAM that U-Boot (or an SPL) could copy itself to
before C code, etc.

-Scott

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Graeme Russ
On Wed, Nov 24, 2010 at 10:24 AM, Scott Wood  wrote:
> On Wed, 24 Nov 2010 00:03:13 +0100
> Wolfgang Denk  wrote:
>
>> Dear Scott Wood,
>>
>> In message <20101123163204.4f843...@udp111988uds.am.freescale.net> you wrote:
>> >
>> > How about playing with BATs before entering C code, so that the image
>> > always appears at the same effective address?
>>
>> Not all systems have BATs.
>
> I was speaking in the context of what he wanted to do with an 83xx board
> -- but the concept applies to any hardware with an MMU that isn't too
> painful to set up that early.
>
> If someone wants to do this kind of thing on hardware that doesn't
> meet that description, that's another matter -- if the the hardware
> doesn't provide a nicer bank switching mechanism (e.g. p4080ds lets you
> rotate the flash banks' physical addresses, rather than change the
> reset vector), or an SRAM that U-Boot (or an SPL) could copy itself to
> before C code, etc.

It seems to me that we are applying at the architecture level a 'nice to
have' which may belong at the board level. How many vendors are going to
do a fancy 'two U-Boot images' trickery? Will it be (nearly) every 83xx
board?

I agree with Scott - If you want to do something that fancy, provide
support for it in your board hardware. I don't like the idea of diverging
the core feature-set available at the architecture level if those features
belong more at the SOC or Board level.

Regards,

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


Re: [U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

2010-11-23 Thread Joakim Tjernlund
Scott Wood  wrote on 2010/11/23 23:32:04:
>
> On Tue, 23 Nov 2010 23:14:06 +0100
> Joakim Tjernlund  wrote:
>
> > Scott Wood  wrote on 2010/11/23 22:20:58:
> > > "load address" being pre-relocation?  Currently these must be equal
> > > (which doesn't seem particularly burdensome).
> >
> > Yes, but in our case we update the boot in the field and we want to
> > make that safer by having two uboot areas but we don't want to carry around
> > two u-boot images.
>
> How about playing with BATs before entering C code, so that the image
> always appears at the same effective address?

hmm, never thought of that. The extra bonus would be that LINK_OFF should
not be needed either.

 Jocke

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


Re: [U-Boot] [PATCH] OMAP3: add CM-T35 board

2010-11-23 Thread Nishanth Menon
Mike Rapoport wrote, on 11/23/2010 01:29 AM:
minor comments follow:
[...]
 > diff --git a/board/cm_t35/cm_t35.h b/board/cm_t35/cm_t35.h
 > new file mode 100644
 > index 000..514017d
 > --- /dev/null
 > +++ b/board/cm_t35/cm_t35.h
[..]
> + /*DSS*/\
> + MUX_VAL(CP(DSS_PCLK),   (IDIS | PTD | DIS | M0)) /*DSS_PCLK*/\
> + MUX_VAL(CP(DSS_HSYNC),  (IDIS | PTD | DIS | M0)) /*DSS_HSYNC*/\
> + MUX_VAL(CP(DSS_VSYNC),  (IDIS | PTD | DIS | M0)) /*DSS_VSYNC*/\
> + MUX_VAL(CP(DSS_ACBIAS), (IDIS | PTD | DIS | M0)) /*DSS_ACBIAS*/\
> + MUX_VAL(CP(DSS_DATA0),  (IDIS | PTD | DIS | M0)) /*DSS_DATA0*/\
> + MUX_VAL(CP(DSS_DATA1),  (IDIS | PTD | DIS | M0)) /*DSS_DATA1*/\
> + MUX_VAL(CP(DSS_DATA2),  (IDIS | PTD | DIS | M0)) /*DSS_DATA2*/\
> + MUX_VAL(CP(DSS_DATA3),  (IDIS | PTD | DIS | M0)) /*DSS_DATA3*/\
> + MUX_VAL(CP(DSS_DATA4),  (IDIS | PTD | DIS | M0)) /*DSS_DATA4*/\
> + MUX_VAL(CP(DSS_DATA5),  (IDIS | PTD | DIS | M0)) /*DSS_DATA5*/\
> + MUX_VAL(CP(DSS_DATA6),  (IDIS | PTD | DIS | M0)) /*DSS_DATA6*/\
> + MUX_VAL(CP(DSS_DATA7),  (IDIS | PTD | DIS | M0)) /*DSS_DATA7*/\
> + MUX_VAL(CP(DSS_DATA8),  (IDIS | PTD | DIS | M0)) /*DSS_DATA8*/\
> + MUX_VAL(CP(DSS_DATA9),  (IDIS | PTD | DIS | M0)) /*DSS_DATA9*/\
> + MUX_VAL(CP(DSS_DATA10), (IDIS | PTD | DIS | M0)) /*DSS_DATA10*/\
> + MUX_VAL(CP(DSS_DATA11), (IDIS | PTD | DIS | M0)) /*DSS_DATA11*/\
> + MUX_VAL(CP(DSS_DATA12), (IDIS | PTD | DIS | M0)) /*DSS_DATA12*/\
> + MUX_VAL(CP(DSS_DATA13), (IDIS | PTD | DIS | M0)) /*DSS_DATA13*/\
> + MUX_VAL(CP(DSS_DATA14), (IDIS | PTD | DIS | M0)) /*DSS_DATA14*/\
> + MUX_VAL(CP(DSS_DATA15), (IDIS | PTD | DIS | M0)) /*DSS_DATA15*/\
> + MUX_VAL(CP(DSS_DATA16), (IDIS | PTD | DIS | M0)) /*DSS_DATA16*/\
> + MUX_VAL(CP(DSS_DATA17), (IDIS | PTD | DIS | M0)) /*DSS_DATA17*/\
> + MUX_VAL(CP(DSS_DATA18), (IDIS | PTD | DIS | M0)) /*DSS_DATA18*/\
> + MUX_VAL(CP(DSS_DATA19), (IDIS | PTD | DIS | M0)) /*DSS_DATA19*/\
> + MUX_VAL(CP(DSS_DATA20), (IDIS | PTD | DIS | M0)) /*DSS_DATA20*/\
> + MUX_VAL(CP(DSS_DATA21), (IDIS | PTD | DIS | M0)) /*DSS_DATA21*/\
> + MUX_VAL(CP(DSS_DATA22), (IDIS | PTD | DIS | M0)) /*DSS_DATA22*/\
> + MUX_VAL(CP(DSS_DATA23), (IDIS | PTD | DIS | M0)) /*DSS_DATA23*/\
Are you using bootlogo in CM-t35 u-boot?


> + MUX_VAL(CP(SYS_CLKOUT1),(IEN  | PTD | DIS | M0)) /*CLKOUT1*/\
> + MUX_VAL(CP(SYS_CLKOUT2),(IDIS | PTD | DIS | M4)) /*green LED*/\
might be better to state which GPIO than green led :)

> + MUX_VAL(CP(JTAG_nTRST), (IEN  | PTD | DIS | M0)) /*JTAG_nTRST*/\
> + MUX_VAL(CP(JTAG_TCK),   (IEN  | PTD | DIS | M0)) /*JTAG_TCK*/\
> + MUX_VAL(CP(JTAG_TMS),   (IEN  | PTD | DIS | M0)) /*JTAG_TMS*/\
> + MUX_VAL(CP(JTAG_TDI),   (IEN  | PTD | DIS | M0)) /*JTAG_TDI*/\

> + MUX_VAL(CP(SDRC_CKE0),  (IDIS | PTU | EN  | M0)) /*sdrc_cke0*/\
> + MUX_VAL(CP(SDRC_CKE1),  (IDIS | PTD | DIS | M7)) /*sdrc_cke1*/\
this tiny set probably should go along with sdrc to reflect proper 
functional set I guess.


> +
> +#endif
> diff --git a/board/cm_t35/config.mk b/board/cm_t35/config.mk
> new file mode 100644
> index 000..e81e283
> --- /dev/null
> +++ b/board/cm_t35/config.mk
> @@ -0,0 +1,30 @@
> +#
> +# (C) Copyright 2009
> +# CompuLab, Ltd.,
> +#
> +# 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
> +#
> +# Physical Address:
> +# 8000' (bank0)
> +#
> +# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
> +# (mem base + reserved)
> +
> +# For use with external or internal boots.
> +CONFIG_SYS_TEXT_BASE = 0x80008000
> diff --git a/boards.cfg b/boards.cfg
> index 6c2a667..e79b2d7 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -392,6 +392,7 @@ igep0020  arm armv7   igep0020isee
> omap3
>   igep0030arm armv7   igep0030iseeomap3
>   am3517_evm  arm armv7   am3517evm   logicpd 

Re: [U-Boot] MACHINE ID

2010-11-23 Thread Bedia, Vaibhav
On Wednesday, November 24, 2010 1:24 AM, Wolfgang Denk wrote:
> Dear "Bedia, Vaibhav",
> 
> In message
>  you
> wrote:  
>> 
>> This error is due to an incorrect machid being passed to the kernel.
>> 
>> This can be fixed using the following commands:
>> 
>> TI8168_EVM# setenv machid af0
> 
> Note that is is a workaround at best, not a fix. For a fix the
> incorrect value needs to be substituted in the board config file. 
> 
This issue was only with the first version of the code.
This was fixed in the subsequent versions and we will be submitting the patches 
to the U-Boot list for review.

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


[U-Boot] About "sf probe" command

2010-11-23 Thread wzc0066
Hello, i feel confused about the parameter of "sf probe" command.
Such as "sf  probe 0" or "sf  probe 1"

I have a 4M SPI Flash on my board, how should i specify the parameter of "sf
probe" ?
And what means of these parameters ?  ( the help info of this command is too
small which displayed in u-boot console )


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


[U-Boot] 69JQX-F2284

2010-11-23 Thread You Have Won
  GPG ALERT

InterGold/ GPG wishes to inform you of the results of the Strike-It-Lucky 
Global Online Mail End-of-Year Program held in Bolton, Lancashire - United 
Kingdom on Saturday 13th November, 2010. Your account has been picked as a 
winner.

This is what our latest winners had to say:

Lydie A - won 370,000 Pounds Sterling
"I've just won 370,000 Pounds. All of my dearest dreams and the dreams of my 
children will now come true and it is all thanks to you"

Emma S - won 550,000 Pounds Sterling
"I cannot explain the emotion when I saw all these zeros!! I cannot believe I 
won 550,000!"


* To begin your claim, contact the officer assigned to you using the details 
below:

Contact person: Simon Atkins
Email: ab89sc7hk65v...@jetable.org
Tel: +44 (0) 844 664 4633
  +44 (0) 844 664 4599

Winning Details:

Ref #: GPG-GEP/279-QE1118FK42
Batch #: 69JQX-F2284
Amount Won: 739,761.25 Pounds Sterling


This program was held in conjunction with major email providers in over 120 
countries worldwide.

Copyright © 2010 Grand Promotions Group, Inc. All Rights Reserved.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] ppc44x : build failure

2010-11-23 Thread Rupjyoti Sarmah
Hi Stefan,



The current u-boot  git tree fails to build for Canyonlands. It reports
“board/amcc/canyonlands/init.S:43: multiple definition of `tlbtab' ”

Was there any recent changes  ?



Regards,

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


Re: [U-Boot] [PATCH 7/7] 4xx: Cleanup for partial linking and --gc-sections

2010-11-23 Thread Stefan Roese
Hi Wolfgang,

On Tuesday 23 November 2010 20:55:03 Wolfgang Denk wrote:
> > > --- a/arch/powerpc/cpu/ppc4xx/Makefile
> > > +++ b/arch/powerpc/cpu/ppc4xx/Makefile
> > > @@ -37,9 +37,9 @@ COBJS   := 40x_spd_sdram.o
> > > 
> > >  ifndef CONFIG_NAND_SPL
> > >  ifndef CONFIG_NAND_U_BOOT
> > >  COBJS+= 44x_spd_ddr.o
> > > 
> > > +COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
> > > 
> > >  endif
> > >  endif
> > > 
> > > -COBJS-$(CONFIG_SDRAM_PPC4xx_IBM_DDR2) += 44x_spd_ddr2.o
> > 
> > This change introduces the problem with the kilauea/haleakala NAND
> > booting images. Yes, I am aware that without this change,
> > canyonlands_nand fails to build. I noticed this too right now. I'll send
> > another patch to fix this canyonlands_nand build problem shortly.
> 
> Without this, kilauea/haleakala NAND boot configurations load the
> 44x_spd_ddr2 init code, which you said was not the correct thing.
> 
> So which is correct?

I said that denali_spd_ddr2.c was incorrect. Note that that 44x_spd_ddr2.c not 
only has code for SPD type DDR2 inititalization but also fixed init code for 
this DDR2 controller. So its a bit of a misnomer. I can rename this file but I 
suggest to do this at a later time.

Please also note, that I sent a patch that fixes those problems "ppc4xx: Fix 
build problems of IBM DDR2 NAND booting targets". Its a add-on patch to your 
patchset and you can squash it into your patches if you prefer (I mentioned 
this in the patch comments of this patch).

Cheers,
Stefan

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


Re: [U-Boot] ppc44x : build failure

2010-11-23 Thread Stefan Roese
Hi Rup,

On Wednesday 24 November 2010 06:27:06 Rupjyoti Sarmah wrote:
> The current u-boot  git tree fails to build for Canyonlands. It reports
> “board/amcc/canyonlands/init.S:43: multiple definition of `tlbtab' ”
> 
> Was there any recent changes  ?

Yes, a lot of 4xx board fail to compile right now. We're working on patches to 
fix this:

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

Hopefully this will be resolved in a few days.

Cheers,
Stefan

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


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

2010-11-23 Thread Sughosh Ganu
hi,

On Tue Nov 23, 2010 at 01:31:46PM -0500, Ben Gardiner wrote:

> On Tue, Nov 23, 2010 at 1:25 PM, Paulraj, Sandeep  wrote:
> > I have been tracking this e-mail chain for some time now and I have lost 
> > track of which patches to apply in which order.
> >
> > Can someone please give me the correct order and the correct version of the 
> > patches?
> 
> The correct order and correct versions of the patches can be found in
> branch "testing-ea20-plus" of
> git://github.com/BenGardiner/u-boot-bg.git. The commit messages there
> do not include Sugosh's Tested-by: tag on the hawkboard patches, nor
> has he re-sent them to the ML yet.

  I will be sending the updated version based off Ben's tree
  tonight. Thanks.

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


[U-Boot] [PATCH v2] Fix NAND booting make target

2010-11-23 Thread Stefan Roese
Without this fix, the NAND_SPL target (in nand_spl/) is not built
at all for those boards defining NAND_U_BOOT=y in boards.cfg.

Signed-off-by: Stefan Roese 
Cc: Scott Wood 
---
v2:
- Don't change toplevel Makefile but fix boards.cfg as suggested
  by Scott Wood.

 boards.cfg |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index aa630ef..a4825f7 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -326,16 +326,16 @@ mcu25 powerpc ppc4xx  mcu25   
netstal
 alpr   powerpc ppc4xx  -   prodrive
 p3p440 powerpc ppc4xx  -   prodrive
 KAREF  powerpc ppc4xx  karef   sandburst
-acadia_nandpowerpc ppc4xx  acadia  amcc-   
acadia:NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
-bamboo_nandpowerpc ppc4xx  bamboo  amcc-   
bamboo:NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
-haleakala_nand powerpc ppc4xx  kilauea amcc-   
kilauea:NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
+acadia_nandpowerpc ppc4xx  acadia  amcc-   
acadia:NAND_U_BOOT,SYS_TEXT_BASE=0x0100
+bamboo_nandpowerpc ppc4xx  bamboo  amcc-   
bamboo:NAND_U_BOOT,SYS_TEXT_BASE=0x0100
+haleakala_nand powerpc ppc4xx  kilauea amcc-   
kilauea:NAND_U_BOOT,SYS_TEXT_BASE=0x0100
 kilaueapowerpc ppc4xx  kilauea amcc
-   kilauea:KILAUEA
-kilauea_nand   powerpc ppc4xx  kilauea amcc-   
kilauea:NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
+kilauea_nand   powerpc ppc4xx  kilauea amcc-   
kilauea:NAND_U_BOOT,SYS_TEXT_BASE=0x0100
 rainierpowerpc ppc4xx  sequoia amcc
-   sequoia:RAINIER
-rainier_nand   powerpc ppc4xx  sequoia amcc-   
sequoia:RAINIER,NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
+rainier_nand   powerpc ppc4xx  sequoia amcc-   
sequoia:RAINIER,NAND_U_BOOT,SYS_TEXT_BASE=0x0100
 rainier_rambootpowerpc ppc4xx  sequoia amcc
-   
sequoia:RAINIER,SYS_RAMBOOT,SYS_TEXT_BASE=0x0100,SYS_LDSCRIPT=board/amcc/sequoia/u-boot-ram.lds
 sequoiapowerpc ppc4xx  sequoia amcc
-   sequoia:SEQUOIA
-sequoia_nand   powerpc ppc4xx  sequoia amcc-   
sequoia:SEQUOIA,NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
+sequoia_nand   powerpc ppc4xx  sequoia amcc-   
sequoia:SEQUOIA,NAND_U_BOOT,SYS_TEXT_BASE=0x0100
 sequoia_rambootpowerpc ppc4xx  sequoia amcc
-   
sequoia:SEQUOIA,SYS_RAMBOOT,SYS_TEXT_BASE=0x0100,SYS_LDSCRIPT=board/amcc/sequoia/u-boot-ram.lds
 fx12mm powerpc ppc4xx  fx12mm  avnet   -   
fx12mm:SYS_TEXT_BASE=0x0300,SYS_LDSCRIPT=$(SRCTREE)/board/xilinx/ppc405-generic/u-boot-ram.lds
 fx12mm_flash   powerpc ppc4xx  fx12mm  avnet   -   
fx12mm:SYS_TEXT_BASE=0xFFCB,SYS_LDSCRIPT=$(SRCTREE)/board/xilinx/ppc405-generic/u-boot-rom.lds
@@ -345,7 +345,7 @@ ml507   powerpc ppc4xx  ml507   
xilinx  -   ml507:SYS_TEXT_BASE=0x0400,SYS_LDSCR
 ml507_flashpowerpc ppc4xx  ml507   xilinx  -   
ml507:SYS_TEXT_BASE=0xFE36,SYS_LDSCRIPT=$(SRCTREE)/board/xilinx/ppc440-generic/u-boot-rom.lds
 arches powerpc ppc4xx  canyonlands amcc-   
canyonlands:ARCHES
 glacierpowerpc ppc4xx  canyonlands amcc
-   canyonlands:GLACIER
-glacier_nand   powerpc ppc4xx  canyonlands amcc-   
canyonlands:GLACIER,NAND_U_BOOT=y,SYS_TEXT_BASE=0x0100
+glacier_nand   powerpc ppc4xx  canyonlands amcc-   
canyonlands:GLACIER,NAND_U_BOOT,SYS_TEXT_BASE=0x0100
 v5fx30tevalpowerpc ppc4xx  v5fx30teval avnet   -   
v5fx30teval:SYS_TEXT_BASE=0x0300,SYS_LDSCRIPT=$(SRCTREE)/board/xilinx/ppc440-generic/u-boot-ram.lds
 grsim  sparc   leon3   -   gaisler
 PM825_ROMBOOT_BIGFLASH   powerpc  mpc8260  pm826   -   -   
PM826:PCI,BOOT_ROM,FLASH_32MB,SYS_TEXT_BASE=0xFF80
@@ -689,8 +689,8 @@ PQ2FADS-VR_lowboot  powerpc  mpc8260mpc8260ads  
freescale   -   MPC8260ADS:ADSTYPE=C
 PQ2FADS-ZU_66MHz  powerpc  mpc8260 mpc8260ads  freescale   -   
MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=6600
 PQ2FADS-ZU_66MHz_lowboot  powerpc  mpc8260  mpc8260ads freescale   -   
MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=6600,SYS_TEXT_BASE=0xFF80
 PQ2FADS-ZU_lowboot  p

Re: [U-Boot] ppc44x : build failure

2010-11-23 Thread Wolfgang Denk
Dear Rupjyoti Sarmah,

In message  you wrote:
>
> The current u-boot  git tree fails to build for Canyonlands. It reports
> board/amcc/canyonlands/init.S:43: multiple definition of `tlbtab' 
> 
> Was there any recent changes  ?

Yes. See thread starting here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89401

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
Marriage is the sole cause of divorce.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] About "sf probe" command

2010-11-23 Thread Mike Frysinger
On Tuesday, November 23, 2010 23:46:53 wzc0066 wrote:
> Hello, i feel confused about the parameter of "sf probe" command.
> Such as "sf  probe 0" or "sf  probe 1"
> 
> I have a 4M SPI Flash on my board, how should i specify the parameter of
> "sf probe" ?
> And what means of these parameters ?  ( the help info of this command is
> too small which displayed in u-boot console )

so read the source.  it is clearly cropped to below 80 cols, so if your 
console is smaller than that, fix your console.

the help is pretty obvious to me:
sf probe 

the # is the SPI chip select.  only you know how you have the SPI flash 
connected on your board.
-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 V2 1/2] Davinci 8xx: Move common functions to share code

2010-11-23 Thread Sughosh Ganu
hi Ben,

On Fri Nov 19, 2010 at 10:16:09AM -0500, Ben Gardiner wrote:
> We are happy to see the omap-L138 support in u-boot moving forward. We
> would like to get either SD or USB (or both) omapL138 support upstream
> next. Does the ea20 have USB or SD? Will the hawkboard u-boot support
> include USB or SD support?

  Sorry for the late response. I will start working on getting the USB
  stuff in after the base port has gone into mainline. This might take
  some time though, as i am not much familiar with the USB related
  code.

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


Re: [U-Boot] [PATCH v5] Seagate FreeAgent DockStar support

2010-11-23 Thread Prafulla Wadaskar


> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Eric Cooper
> Sent: Tuesday, November 23, 2010 9:04 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH v5] Seagate FreeAgent DockStar support
> 
> start with sheevaplug configuration
> add modifications by Alexander Holler 
> change RAM definitions to one bank (128 MB)
> change ident string and prompt
> define MTD partitions and default environment variables
> add support for LEDs
> 
> Signed-off-by: Eric Cooper 
> ---
> Changes for v2:
>   - rebased on master, post ARM and kirkwood relocation changes
>   - squashed into single commit
> 
> Changes for v3:
>   - moved files to board/Seagate/dockstar/ and updated copyright notices
>   - removed dockstar entry from MAKEALL
>   - moved CONFIG_SYS_TEXT_BASE from config.mk to
> include/configs/dockstar.h
>   - corrected comment in board/Seagate/dockstar/kwbimage.cfg
> 
> Changes for v4:
>   - moved dockstar entry in boards.cfg to conform to intended sort order
> (other entries to be re-ordered in a subsequent patch)
> 
> Changes for v5:
>   - changed environment address to 0x6
> 
>  MAINTAINERS |4 +
>  board/Seagate/dockstar/Makefile |   54 +++
>  board/Seagate/dockstar/dockstar.c   |  181
> +++
>  board/Seagate/dockstar/dockstar.h   |   44 +
>  board/Seagate/dockstar/kwbimage.cfg |  165
> +++
>  boards.cfg  |1 +
>  include/configs/dockstar.h  |  125 
>  7 files changed, 574 insertions(+), 0 deletions(-)
>  create mode 100644 board/Seagate/dockstar/Makefile
>  create mode 100644 board/Seagate/dockstar/dockstar.c
>  create mode 100644 board/Seagate/dockstar/dockstar.h
>  create mode 100644 board/Seagate/dockstar/kwbimage.cfg
>  create mode 100644 include/configs/dockstar.h

Applied to u-boot marvell.com master branch

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


[U-Boot] [PATCH] Kirkwood: grouped all Kirkwood boards

2010-11-23 Thread Prafulla Wadaskar
Kirkwood based boards where scattered in boards.cfg
All such boards were grouped together
The ordering is fixed

Signed-off-by: Prafulla Wadaskar 
---
 boards.cfg |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 9e03f81..5d9638e 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -51,9 +51,6 @@ meesc arm arm926ejs   -   esd 
at91
 otc570 arm arm926ejs   -   esd at91
 pm9261 arm arm926ejs   -   ronetix at91
 pm9263 arm arm926ejs   -   ronetix at91
-suen3  arm arm926ejs   km_arm  keymile kirkwood
-rd6281aarm arm926ejs   -   Marvell 
kirkwood
-dockstar   arm arm926ejs   -   Seagate kirkwood
 jadecpuarm arm926ejs   jadecpu syteco  
mb86r0x
 mx51evkarm armv7   mx51evk freescale   
mx5
 vision2arm armv7   vision2 ttcontrol   
mx5
@@ -373,10 +370,13 @@ davinci_sffsdrarm arm926ejs   sffsdr  
davinci davinci
 davinci_sonata arm arm926ejs   sonata  davinci davinci
 da830evm   arm arm926ejs   da8xxevmdavinci davinci
 da850evm   arm arm926ejs   da8xxevmdavinci davinci
+dockstar   arm arm926ejs   -   Seagate kirkwood
 guruplug   arm arm926ejs   -   Marvell kirkwood
 mv88f6281gtw_gearm arm926ejs   -   Marvell 
kirkwood
 openrd_basearm arm926ejs   -   Marvell kirkwood
+rd6281aarm arm926ejs   -   Marvell 
kirkwood
 sheevaplug arm arm926ejs   -   Marvell kirkwood
+suen3  arm arm926ejs   km_arm  keymile kirkwood
 imx27lite  arm arm926ejs   imx27lite   logicpd mx27
 magnesium  arm arm926ejs   imx27lite   logicpd mx27
 omap5912oskarm arm926ejs   -   ti  omap
-- 
1.5.3.3

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