Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

2011-01-25 Thread Mike Rapoport
On 01/22/11 01:06, Tom Warren wrote:
> Signed-off-by: Tom Warren 
> ---

[ snip ]

> +/*
> + * Routine: pin_mux_uart
> + * Description: setup the pin muxes/tristate values for a UART
> + */
> +static void pin_mux_uart(void)
> +{
> + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
> + u32 reg;
> +
> +#if CONFIG_TEGRA2_ENABLE_UARTA
> + reg = readl(&pmt->pmt_ctl_c);
> + reg &= 0xFFF0;  /* IRRX_/IRTX_SEL [19:16] = 00 UARTA */
> + writel(reg, &pmt->pmt_ctl_c);
> +
> + reg = readl(&pmt->pmt_tri_a);
> + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */
> + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */
> + writel(reg, &pmt->pmt_tri_a);
> +#endif   /* CONFIG_TEGRA2_ENABLE_UARTA */
> +#if CONFIG_TEGRA2_ENABLE_UARTD
> + reg = readl(&pmt->pmt_ctl_b);
> + reg &= 0xFFF3;  /* GMC_SEL [3:2] = 00, UARTD */
> + writel(reg, &pmt->pmt_ctl_b);
> +
> + reg = readl(&pmt->pmt_tri_a);
> + reg &= ~Z_GMC;  /* Z_GMC = normal (0) */
> + writel(reg, &pmt->pmt_tri_a);
> +#endif   /* CONFIG_TEGRA2_ENABLE_UARTD */

As I've already pointed out (1) this covers only one possibility of UART pin
muxing options. I agree that it makes sense when this is a part of the
board-specific code. However, forcing specific pins configuration in the generic
driver seems problematic to me, even if most Tegra2 boards use the same
configuration.
As a side note, I'd prefer to have all the pin multiplexing defined in one place
in board file rather than scattered among different drivers.

(1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233


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


Re: [U-Boot] U-Boot v2010.12 released - Merge Window OPEN

2011-01-25 Thread Alexander Holler
Hello,

Am 22.12.2010 21:15, schrieb Wolfgang Denk:

> *
> * Currently,>100 ARM boards are *broken* and *do not compile*. *
> *
>
> Board maintainers or othe rinterested parties are requested to
> adapt their boards to the new code in the timeframe of the
> upcoming release v2010.03; all boards that have not been converted
> by then, i. e. that are still broken then, are considered
> unmaintained and without interest to the community and will be
> removed.

Maybe just a

#error Code for this board doesn't compile since at least #date#

or a similiar message in foo_config.h would be a way to inform people 
early that the code needs some work.

This way the source for the board could be visible for some more time in 
the repository.

Regards,

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


[U-Boot] Default base for numbers

2011-01-25 Thread Alexander Holler
Hello,

I've stumbled over the fact that the length parameter for sha1sum uses 
16 as default base, which I found a bit confusing.

E.g.
-
U-Boot>> tftp $loadaddr uImage
...
done
Bytes transferred = 1976384 (1e2840 hex)
U-Boot>> sha1sum $loadaddr 1976384
SHA1 for 0080 ... 02176383 ==> 8d9cc7b167b6d1471d73d46cfc3b374091de88a6
U-Boot>> sha1sum $loadaddr 0x1e2840
SHA1 for 0080 ... 009e283f ==> fde54f7409c785b7929d36624f77f71abd30282a
-
(The second one is correct)

Is the base 16 as default for numbers common for commands in u-boot or 
is that just a problem of md5sum and sha1sum?

Regards,

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


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

2011-01-25 Thread Kumar Gala

On Jan 25, 2011, at 12:36 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <356989c7-fa92-46d5-9fb6-5f9332ecb...@kernel.crashing.org> you 
> wrote:
>> 
>> The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
>> 
>> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
>> CFLAGS += -mhard-float -fkeep-inline-functions
>> 
>> We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir 
>> if CONFIG_POST_FPU isn't set in CONFIG_POST.
> 
> This might solve the warning in most cases - but what abut these where
> CONFIG_POST_FPU is defined?  I mean, it is inherent that these tests
> need to execute FP instructions.
> 
> Best regards,
> 
> Wolfgang Denk

Actually we've dealt with this already:

commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
Author: Yuri Tikhonov 
Date:   Sat Dec 20 14:54:21 2008 +0300

FPU POST: fix warnings when building with 2.18 binutils

When compile u-boot with the 2.18 binutils the following
warning messages for each object file in post/lib_ppc/fpu/ is
produced at the linking stage:

post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float
...


...

However I think we just need to move the code a bit.  Will post a patch

- k

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


[U-Boot] [PATCH] arm, keymile: remove unneeded code

2011-01-25 Thread Holger Brunck
On first HW versions the BOCO FPGA was behind a MUX device. These
HW versions are not supported anymore. And therefore this code can
be removed, it is already unused.

Signed-off-by: Holger Brunck 
---
 board/keymile/km_arm/km_arm.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index 2e20644..dcf0f42 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -41,9 +41,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static int io_dev;
-extern I2C_MUX_DEVICE *i2c_mux_ident_muxstring (uchar *buf);
-
 /* Multi-Purpose Pins Functionality configuration */
 u32 kwmpp_config[] = {
MPP0_NF_IO2,
@@ -122,13 +119,9 @@ int ethernet_present(void)
 
 int misc_init_r(void)
 {
-   I2C_MUX_DEVICE  *i2cdev;
char *str;
int mach_type;
 
-   /* add I2C Bus for I/O Expander */
-   i2cdev = i2c_mux_ident_muxstring((uchar *)"pca9554a:70:a");
-   io_dev = i2cdev->busid;
puts("Piggy:");
if (ethernet_present() == 0)
puts (" not");
-- 
1.7.0.5

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


[U-Boot] [PATCH] powerpc: Fix FPU post related link warnings

2011-01-25 Thread Kumar Gala
If we built POST on PPC's that didn't enable CONFIG_SYS_POST_FPU we'd
get the following warning with newer toolchains:

powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o
  uses hard float, libpost.o uses soft float

We actually worked around this sometime ago with the following commit:

commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
Author: Yuri Tikhonov 
Date:   Sat Dec 20 14:54:21 2008 +0300

   FPU POST: fix warnings when building with 2.18 binutils

However, this only took into effect if CONFIG_SYS_POST_FPU was enabled.
We can simply move the GNU_FPOST_ATTR out of the CONFIG_SYS_POST_FPU
ifdef block to address the issue.

Signed-off-by: Kumar Gala 
---

Wolfgang, I request we think about include this patch in v2011.03 tree so we
can all stop getting these build warnings :)

- k

 post/lib_powerpc/fpu/20001122-1.c |4 ++--
 post/lib_powerpc/fpu/20010114-2.c |4 ++--
 post/lib_powerpc/fpu/20010226-1.c |4 ++--
 post/lib_powerpc/fpu/980619-1.c   |4 ++--
 post/lib_powerpc/fpu/acc1.c   |4 ++--
 post/lib_powerpc/fpu/compare-fp-1.c   |4 ++--
 post/lib_powerpc/fpu/fpu.c|4 ++--
 post/lib_powerpc/fpu/mul-subnormal-single-1.c |4 ++--
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/post/lib_powerpc/fpu/20001122-1.c 
b/post/lib_powerpc/fpu/20001122-1.c
index bef80c5..4af300d 100644
--- a/post/lib_powerpc/fpu/20001122-1.c
+++ b/post/lib_powerpc/fpu/20001122-1.c
@@ -28,10 +28,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 int fpu_post_test_math1 (void)
 {
volatile double a, *p;
diff --git a/post/lib_powerpc/fpu/20010114-2.c 
b/post/lib_powerpc/fpu/20010114-2.c
index ee564e8..dab4d7e 100644
--- a/post/lib_powerpc/fpu/20010114-2.c
+++ b/post/lib_powerpc/fpu/20010114-2.c
@@ -28,10 +28,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 static float rintf (float x)
 {
volatile float TWO23 = 8388608.0;
diff --git a/post/lib_powerpc/fpu/20010226-1.c 
b/post/lib_powerpc/fpu/20010226-1.c
index 099ca4a..c644bc9 100644
--- a/post/lib_powerpc/fpu/20010226-1.c
+++ b/post/lib_powerpc/fpu/20010226-1.c
@@ -28,10 +28,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 int fpu_post_test_math3 (void)
 {
volatile long double dfrom = 1.1;
diff --git a/post/lib_powerpc/fpu/980619-1.c b/post/lib_powerpc/fpu/980619-1.c
index 46a31ae..0c195c1 100644
--- a/post/lib_powerpc/fpu/980619-1.c
+++ b/post/lib_powerpc/fpu/980619-1.c
@@ -28,10 +28,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 int fpu_post_test_math4 (void)
 {
volatile float reale = 1.0f;
diff --git a/post/lib_powerpc/fpu/acc1.c b/post/lib_powerpc/fpu/acc1.c
index 9fca9b3..4dc1362 100644
--- a/post/lib_powerpc/fpu/acc1.c
+++ b/post/lib_powerpc/fpu/acc1.c
@@ -28,10 +28,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 static double func (const double *array)
 {
double d = *array;
diff --git a/post/lib_powerpc/fpu/compare-fp-1.c 
b/post/lib_powerpc/fpu/compare-fp-1.c
index f836b29..a0859f8 100644
--- a/post/lib_powerpc/fpu/compare-fp-1.c
+++ b/post/lib_powerpc/fpu/compare-fp-1.c
@@ -30,10 +30,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 static int failed;
 
 #define TEST(c) if ((c) != ok) failed++
diff --git a/post/lib_powerpc/fpu/fpu.c b/post/lib_powerpc/fpu/fpu.c
index 3f3adea..a4369f1 100644
--- a/post/lib_powerpc/fpu/fpu.c
+++ b/post/lib_powerpc/fpu/fpu.c
@@ -36,12 +36,12 @@
 
 #include 
 
+GNU_FPOST_ATTR
+
 #if CONFIG_POST & CONFIG_SYS_POST_FPU
 
 #include 
 
-GNU_FPOST_ATTR
-
 extern int fpu_status (void);
 extern void fpu_enable (void);
 extern void fpu_disable (void);
diff --git a/post/lib_powerpc/fpu/mul-subnormal-single-1.c 
b/post/lib_powerpc/fpu/mul-subnormal-single-1.c
index 1f3732d..23a3f30 100644
--- a/post/lib_powerpc/fpu/mul-subnormal-single-1.c
+++ b/post/lib_powerpc/fpu/mul-subnormal-single-1.c
@@ -30,10 +30,10 @@
 
 #include 
 
-#if CONFIG_POST & CONFIG_SYS_POST_FPU
-
 GNU_FPOST_ATTR
 
+#if CONFIG_POST & CONFIG_SYS_POST_FPU
+
 union uf
 {
unsigned int u;
-- 
1.7.2.3

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


Re: [U-Boot] Default base for numbers

2011-01-25 Thread Wolfgang Denk
Dear Alexander Holler,

In message <4d3e8f9d.7040...@ahsoftware.de> you wrote:
> 
> I've stumbled over the fact that the length parameter for sha1sum uses 
> 16 as default base, which I found a bit confusing.

Read the documentation.

> Is the base 16 as default for numbers common for commands in u-boot or 
> is that just a problem of md5sum and sha1sum?

With very few exceptions all commands use base 16 input.  I recommend
you start reading the manual.

Best regards,

Wolfgang Denk

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


[U-Boot] [PATCH] powerpc/85xx: Extend ethernet device tree stashing parameters for "fsl, etsec2"

2011-01-25 Thread Kumar Gala
From: Pankaj Chauhan 

In a manner similar to passing ethernet stashing parameters into device
tree for "gianfar", extend the support to the "fsl,etsec2" as well.

Signed-off-by: Pankaj Chauhan 
Signed-off-by: Sandeep Gopalpet 
Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/fdt.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 00fa752..6ed0284 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -338,6 +338,9 @@ void fdt_add_enet_stashing(void *fdt)
do_fixup_by_compat_u32(fdt, "gianfar", "rx-stash-len", 96, 1);
 
do_fixup_by_compat_u32(fdt, "gianfar", "rx-stash-idx", 0, 1);
+   do_fixup_by_compat(fdt, "fsl,etsec2", "bd-stash", NULL, 0, 1);
+   do_fixup_by_compat_u32(fdt, "fsl,etsec2", "rx-stash-len", 96, 1);
+   do_fixup_by_compat_u32(fdt, "fsl,etsec2", "rx-stash-idx", 0, 1);
 }
 
 #if defined(CONFIG_SYS_DPAA_FMAN) || defined(CONFIG_SYS_DPAA_PME)
-- 
1.7.2.3

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


Re: [U-Boot] Default base for numbers

2011-01-25 Thread Alexander Holler
Am 25.01.2011 10:16, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<4d3e8f9d.7040...@ahsoftware.de>  you wrote:
>>
>> I've stumbled over the fact that the length parameter for sha1sum uses
>> 16 as default base, which I found a bit confusing.
>
> Read the documentation.
>
>> Is the base 16 as default for numbers common for commands in u-boot or
>> is that just a problem of md5sum and sha1sum?
>
> With very few exceptions all commands use base 16 input.  I recommend
> you start reading the manual.

Thanks for the pointer, if someone else is interested, it is described 
in chapter 5.9. U-Boot Command Line Interface. Easy to find. ;)

Regards,

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


[U-Boot] [PATCH] Change the visible output for transfers to display hex numbers

2011-01-25 Thread Alexander Holler
When files were transfered the output is currently
-
Bytes transferred = 1976384 (1e2840 hex)
-
Using the decimal length as input for other commands conflicts with the
the default base of 16 needed.

Change the output to
-
Bytes transferred = 0x1e2840 (1976384 bytes)
-
to reflect what should be used as input for other commands.

Signed-off-by: Alexander Holler 
---
 net/net.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/net.c b/net/net.c
index a609632..a454411 100644
--- a/net/net.c
+++ b/net/net.c
@@ -528,7 +528,7 @@ restart:
case NETLOOP_SUCCESS:
if (NetBootFileXferSize > 0) {
char buf[20];
-   printf("Bytes transferred = %ld (%lx hex)\n",
+   printf("Bytes transferred = 0x%lx (%ld 
bytes)\n",
NetBootFileXferSize,
NetBootFileXferSize);
sprintf(buf, "%lX", NetBootFileXferSize);
-- 
1.7.3.4

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


[U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig
Hi,


I change my uboot version and after it the uboot don't starts the same 
linux kernel:

## Booting kernel from Legacy Image at 1006 ...
Image Name:   Linux Kernel
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:1178673 Bytes = 1.1 MiB
Load Address: 20008000
Entry Point:  20008000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...

*LOG END*


It's a board simular to the at91rm9200dk. I start the kernel with

bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs 
ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006

run bootcmd2

Can anybody give me a hint where I had to search for the error?



Mit freundlichen Grüßen

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


[U-Boot] [PATCH] ppc, mgcoge: add DIP switch detection

2011-01-25 Thread Holger Brunck
From: Andreas Huber 

This reads the DIP switch on mgcoge. The DIP switch is connected to
the BFTICU (0x4089) FPGA. If the DIP switch is set the environment
variable 'actual_bank' is set to 0 and starts the SW in bank0.

Signed-off-by: Andreas Huber 
Signed-off-by: Holger Brunck 
---
 board/keymile/mgcoge/mgcoge.c |   18 ++
 include/configs/mgcoge.h  |5 +
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/board/keymile/mgcoge/mgcoge.c b/board/keymile/mgcoge/mgcoge.c
index 5c9496c..5dcdf37 100644
--- a/board/keymile/mgcoge/mgcoge.c
+++ b/board/keymile/mgcoge/mgcoge.c
@@ -293,6 +293,24 @@ int checkboard(void)
return 0;
 }
 
+#define DIPSWITCH_OFFSET 0x89
+#define DIPSWITCH_MASK   0x0f
+
+int last_stage_init(void)
+{
+   u8 dip_switch;
+   /* Dip switch */
+   dip_switch = readb(CONFIG_SYS_BFTICU_BASE + DIPSWITCH_OFFSET);
+   dip_switch &= DIPSWITCH_MASK;
+   /* dip switch 'full reset' or 'db erase' */
+   if (dip_switch & 0x1 || dip_switch & 0x2) {
+   /* start bootloader */
+   puts("DIP:   Enabled\n");
+   setenv("actual_bank", "0");
+   }
+   return 0;
+}
+
 /*
  * Early board initalization.
  */
diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
index 6dec0ee..f1bd32a 100644
--- a/include/configs/mgcoge.h
+++ b/include/configs/mgcoge.h
@@ -348,4 +348,9 @@
 #define OF_TBCLK   (bd->bi_busfreq / 4)
 #define OF_STDOUT_PATH "/soc/cpm/serial@11a90"
 
+/* enable last_stage_init */
+#define CONFIG_LAST_STAGE_INIT  1
+/* bfticu address */
+#define CONFIG_SYS_BFTICU_BASE  0x4000
+
 #endif /* __CONFIG_H */
-- 
1.7.0.5

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


Re: [U-Boot] [PATCH] Change the visible output for transfers to display hex numbers

2011-01-25 Thread Wolfgang Denk
Dear Alexander Holler,

In message <1295950537-12363-1-git-send-email-hol...@ahsoftware.de> you wrote:
> When files were transfered the output is currently
> -
> Bytes transferred = 1976384 (1e2840 hex)
> -
> Using the decimal length as input for other commands conflicts with the
> the default base of 16 needed.
> 
> Change the output to
> -
> Bytes transferred = 0x1e2840 (1976384 bytes)
> -
> to reflect what should be used as input for other commands.

In which way does this reflect what "should be used as input for other
commands"?

I don't even understand why you use this manually with copy & paste.

Why don't you simply refer to the ${filesize} variable?


In any case, if you want to change this format, you must change _all_
occurrences of it, i. e. include all the commands that load from
external storage (ide, usb, scsi, sata, nand, dataflash, SPI-Flash,
...).


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
Lots of folks confuse bad management with destiny.   -- Frank Hubbard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig
Hi,


I change my uboot version and after it the uboot don't starts the same 
linux kernel:

## Booting kernel from Legacy Image at 1006 ...
Image Name:   Linux Kernel
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:1178673 Bytes = 1.1 MiB
Load Address: 20008000
Entry Point:  20008000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...

*LOG END*


It's a board simular to the at91rm9200dk. I start the kernel with

bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs 
ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006

run bootcmd2

Can anybody give me a hint where I had to search for the error?



Mit freundlichen Grüßen

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


Re: [U-Boot] [PATCH] Change the visible output for transfers to display hex numbers

2011-01-25 Thread Alexander Holler
Hello,

Am 25.01.2011 11:27, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<1295950537-12363-1-git-send-email-hol...@ahsoftware.de>  you wrote:
>> When files were transfered the output is currently
>> -
>> Bytes transferred = 1976384 (1e2840 hex)
>> -
>> Using the decimal length as input for other commands conflicts with the
>> the default base of 16 needed.
>>
>> Change the output to
>> -
>> Bytes transferred = 0x1e2840 (1976384 bytes)
>> -
>> to reflect what should be used as input for other commands.
>
> In which way does this reflect what "should be used as input for other
> commands"?
>
> I don't even understand why you use this manually with copy&  paste.
>
> Why don't you simply refer to the ${filesize} variable?

TIMTOWTDI

> In any case, if you want to change this format, you must change _all_
> occurrences of it, i. e. include all the commands that load from
> external storage (ide, usb, scsi, sata, nand, dataflash, SPI-Flash,
> ...).

Than I prefer not to change something and live with that 
unorthogonality. Besides several READMEs, net/net.c is the only source where

git grep "Bytes transferred"

shows that such an output is used.

Regards,

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


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Reinhard Meyer
Dear Maik Hänig,
> Hi,
> 
> 
> I change my uboot version and after it the uboot don't starts the same 
> linux kernel:
> 
> ## Booting kernel from Legacy Image at 1006 ...
_
> Image Name:   Linux Kernel
> Image Type:   ARM Linux Kernel Image (gzip compressed)
> Data Size:1178673 Bytes = 1.1 MiB
> Load Address: 20008000
> Entry Point:  20008000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> 
> Starting kernel ...
> 
> *LOG END*
> 
> 
> It's a board simular to the at91rm9200dk. I start the kernel with
> 
> bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs 
> ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006
__
> 
> run bootcmd2

First, I don't understand why those two addresses are not the same.

Then, are you sure your "bootcmd2" ist really what you think it is?
Try a "printenv" and see whats really there.

Should you not have a "console=xxx" in your kernel parameters?

Besides once "Starting kernel ..." shows, u-boot is about to give control
to the kernel, all future output would be from the kernel itself, probably
needing a sane "console=xxx" parameter.

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


Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux

2011-01-25 Thread Matthias Weißer
Am 24.01.2011 21:07, schrieb Wolfgang Denk:
> OK - so which results do you see in reallife use, say when loading and
> booting an OS? How much boot time can be saved?

All tests are done with jadecpu

| HEAD(1)| HEAD(1)| HEAD(2)| HEAD(2)|
|| +patch || +patch |
---+++++
Reset to prompt|  438ms |  330ms |  228ms |  120ms |
|||||
TFTP a 3MB img | 4782ms | 3428ms | 3245ms | 2820ms |
|||||
FATLOAD USB a 3MB img* | 8515ms | 8510ms | -- | -- |
|||||
BOOTM LZO img in RAM   | 3473ms | 3168ms |  592ms |  592ms |
  where CRC is  |  615ms |  615ms |   54ms |   54ms |
  uncompress| 2460ms | 2462ms |  450ms |  451ms |
  final boot_elf|  376ms |   68ms |   65ms |   65ms |
|||||
BOOTM LZO img in FLASH | 3207ms | 2902ms | 1050ms | 1050ms |
  where CRC is  |  600ms |  600ms |  135ms |  135ms |
  uncompress| 2209ms | 2211ms |  828ms |  828ms |
  final boot_elf|  376ms |   68ms |   65ms |   65ms |

(1) No dcache
(2) dcache enabled in board_init
*Does not work when dcache is on

I think we can see that there seems to be no negativ impact of theses 
patches when only execution speed is taken into consideration. The gain 
is noticable when caching is not used or not activated. For pure RAM to 
RAM copy when caching is activated the patch didn't change anything.

Here are some additional numbers for copying a 1.4MB image from NOR to RAM:

HEAD  : 134ms
HEAD + patch  : 72ms
HEAD + dcache : 120ms
HEAD + dcache + patch : 70ms

So, for copy actions from flash to RAM there is also an improvement. As 
boot times are a bit critical or us every improvement > 10ms is 
interesting for us.

> I guess the speed improvemnt you see for a few large copy operations
> is just one side - probably there will be slower excution (due to the
> effort to set up the operations) for the (many more frequent) small
> operations.  In addition, there is an increase of the memory footprint
> of nearly 1 kB.
 >
> I think additional measuremnts need to be done - for example, we
> should check how the execution times change for typical operations
> like TFTP download, reading from NAND flash and MMC/SDcard, booting a
> Linux kernel etc.

As the test above show there is no negative performance impact with the 
test cases I have done. As we don't use Linux here I can't test this. 
Maybe someone other can jump in here.

> Also, it should be possible to enable this feature consditionally, so
> users can decide wether speed or size is more important in their
> configurations.

Would it be an option to use the CONFIG entries CONFIG_USE_ARCH_MEMCPY 
and CONFIG_USE_ARCH_MEMSET to enable that feature? If that is OK I can 
send a new version of the patch. The only problem I see with this 
approach is that there are architectures which already have their own 
implementations which are then not affected by these config options.


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


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig
Dear Reinhard,

sorry I copied the wrong log:

U-Boot 2010.09 (Jan 24 2011 - 17:45:54)

I2C:   ready
DRAM:  64 MiB
Flash: 32 MiB
In:serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting kernel from Legacy Image at 3006 ...
Image Name:   Linux Kernel
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:1084127 Bytes = 1 MiB
Load Address: 20008000
Entry Point:  20008000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...

I have to kernel Images in flash. The bootcmd is copied from printenv. 
With the uboot version 2009.01 it works well. Is it nessesary to set a 
console parameter in the bootcmd in uboot version 2010.09?


Mit freundlichen Grüßen

Maik Hänig

Am 25.01.2011 11:54, schrieb Reinhard Meyer:
> Dear Maik Hänig,
>> Hi,
>>
>>
>> I change my uboot version and after it the uboot don't starts the same
>> linux kernel:
>>
>> ## Booting kernel from Legacy Image at 1006 ...
> _
>>  Image Name:   Linux Kernel
>>  Image Type:   ARM Linux Kernel Image (gzip compressed)
>>  Data Size:1178673 Bytes = 1.1 MiB
>>  Load Address: 20008000
>>  Entry Point:  20008000
>>  Verifying Checksum ... OK
>>  Uncompressing Kernel Image ... OK
>>
>> Starting kernel ...
>>
>> *LOG END*
>>
>>
>> It's a board simular to the at91rm9200dk. I start the kernel with
>>
>> bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs
>> ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006
> __
>>
>> run bootcmd2
>
> First, I don't understand why those two addresses are not the same.
>
> Then, are you sure your "bootcmd2" ist really what you think it is?
> Try a "printenv" and see whats really there.
>
> Should you not have a "console=xxx" in your kernel parameters?
>
> Besides once "Starting kernel ..." shows, u-boot is about to give control
> to the kernel, all future output would be from the kernel itself, probably
> needing a sane "console=xxx" parameter.
>
> Best Regards,
> Reinhard
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig
Dear Reinhard Meyer,

I tried it with:

setenv bootargs root=/dev/mtdblock9 rootfstype=jffs2 console=ttyS4 
ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006

but nothing the error is still there. The console is set in the board 
init of the linux kernel.

I changed only the uboot verion. The linux kernel and the rootfilesystem 
are the same.


Mit freundlichen Grüßen

Maik Hänig

Am 25.01.2011 12:03, schrieb Maik Hänig:
> Dear Reinhard,
>
> sorry I copied the wrong log:
>
> U-Boot 2010.09 (Jan 24 2011 - 17:45:54)
>
> I2C:   ready
> DRAM:  64 MiB
> Flash: 32 MiB
> In:serial
> Out:   serial
> Err:   serial
> Hit any key to stop autoboot:  0
> ## Booting kernel from Legacy Image at 3006 ...
>  Image Name:   Linux Kernel
>  Image Type:   ARM Linux Kernel Image (gzip compressed)
>  Data Size:1084127 Bytes = 1 MiB
>  Load Address: 20008000
>  Entry Point:  20008000
>  Verifying Checksum ... OK
>  Uncompressing Kernel Image ... OK
>
> Starting kernel ...
>
> I have to kernel Images in flash. The bootcmd is copied from printenv.
> With the uboot version 2009.01 it works well. Is it nessesary to set a
> console parameter in the bootcmd in uboot version 2010.09?
>
>
> Mit freundlichen Grüßen
>
> Maik Hänig
>
> Am 25.01.2011 11:54, schrieb Reinhard Meyer:
>> Dear Maik Hänig,
>>> Hi,
>>>
>>>
>>> I change my uboot version and after it the uboot don't starts the same
>>> linux kernel:
>>>
>>> ## Booting kernel from Legacy Image at 1006 ...
>> _
>>>   Image Name:   Linux Kernel
>>>   Image Type:   ARM Linux Kernel Image (gzip compressed)
>>>   Data Size:1178673 Bytes = 1.1 MiB
>>>   Load Address: 20008000
>>>   Entry Point:  20008000
>>>   Verifying Checksum ... OK
>>>   Uncompressing Kernel Image ... OK
>>>
>>> Starting kernel ...
>>>
>>> *LOG END*
>>>
>>>
>>> It's a board simular to the at91rm9200dk. I start the kernel with
>>>
>>> bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs
>>> ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006
>> __
>>>
>>> run bootcmd2
>>
>> First, I don't understand why those two addresses are not the same.
>>
>> Then, are you sure your "bootcmd2" ist really what you think it is?
>> Try a "printenv" and see whats really there.
>>
>> Should you not have a "console=xxx" in your kernel parameters?
>>
>> Besides once "Starting kernel ..." shows, u-boot is about to give control
>> to the kernel, all future output would be from the kernel itself, probably
>> needing a sane "console=xxx" parameter.
>>
>> Best Regards,
>> Reinhard
>>
>>
> ___
> 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] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Andreas Bießmann
Dear Maik Hänig,

please do not hijack a thread!

Am 25.01.2011 12:03, schrieb Maik Hänig:
> Dear Reinhard,
> 
> sorry I copied the wrong log:
> 
> U-Boot 2010.09 (Jan 24 2011 - 17:45:54)

Ok, you use 2010.09. This was last release before relocate changes.
Therefore it has no connection with the relocation stuff.

> I2C:   ready
> DRAM:  64 MiB
> Flash: 32 MiB
> In:serial
> Out:   serial
> Err:   serial
> Hit any key to stop autoboot:  0
> ## Booting kernel from Legacy Image at 3006 ...
> Image Name:   Linux Kernel
> Image Type:   ARM Linux Kernel Image (gzip compressed)
> Data Size:1084127 Bytes = 1 MiB
> Load Address: 20008000
> Entry Point:  20008000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> 
> Starting kernel ...
> 
> I have to kernel Images in flash. The bootcmd is copied from printenv. 
> With the uboot version 2009.01 it works well. 


> Is it nessesary to set a 
> console parameter in the bootcmd in uboot version 2010.09?

We don't know your configuration. What tells your working setup in
kernel log messages about 'Command line'? -> /proc/cmdline

> 
> 
> Mit freundlichen Grüßen
> 
> Maik Hänig
> 
> Am 25.01.2011 11:54, schrieb Reinhard Meyer:
>> Dear Maik Hänig,
>>> Hi,
>>>
>>>
>>> I change my uboot version and after it the uboot don't starts the same
>>> linux kernel:
>>>
>>> ## Booting kernel from Legacy Image at 1006 ...
>> _
>>>  Image Name:   Linux Kernel
>>>  Image Type:   ARM Linux Kernel Image (gzip compressed)
>>>  Data Size:1178673 Bytes = 1.1 MiB
>>>  Load Address: 20008000
>>>  Entry Point:  20008000
>>>  Verifying Checksum ... OK
>>>  Uncompressing Kernel Image ... OK
>>>
>>> Starting kernel ...
>>>
>>> *LOG END*
>>>
>>>
>>> It's a board simular to the at91rm9200dk. I start the kernel with

What is your board exactly? Is it currently in official u-boot or do you
have another tree?
at91rm9200dk is most likely broken with current u-boot (2010.12) and
will be removed for 2011.03. So if you have a at91rm9200dk at hand
please try to get the current u-boot working with that board and provide
patches. You may see my patches for at91rm9200ek which at least make
at91rm9200ek boot from SDRAM when setup correctly with an jtag (->
booting with at91bootstrab should also work but is untested).

regards

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


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Andreas Bießmann
Dear Maik Hänig,

Am 25.01.2011 12:18, schrieb Maik Hänig:
> Dear Reinhard Meyer,
> 
> I tried it with:
> 
> setenv bootargs root=/dev/mtdblock9 rootfstype=jffs2 console=ttyS4 
> ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006
> 
> but nothing the error is still there. The console is set in the board 
> init of the linux kernel.
> 
> I changed only the uboot verion. The linux kernel and the rootfilesystem 
> are the same.
> 

I guess you have a board with specific kernel and specific u-boot. So
maybe the machtype does not match?

regards

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


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig
Andreas Bießmann,

 > I guess you have a board with specific kernel and specific u-boot. So
 > maybe the machtype does not match?

Yes. Where can I found the mach type in uboot source?


Best regards / Mit freundlichen Grüßen

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


Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig

Dear Andreas Bießmann,


please do not hijack a thread!


sorry I didn't want do this. I wanted to give some more information.


Ok, you use 2010.09. This was last release before relocate changes.
Therefore it has no connection with the relocation stuff.


yes I. I tried to make a patch for 2010.12 but the uboot don't starts so 
I tried in the first step the version before. It is a similar board to 
the at91rm9200dk. It hangs in the low level_init file. But I have only a 
keil jtag debugger and couldn't debug it. or is there any possibility to 
use it with the gdb?


I found the problem in the board.c of the arm architecture. But can't 
see why. Line 303 is reached but line 312 not. Also line 306 is not 
reached. I don't know why, maybe you can give me a hint?


I think if the problem is found the problem with the at91rm9200dk is 
also found.



Is it nessesary to set a
console parameter in the bootcmd in uboot version 2010.09?


We don't know your configuration. What tells your working setup in
kernel log messages about 'Command line'? ->  /proc/cmdline


I only give the MAC and the running image in the cmdline. I think the 
problem must be in the uboot.




What is your board exactly? Is it currently in official u-boot or do you
have another tree?
at91rm9200dk is most likely broken with current u-boot (2010.12) and
will be removed for 2011.03. So if you have a at91rm9200dk at hand
please try to get the current u-boot working with that board and provide
patches. You may see my patches for at91rm9200ek which at least make
at91rm9200ek boot from SDRAM when setup correctly with an jtag (->
booting with at91bootstrab should also work but is untested).


It isn't in official u-boot tree. You can have a look in the patch.


Best regards / Mit freundlichen Grüßen

Maik Hänig
diff -Naur u-boot-2010.12_org/arch/arm/cpu/arm920t/at91/lowlevel_init.S 
u-boot-2010.12_patch/arch/arm/cpu/arm920t/at91/lowlevel_init.S
--- u-boot-2010.12_org/arch/arm/cpu/arm920t/at91/lowlevel_init.S
2010-12-22 20:22:14.0 +0100
+++ u-boot-2010.12_patch/arch/arm/cpu/arm920t/at91/lowlevel_init.S  
2011-01-20 11:44:21.384576087 +0100
@@ -65,7 +65,7 @@
ldr r0, =SMRDATA
ldr r1, _MTEXT_BASE
sub r0, r0, r1
-   add r2, r0, #80
+   add r2, r0, #(SMRDATA1-SMRDATA)
 pllloop:
/* the address */
ldr r1, [r0], #4
@@ -83,7 +83,7 @@
ldr r0, =SMRDATA1
ldr r1, _MTEXT_BASE
sub r0, r0, r1
-   add r2, r0, #176
+   add r2, r0, #(SMRDATA2-SMRDATA1)
 sdinit:
/* the address */
ldr r1, [r0], #4
@@ -108,6 +108,10 @@
.word CONFIG_SYS_EBI_CFGR_VAL
.word AT91_ASM_MC_SMC_CSR0
.word CONFIG_SYS_SMC_CSR0_VAL
+#ifdef CONFIG_SYS_SMC_CSR2_VAL
+   .word AT91_ASM_MC_SMC_CSR2
+   .word CONFIG_SYS_SMC_CSR2_VAL
+#endif 
.word AT91_ASM_PMC_PLLAR
.word CONFIG_SYS_PLLAR_VAL
.word AT91_ASM_PMC_PLLBR
@@ -161,4 +165,5 @@
.word CONFIG_SYS_SDRAM
.word CONFIG_SYS_SDRAM_VAL
/* SMRDATA1 is 176 bytes long */
+SMRDATA2:
 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
diff -Naur u-boot-2010.12_org/arch/arm/cpu/arm920t/start.S 
u-boot-2010.12_patch/arch/arm/cpu/arm920t/start.S
--- u-boot-2010.12_org/arch/arm/cpu/arm920t/start.S 2010-12-22 
20:22:14.0 +0100
+++ u-boot-2010.12_patch/arch/arm/cpu/arm920t/start.S   2011-01-20 
12:22:11.732575245 +0100
@@ -122,7 +122,7 @@
bl  coloured_LED_init
bl  red_LED_on
 
-#ifdefined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT91RM9200EK)
+#ifdefined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT91RM9200EK) || 
defined(CONFIG_KACOM)
/*
 * relocate exception table
 */
@@ -190,6 +190,14 @@
 
 
/*--*/
 
+/* ldr r0, =0x0001
+   ldr r1, =0xfA00
+   str r0, [r1]
+   ldr r1, =0xfA10
+   str r0, [r1]
+   ldr r1, =0xfA34
+   str r0, [r1]*/
+
 /*
  * void relocate_code (addr_sp, gd, addr_moni)
  *
diff -Naur u-boot-2010.12_org/arch/arm/include/asm/arch-at91/at91_mc.h 
u-boot-2010.12_patch/arch/arm/include/asm/arch-at91/at91_mc.h
--- u-boot-2010.12_org/arch/arm/include/asm/arch-at91/at91_mc.h 2010-12-22 
20:22:14.0 +0100
+++ u-boot-2010.12_patch/arch/arm/include/asm/arch-at91/at91_mc.h   
2011-01-20 08:39:22.604076221 +0100
@@ -26,6 +26,7 @@
 #define AT91_ASM_MC_EBI_CSA(AT91_MC_BASE + 0x60)
 #define AT91_ASM_MC_EBI_CFG(AT91_MC_BASE + 0x64)
 #define AT91_ASM_MC_SMC_CSR0   (AT91_MC_BASE + 0x70)
+#define AT91_ASM_MC_SMC_CSR2   (AT91_MC_BASE + 0x78)
 #define AT91_ASM_MC_SDRAMC_MR  (AT91_MC_BASE + 0x90)
 #define AT91_ASM_MC_SDRAMC_TR  (AT91_MC_BASE + 0x94)
 #define AT91_ASM_MC_SDRAMC_CR  (AT91_MC_BASE + 0x98)
diff -Naur u-boot-2010.12_org/arch/arm/lib/board.c 
u-boot-2010.12_patch/arch/arm/lib/board.

[U-Boot] Pull from ARM mavell and samsung repos?

2011-01-25 Thread Albert ARIBAUD
(cc: ARM Marvell and Samsung custodians)

Hi,

Looking up ARM repos, I see that currently u-boot-arm/master is lagging 
behind u-boot-marvell/master and u-boot-samsung/master. All patches in 
these two repos are prior to jan 17.

However I haven't found pull requests for these. Should I pull them in 
before sending out my pull request to u-boot ?

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


Re: [U-Boot] Pull from ARM mavell and samsung repos?

2011-01-25 Thread Minkyu Kang
Dear Albert ARIBAUD,

On 25 January 2011 21:18, Albert ARIBAUD  wrote:
> (cc: ARM Marvell and Samsung custodians)
>
> Hi,
>
> Looking up ARM repos, I see that currently u-boot-arm/master is lagging
> behind u-boot-marvell/master and u-boot-samsung/master. All patches in these
> two repos are prior to jan 17.
>
> However I haven't found pull requests for these. Should I pull them in
> before sending out my pull request to u-boot ?
>

I'm going to send the pull request at this Thursday .
Because of I'm waiting the review of my patches. (about s5pc2xx SoC)

When will you send the pull request to u-boot?

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] Uboot can't start kernel after change from version 2009.01 to 2010.09

2011-01-25 Thread Maik Hänig
Dear Andreas Bießmann,

 > I guess you have a board with specific kernel and specific u-boot. So
 > maybe the machtype does not match?

thanks, you was right it was a mach-type problem. I had set the wrong 
mach-type in my board init.

The problem with the uboot version 2010.12 hasn't changed.


Best regards / Mit freundlichen Grüßen

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


[U-Boot] How to give RESET_VECTOR_ADDRESS

2011-01-25 Thread Fabian Cenedese
Hi

As the config.mk file is doomed I tried to set my reset vector
in another way. I first tried it in the board's config header. But
that didn't seem to have an effect. I then tried a config option
in the boards.cfg file but that also didn't work. The only way I
could get it to work so far was with the config.mk file.

What's the new way to give a (CONFIG_)RESET_VECTOR_ADDRESS?

Thanks

bye  Fabi

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


Re: [U-Boot] How to give RESET_VECTOR_ADDRESS

2011-01-25 Thread Kumar Gala

On Jan 25, 2011, at 7:25 AM, Fabian Cenedese wrote:

> Hi
> 
> As the config.mk file is doomed I tried to set my reset vector
> in another way. I first tried it in the board's config header. But
> that didn't seem to have an effect. I then tried a config option
> in the boards.cfg file but that also didn't work. The only way I
> could get it to work so far was with the config.mk file.
> 
> What's the new way to give a (CONFIG_)RESET_VECTOR_ADDRESS?

Specify it in the board's config.h

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


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

2011-01-25 Thread Timur Tabi
Kumar Gala wrote:
> Actually we've dealt with this already:
> 
> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> Author: Yuri Tikhonov 
> Date:   Sat Dec 20 14:54:21 2008 +0300
> 
> FPU POST: fix warnings when building with 2.18 binutils

Why don't we compile all of U-Boot with hard float by default?  What's wrong
with using floating point instructions in U-Boot?

-- 
Timur Tabi
Linux kernel developer at Freescale

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


Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

2011-01-25 Thread Tom Warren
Mike,

On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport  wrote:
> On 01/22/11 01:06, Tom Warren wrote:
>> Signed-off-by: Tom Warren 
>> ---
>
> [ snip ]
>
>> +/*
>> + * Routine: pin_mux_uart
>> + * Description: setup the pin muxes/tristate values for a UART
>> + */
>> +static void pin_mux_uart(void)
>> +{
>> +     pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
>> +     u32 reg;
>> +
>> +#if CONFIG_TEGRA2_ENABLE_UARTA
>> +             reg = readl(&pmt->pmt_ctl_c);
>> +             reg &= 0xFFF0;      /* IRRX_/IRTX_SEL [19:16] = 00 UARTA */
>> +             writel(reg, &pmt->pmt_ctl_c);
>> +
>> +             reg = readl(&pmt->pmt_tri_a);
>> +             reg &= ~Z_IRRX;         /* Z_IRRX = normal (0) */
>> +             reg &= ~Z_IRTX;         /* Z_IRTX = normal (0) */
>> +             writel(reg, &pmt->pmt_tri_a);
>> +#endif       /* CONFIG_TEGRA2_ENABLE_UARTA */
>> +#if CONFIG_TEGRA2_ENABLE_UARTD
>> +             reg = readl(&pmt->pmt_ctl_b);
>> +             reg &= 0xFFF3;      /* GMC_SEL [3:2] = 00, UARTD */
>> +             writel(reg, &pmt->pmt_ctl_b);
>> +
>> +             reg = readl(&pmt->pmt_tri_a);
>> +             reg &= ~Z_GMC;          /* Z_GMC = normal (0) */
>> +             writel(reg, &pmt->pmt_tri_a);
>> +#endif       /* CONFIG_TEGRA2_ENABLE_UARTD */
>
> As I've already pointed out (1) this covers only one possibility of UART pin
> muxing options. I agree that it makes sense when this is a part of the
> board-specific code. However, forcing specific pins configuration in the 
> generic
> driver seems problematic to me, even if most Tegra2 boards use the same
> configuration.
> As a side note, I'd prefer to have all the pin multiplexing defined in one 
> place
> in board file rather than scattered among different drivers.
>
Alright. I'd like to get this wrapped up and accepted before the merge window
closes so I can get on with the important bits (drivers, etc.). What
would you like
here? A generic function like 'pinmux_set_config(reg, val, bit)' that
lives in the board
files and gets called from the driver code with specifics of that
board's/drivers pinmux
config? Or do you see the pinmux code living entirely in the board
files, and being done
as part of board init? That's where it was before, BTW.

If there are examples that you approve of in any extant U-Boot code (omap,
ti91, davinci, etc.), please point them out.  I'd really like to
finalize this patch series.

> (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233
>
>
> --
> Sincerely yours,
> Mike.
Thanks,

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


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

2011-01-25 Thread Kumar Gala

On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:

> Kumar Gala wrote:
>> Actually we've dealt with this already:
>> 
>> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
>> Author: Yuri Tikhonov 
>> Date:   Sat Dec 20 14:54:21 2008 +0300
>> 
>>FPU POST: fix warnings when building with 2.18 binutils
> 
> Why don't we compile all of U-Boot with hard float by default?  What's wrong
> with using floating point instructions in U-Boot?

* still have to deal with cores that dont have FP

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


Re: [U-Boot] Pull from ARM mavell and samsung repos?

2011-01-25 Thread Albert ARIBAUD
Le 25/01/2011 13:51, Minkyu Kang a écrit :
> Dear Albert ARIBAUD,
>
> On 25 January 2011 21:18, Albert ARIBAUD  wrote:
>> (cc: ARM Marvell and Samsung custodians)
>>
>> Hi,
>>
>> Looking up ARM repos, I see that currently u-boot-arm/master is lagging
>> behind u-boot-marvell/master and u-boot-samsung/master. All patches in these
>> two repos are prior to jan 17.
>>
>> However I haven't found pull requests for these. Should I pull them in
>> before sending out my pull request to u-boot ?
>>
>
> I'm going to send the pull request at this Thursday .
> Because of I'm waiting the review of my patches. (about s5pc2xx SoC)
>
> When will you send the pull request to u-boot?

If that's fine with Wolfgang, I'll wait for your own pull request.

> Thanks
> Minkyu Kang

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


Re: [U-Boot] U-Boot support for board(s) meesc, otc570

2011-01-25 Thread Albert ARIBAUD
Le 24/01/2011 12:39, Daniel Gorsulowski a écrit :
> Hello Reinhard,
>
> ...
>>>
>>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>>> very end
>>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>>> AT91Bootstrap
>>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
>>> of DRAM
>>> for our boards.)
>>>
>>
>> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address,
>> so the problem must be located elsewhere.
>>
>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>> its startup messages to wrong USART with proper baudrate. I'll try to
>> find out, why there is no output on DBGU.
>>
>
> I have to correct myself.
> My board_init() and checkboard() fanctions are executed. But the board
> crashes, before misc_init_r() functions executes.
> (I guess, it crashes somwhere in board_init_f())
> I'll try to find out more infos. But without an appropriate opportunity
> to debug, it will be verry difficult.

Make sure nothing executes under board_init_f() that tries to write to 
BSS (uninitialized) variables: BSS does not actually exist until after 
relocation, and writing to the would-be BSS area will cause corruption 
of the U-boot code. Not sure this is what happens with you but better 
safe than sorry.

> Best regards
> Daniel

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


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

2011-01-25 Thread Wolfgang Denk
Dear Timur Tabi,

In message <4d3efcf2.4060...@freescale.com> you wrote:
>
> Why don't we compile all of U-Boot with hard float by default?  What's wrong
> with using floating point instructions in U-Boot?

We don't need it.

Why doesn't the Linux kernel use floating point instructions?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The ultimate barrier is one's viewpoint.
- Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Pull from ARM mavell and samsung repos?

2011-01-25 Thread Wolfgang Denk
Dear Albert ARIBAUD,

In message <4d3f1125.5070...@free.fr> you wrote:
>
> > I'm going to send the pull request at this Thursday .
> > Because of I'm waiting the review of my patches. (about s5pc2xx SoC)
> >
> > When will you send the pull request to u-boot?
> 
> If that's fine with Wolfgang, I'll wait for your own pull request.

I have little choice but wait until you all are ready. [And my own
todo list is not empty yet either.]

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 evolution of the human race will not be accomplished in  the  ten
thousand  years  of  tame  animals,  but in the million years of wild
animals, because man is and will always be a wild animal.
  - Charles Galton Darwin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Timur Tabi
Wolfgang Denk wrote:
> Why doesn't the Linux kernel use floating point instructions?

Because dealing with FP in a multi-tasking OS is messy.  U-Boot doesn't have
that problem.

-- 
Timur Tabi
Linux kernel developer at Freescale

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


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

2011-01-25 Thread Timur Tabi
Kumar Gala wrote:
> * still have to deal with cores that dont have FP

But when will gcc generate FP instructions?  If we compile with soft-float, will
it link in an FP library and use it?

My point is that compiling with soft-float doesn't make much more sense than
compiling with hard-float, since there won't be any floating point instructions
in either case.

-- 
Timur Tabi
Linux kernel developer at Freescale

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


[U-Boot] SteppingStone

2011-01-25 Thread Matt Johnson
Hello.

I have a custom board with a Samsung s3c2410 (arm920t) processor.  I have
been unable to get the main branch of u-boot to work with this board.
However, I have been successful with the old OpenMoko fork.  (I believe it
is because of the "SteppingStone" microcode. See
http://wiki.openmoko.org/wiki/S3C2410_Steppingstone if you're unfamiliar.)

I'd prefer to use the main branch, because the OpenMoko fork is old and
unmaintained.  The OpenMoko project abandoned u-boot some time ago, in favor
of their "Qi" bootloader.

Has anyone looked at merging the SteppingStone code back in to the main
branch?  Is there some other workaround that is unclear to me?

Are there other bootloaders that support SteppingStone that I could try?
I'm looking for something as full-featured as u-boot, but actively
maintained. The only other that I've found is Vivi - which is super ancient.
Any advice is appreciated.

Thanks,
Matt

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


[U-Boot] [PATCH] powerpc/85xx: Add some defines for P2040, P3041, P5010, P5020

2011-01-25 Thread Kumar Gala
Specify the number of DDR controllers, number of frame managers, number
of 1g and 10g ports.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/include/asm/config_mpc85xx.h |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index a78086b..0f83d15 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -140,11 +140,18 @@
 #define CONFIG_MAX_CPUS4
 #define CONFIG_SYS_FSL_NUM_LAWS32
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
+#define CONFIG_SYS_NUM_FMAN1
+#define CONFIG_SYS_NUM_FM1_DTSEC   5
+#define CONFIG_NUM_DDR_CONTROLLERS 1
 
 #elif defined(CONFIG_PPC_P3041)
 #define CONFIG_MAX_CPUS4
 #define CONFIG_SYS_FSL_NUM_LAWS32
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
+#define CONFIG_SYS_NUM_FMAN1
+#define CONFIG_SYS_NUM_FM1_DTSEC   5
+#define CONFIG_SYS_NUM_FM1_10GEC   1
+#define CONFIG_NUM_DDR_CONTROLLERS 1
 
 #elif defined(CONFIG_PPC_P4040)
 #define CONFIG_MAX_CPUS4
@@ -176,11 +183,19 @@
 #define CONFIG_MAX_CPUS1
 #define CONFIG_SYS_FSL_NUM_LAWS32
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
+#define CONFIG_SYS_NUM_FMAN1
+#define CONFIG_SYS_NUM_FM1_DTSEC   5
+#define CONFIG_SYS_NUM_FM1_10GEC   1
+#define CONFIG_NUM_DDR_CONTROLLERS 1
 
 #elif defined(CONFIG_PPC_P5020)
 #define CONFIG_MAX_CPUS2
 #define CONFIG_SYS_FSL_NUM_LAWS32
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
+#define CONFIG_SYS_NUM_FMAN1
+#define CONFIG_SYS_NUM_FM1_DTSEC   5
+#define CONFIG_SYS_NUM_FM1_10GEC   1
+#define CONFIG_NUM_DDR_CONTROLLERS 2
 
 #else
 #error Processor type not defined for this platform
-- 
1.7.2.3

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


Re: [U-Boot] Pull from ARM mavell and samsung repos?

2011-01-25 Thread Prafulla Wadaskar


> -Original Message-
> From: Minkyu Kang [mailto:proms...@gmail.com]
> Sent: Tuesday, January 25, 2011 4:52 AM
> To: Albert ARIBAUD
> Cc: u-boot@lists.denx.de; Prafulla Wadaskar
> Subject: Re: Pull from ARM mavell and samsung repos?
> 
> Dear Albert ARIBAUD,
> 
> On 25 January 2011 21:18, Albert ARIBAUD  wrote:
> > (cc: ARM Marvell and Samsung custodians)
> >
> > Hi,
> >
> > Looking up ARM repos, I see that currently u-boot-arm/master is
> lagging
> > behind u-boot-marvell/master and u-boot-samsung/master. All patches in
> these
> > two repos are prior to jan 17.
> >
> > However I haven't found pull requests for these. Should I pull them in
> > before sending out my pull request to u-boot ?
> >
> 
> I'm going to send the pull request at this Thursday .
> Because of I'm waiting the review of my patches. (about s5pc2xx SoC)

Even I too

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


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

2011-01-25 Thread Wolfgang Denk
Dear Timur Tabi,

In message <4d3f1674.10...@freescale.com> you wrote:
>
> Because dealing with FP in a multi-tasking OS is messy.  U-Boot doesn't have
> that problem.

But we also do not have any need for FP operations either. It would
just add to the complexity (and to the memory foot print, especially
on systems without FPU where we would have to provide soft-float
libraries, plus eventually variantes for SPEv1 and SPEvv2 and
whatever - not to mention that tghis will be needed for all the
non-PPC architectures as well).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The combination of a number of things to make existence worthwhile."
"Yes, the philosophy of 'none,' meaning 'all.'"
-- Spock and Lincoln, "The Savage Curtain", stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Wolfgang Denk
Dear Timur Tabi,

In message <4d3f16c7.7040...@freescale.com> you wrote:
>
> But when will gcc generate FP instructions?  If we compile with soft-float, 
> will
> it link in an FP library and use it?

GCC will (in addition to the obvious case of operations of FP data
types) generate FP instructions for a number of "small data copy"
operations, like assignment of structs etc.

> My point is that compiling with soft-float doesn't make much more sense than
> compiling with hard-float, since there won't be any floating point 
> instructions
> in either case.

You are wrong.

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
One difference between a man and a machine is that a machine is quiet
when well oiled.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Wolfgang Denk
Dear Timur Tabi,

In message <4d3f1d25.4070...@freescale.com> you wrote:
>
> I think you misunderstand.  I'm not saying that we should use FP instructions 
> in
> U-Boot.  I'm saying that since we *don't* use FP instructions in U-Boot, we 
> can
> just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU,
> because all of U-Boot will then be compiled with hard-float.

If we let him, GCC would generate FP instructions in a number of
places where you don't expect them, even whithout any FP variables or
explicit FP operations in the whole code C or assembler input.

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
"'Tis true, 'tis pity, and pity 'tis 'tis true."
- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Timur Tabi
Wolfgang Denk wrote:
> But we also do not have any need for FP operations either. It would
> just add to the complexity (and to the memory foot print, especially
> on systems without FPU where we would have to provide soft-float
> libraries, plus eventually variantes for SPEv1 and SPEvv2 and
> whatever - not to mention that tghis will be needed for all the
> non-PPC architectures as well).

I think you misunderstand.  I'm not saying that we should use FP instructions in
U-Boot.  I'm saying that since we *don't* use FP instructions in U-Boot, we can
just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU,
because all of U-Boot will then be compiled with hard-float.

-- 
Timur Tabi
Linux kernel developer at Freescale

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


Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux

2011-01-25 Thread Wolfgang Denk
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,

In message <4d3eac1a.5030...@arcor.de> you wrote:
>
> | HEAD(1)| HEAD(1)| HEAD(2)| HEAD(2)|
> || +patch || +patch |
> ---+++++
> Reset to prompt|  438ms |  330ms |  228ms |  120ms |
> |||||
> TFTP a 3MB img | 4782ms | 3428ms | 3245ms | 2820ms |
> |||||
> FATLOAD USB a 3MB img* | 8515ms | 8510ms | -- | -- |
> |||||
> BOOTM LZO img in RAM   | 3473ms | 3168ms |  592ms |  592ms |
>   where CRC is  |  615ms |  615ms |   54ms |   54ms |
>   uncompress| 2460ms | 2462ms |  450ms |  451ms |
>   final boot_elf|  376ms |   68ms |   65ms |   65ms |
> |||||
> BOOTM LZO img in FLASH | 3207ms | 2902ms | 1050ms | 1050ms |
>   where CRC is  |  600ms |  600ms |  135ms |  135ms |
>   uncompress| 2209ms | 2211ms |  828ms |  828ms |
>   final boot_elf|  376ms |   68ms |   65ms |   65ms |
> 
> (1) No dcache
> (2) dcache enabled in board_init
> *Does not work when dcache is on
> 
> I think we can see that there seems to be no negativ impact of theses 
> patches when only execution speed is taken into consideration. The gain 
> is noticable when caching is not used or not activated. For pure RAM to 
> RAM copy when caching is activated the patch didn't change anything.
> 
> Here are some additional numbers for copying a 1.4MB image from NOR to RAM:
> 
> HEAD  : 134ms
> HEAD + patch  : 72ms
> HEAD + dcache : 120ms
> HEAD + dcache + patch : 70ms

This is pretty much interesting information for developers who have to
decide if they want to accept the increased memory footprint.  Can you
please add this to the commit message?

> Would it be an option to use the CONFIG entries CONFIG_USE_ARCH_MEMCPY 
> and CONFIG_USE_ARCH_MEMSET to enable that feature? If that is OK I can 

Makes sense to me.

> send a new version of the patch. The only problem I see with this 
> approach is that there are architectures which already have their own 
> implementations which are then not affected by these config options.

If you are aware of any, it might make sense to put the respective
maintainers on Cc: to trigger them to adapt / clean up their code.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Its always easier short term to pee in the pond
than install a toilet - it's just not a good long term plan.
  - Alan Cox in <20100101145701.6432e...@lxorguk.ukuu.org.uk>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Scott Wood
On Tue, 25 Jan 2011 11:49:53 -0600
Kumar Gala  wrote:

> 
> On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
> 
> > Kumar Gala wrote:
> >> Actually we've dealt with this already:
> >> 
> >> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> >> Author: Yuri Tikhonov 
> >> Date:   Sat Dec 20 14:54:21 2008 +0300
> >> 
> >>FPU POST: fix warnings when building with 2.18 binutils
> > 
> > Why don't we compile all of U-Boot with hard float by default?  What's wrong
> > with using floating point instructions in U-Boot?
> 
> * still have to deal with cores that dont have FP

On cores that have FP (at least those that support the FPU POST, and
which are currently having problems), use hard float, enable
MSR[FP] or equivalent, and let GCC use FP for various tasks if it
wants.  This shouldn't involve much more complexity than adding a
small amount of init, which you'd need for the POST anyway.

On cores that don't have FP, use soft float, and don't include
the FPU POST code.  This should not be any different than today, except
for adding another compiler flag that depends on the build target.

-Scott

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


Re: [U-Boot] [GIT PULL] Please pull u-boot-mpc85xx.git

2011-01-25 Thread Wolfgang Denk
Dear Kumar Gala,

In message  you wrote:
> The following changes since commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-17 
> 20:31:46 +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc85xx master
> 
> Dipen Dudhat (1):
>   powerpc/85xx: Protect all LBC code with CONFIG_FSL_LBC
> 
> Haiying Wang (1):
>   8xxx/ddr: add support to only compute the ddr sdram size
> 
> Kumar Gala (6):
>   powerpc/85xx: Move RESET_VECTOR_ADDRESS into config.h
>   powerpc/p3041: Add various p3041 specific information
>   powerpc/p5020: Add various p5020 specific information
>   powerpc/p2040: Add various p2040 specific information
>   powerpc/8xxx: Add hwconfig APIs to address early parsing used by DDR 
> init
>   powerpc/8xxx: Introduce 85xx, 86xx, QorIQ config headers
> 
> Poonam Aggrwal (2):
>   powerpc/85xx: Add Support for Freescale P1010 Processor
>   powerpc/85xx: Add Support for Freescale P1014 Processor
> 
> Prabhakar (1):
>   Fix wrong CONFIG_SYS_MPC85xx_SERDES1_ADDR
> 
> Prabhakar Kushwaha (1):
>   ppc/85xx: Fix compile err when PCI disabled on P1_P2_RDB
> 
> York Sun (8):
>   mpc8xxx: Display RDIMM if detected
>   mpc8xxx: Enable ECC on/off control in hwconfig
>   corenet_ds: Enable ECC for corenet_ds
>   mpc85xx: Adding more registers and options
>   mpc85xx: Enable unique mode registers and dynamic ODT for DDR3
>   mpc85xx: Implement workaround for erratum DDR-A003
>   corenet_ds: Extend board specific parameters
>   powerpc/p4080: Fix warning in serdes code from early use of hwconfig
> 
>  arch/powerpc/cpu/mpc85xx/Makefile  |6 +
>  arch/powerpc/cpu/mpc85xx/cmd_errata.c  |3 +
>  arch/powerpc/cpu/mpc85xx/cpu.c |9 +-
>  arch/powerpc/cpu/mpc85xx/ddr-gen3.c|   99 +-
>  arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c  |   17 +-
>  arch/powerpc/cpu/mpc85xx/p2040_serdes.c|   66 
>  arch/powerpc/cpu/mpc85xx/p3041_ids.c   |  105 ++
>  arch/powerpc/cpu/mpc85xx/p3041_serdes.c|  151 
>  arch/powerpc/cpu/mpc85xx/p5020_ids.c   |  105 ++
>  arch/powerpc/cpu/mpc85xx/p5020_serdes.c|  151 
>  arch/powerpc/cpu/mpc85xx/speed.c   |6 +-
>  arch/powerpc/cpu/mpc85xx/u-boot.lds|8 +-
>  arch/powerpc/cpu/mpc8xxx/cpu.c |8 +-
>  arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c   |  262 +++---
>  arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |8 +-
>  .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c|   20 +-
>  arch/powerpc/cpu/mpc8xxx/ddr/main.c|   31 ++-
>  arch/powerpc/cpu/mpc8xxx/ddr/options.c |  395 
> ++--
>  arch/powerpc/include/asm/config.h  |   39 +--
>  arch/powerpc/include/asm/config_mpc85xx.h  |  188 ++
>  arch/powerpc/include/asm/config_mpc86xx.h  |   38 ++
>  arch/powerpc/include/asm/fsl_ddr_sdram.h   |   52 +++
>  arch/powerpc/include/asm/immap_85xx.h  |   23 +-
>  arch/powerpc/include/asm/processor.h   |6 +
>  board/freescale/corenet_ds/config.mk   |   27 --
>  board/freescale/corenet_ds/ddr.c   |  159 
>  board/freescale/mpc8536ds/config.mk|   14 +-
>  board/freescale/mpc8572ds/config.mk|4 +-
>  board/freescale/p1022ds/config.mk  |   10 -
>  board/freescale/p1_p2_rdb/config.mk|   14 +-
>  board/freescale/p1_p2_rdb/p1_p2_rdb.c  |4 +-
>  board/freescale/p1_p2_rdb/tlb.c|4 +-
>  board/freescale/p2020ds/config.mk  |   26 --
>  board/tqc/tqm85xx/sdram.c  |8 +-
>  common/hwconfig.c  |   86 +++--
>  doc/README.fsl-ddr |   74 -
>  drivers/misc/fsl_law.c |   23 +-
>  include/configs/MPC8536DS.h|6 +
>  include/configs/MPC8572DS.h|4 +
>  include/configs/P1022DS.h  |4 +
>  include/configs/P1_P2_RDB.h|   19 +-
>  include/configs/P2020DS.h  |4 +
>  include/configs/P4080DS.h  |   16 -
>  include/configs/corenet_ds.h   |8 +-
>  include/hwconfig.h |   68 +++-
>  45 files changed, 1940 insertions(+), 438 deletions(-)
>  create mode 100644 arch/powerpc/cpu/mpc85xx/p2040_serdes.c
>  create mode 100644 arch/powerpc/cpu/mpc85xx/p3041_ids.c
>  create mode 100644 arch/powerpc/cpu/mpc85xx/p3041_serdes.c
>  create mode 100644 arch/powerpc/cpu/mpc85xx/p5020_ids.c
>  create mode 100644 arch/powerpc/cpu/mpc85xx/p5

Re: [U-Boot] [PATCH] UEC: Fix compiler warnings introduced by linux/mii.h change

2011-01-25 Thread Wolfgang Denk
Dear Kumar Gala,

In message <1295429800-26074-1-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> Patch 8ef583a0 [miiphy: convert to linux/mii.h] introduced the following
> compiler warnings in the uec ethernet driver:
> 
> In file included from /local/home/galak/git/u-boot-85xx/include/miiphy.h:37:0,
>  from uec.c:32:
> /local/home/galak/git/u-boot-85xx/include/linux/mii.h:133:0: warning: 
> "LPA_1000FULL" redefined
> uec_phy.h:34:0: note: this is the location of the previous definition
> /local/home/galak/git/u-boot-85xx/include/linux/mii.h:134:0: warning: 
> "LPA_1000HALF" redefined
> uec_phy.h:35:0: note: this is the location of the previous definition
> In file included from /local/home/galak/git/u-boot-85xx/include/miiphy.h:37:0,
>  from uec_phy.c:27:
> /local/home/galak/git/u-boot-85xx/include/linux/mii.h:133:0: warning: 
> "LPA_1000FULL" redefined
> uec_phy.h:34:0: note: this is the location of the previous definition
> /local/home/galak/git/u-boot-85xx/include/linux/mii.h:134:0: warning: 
> "LPA_1000HALF" redefined
> uec_phy.h:35:0: note: this is the location of the previous definition
> 
> Fix them be removing the duplication in the uec code and utlizing the
> linux/mii.h version instead.
> 
> Signed-off-by: Kumar Gala 
> ---
>  drivers/qe/uec_phy.c |   16 
>  drivers/qe/uec_phy.h |   12 +---
>  2 files changed, 9 insertions(+), 19 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

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


Re: [U-Boot] [PATCH] powerpc: Fix FPU post related link warnings

2011-01-25 Thread Wolfgang Denk
Dear Kumar Gala,

In message <1295946008-11905-1-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> If we built POST on PPC's that didn't enable CONFIG_SYS_POST_FPU we'd
> get the following warning with newer toolchains:
> 
> powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o
> uses hard float, libpost.o uses soft float
> 
> We actually worked around this sometime ago with the following commit:
> 
> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> Author: Yuri Tikhonov 
> Date:   Sat Dec 20 14:54:21 2008 +0300
> 
>FPU POST: fix warnings when building with 2.18 binutils
> 
> However, this only took into effect if CONFIG_SYS_POST_FPU was enabled.
> We can simply move the GNU_FPOST_ATTR out of the CONFIG_SYS_POST_FPU
> ifdef block to address the issue.
> 
> Signed-off-by: Kumar Gala 
> ---
> 
> Wolfgang, I request we think about include this patch in v2011.03 tree so we
> can all stop getting these build warnings :)
> 
> - k
> 
>  post/lib_powerpc/fpu/20001122-1.c |4 ++--
>  post/lib_powerpc/fpu/20010114-2.c |4 ++--
>  post/lib_powerpc/fpu/20010226-1.c |4 ++--
>  post/lib_powerpc/fpu/980619-1.c   |4 ++--
>  post/lib_powerpc/fpu/acc1.c   |4 ++--
>  post/lib_powerpc/fpu/compare-fp-1.c   |4 ++--
>  post/lib_powerpc/fpu/fpu.c|4 ++--
>  post/lib_powerpc/fpu/mul-subnormal-single-1.c |4 ++--
>  8 files changed, 16 insertions(+), 16 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
No more blah, blah, blah!
-- Kirk, "Miri", stardate 2713.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-Boot v2010.12 released - Merge Window OPEN

2011-01-25 Thread Wolfgang Denk
Dear Alexander Holler,

In message <4d3e8855.4070...@ahsoftware.de> you wrote:
> 
> > *
> > * Currently,>100 ARM boards are *broken* and *do not compile*. *
> > *
> >
> > Board maintainers or othe rinterested parties are requested to
> > adapt their boards to the new code in the timeframe of the
> > upcoming release v2010.03; all boards that have not been converted
> > by then, i. e. that are still broken then, are considered
> > unmaintained and without interest to the community and will be
> > removed.
> 
> Maybe just a
> 
> #error Code for this board doesn't compile since at least #date#
> 
> or a similiar message in foo_config.h would be a way to inform people 
> early that the code needs some work.
> 
> This way the source for the board could be visible for some more time in 
> the repository.

Patches welcome...

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 world is coming to an end -- save your buffers!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Wolfgang Denk
Dear Scott Wood,

In message <20110125140547.2825f...@udp111988uds.am.freescale.net> you wrote:
>
> On cores that have FP (at least those that support the FPU POST, and
> which are currently having problems), use hard float, enable
> MSR[FP] or equivalent, and let GCC use FP for various tasks if it
> wants.  This shouldn't involve much more complexity than adding a
> small amount of init, which you'd need for the POST anyway.
> 
> On cores that don't have FP, use soft float, and don't include
> the FPU POST code.  This should not be any different than today, except
> for adding another compiler flag that depends on the build target.

And why exactly should we do all this, given the fact that there are
no intentions to work with floating point data in U-Boot?

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
e-credibility: the non-guaranteeable likelihood that  the  electronic
data you're seeing is genuine rather than somebody's made-up crap.
- Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC][PATCH 12/36] sc520 - Sort Makefile

2011-01-25 Thread Wolfgang Denk
Dear Graeme Russ,

In message <1294084016-2674-13-git-send-email-graeme.r...@gmail.com> you wrote:
> ---
>  arch/i386/cpu/sc520/Makefile |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/i386/cpu/sc520/Makefile b/arch/i386/cpu/sc520/Makefile
> index fb47c20..b962b02 100644
> --- a/arch/i386/cpu/sc520/Makefile
> +++ b/arch/i386/cpu/sc520/Makefile
> @@ -32,9 +32,9 @@ include $(TOPDIR)/config.mk
>  LIB  := $(obj)lib$(SOC).o
> 
>  COBJS-$(CONFIG_SYS_SC520) += sc520.o
> +COBJS-$(CONFIG_PCI) += sc520_pci.o
>  COBJS-$(CONFIG_SYS_SC520_SSI) += sc520_ssi.o
>  COBJS-$(CONFIG_SYS_SC520_TIMER) += sc520_timer.o
> -COBJS-$(CONFIG_PCI) += sc520_pci.o

Please sort list.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If a group of N persons implements a COBOL compiler,  there  will  be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 00/36] Massive x86 Update - Bring x86 in line with ARM and PPC

2011-01-25 Thread Wolfgang Denk
Dear Graeme Russ,

In message <1294084016-2674-1-git-send-email-graeme.r...@gmail.com> you wrote:
> It's been a while since I've posted a patch (missed the last release cycle
> entirely). I've been working on bringing x86 into line with ARM and PowerPC
> with the init sequence running in flash. Currently, the SDRAM gets
> initialised in asm before jumping into C and the first thing the C code did
> was copy U-Boot to RAM.
> 
> The breakthrough came when I discovered that the sc520 CPU can be configured
> to enable the 16kB cache to be used as Cache-As-RAM (Thanks to Juergen
> Beisert). The 'big' changes in this series are:
> 
>  - Memory initialisation is done in C (26)
>  - The initial global data is placed in CAR (Patches 24 & 36) - These are
>interesting and could be used to get rid of the fixed register for
>global data, but that would break the standalone API which uses it
>  - Board initialisation moved into RAM (patches 27 - 34)

Except for the small nitpicking (sort list):

Acked-by: Wolfgang Denk 

for the whole set.  Please feel free to merge and send a pull req.

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 human race is a race of cowards; and I am not  only  marching  in
that procession but carrying a banner.   - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 13/13] add dvlhost (dLAN 200 AV Wireless G) board

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-14-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 
...
> diff --git a/board/dvlhost/config.mk b/board/dvlhost/config.mk
> new file mode 100644
> index 000..a370337
> --- /dev/null
> +++ b/board/dvlhost/config.mk
> @@ -0,0 +1,3 @@
> +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds
> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
> +PLATFORM_LDFLAGS += --gc-sections

Please drop that file, it should not be needed.

...
> +int board_init (void)
> +{
> + gd->bd->bi_arch_number = MACH_TYPE_DVLHOST;
> +
> + /* adress of boot parameters */
> + gd->bd->bi_boot_params = 0x0100;
> +
> + /* Setup GPIOs used as output */
> + GPIO_OUTPUT_CLEAR(CONFIG_SYS_GPIO_WDGTRIGGER);
> + GPIO_OUTPUT_SET(CONFIG_SYS_GPIO_DLAN_PAIRING);
> + GPIO_OUTPUT_CLEAR(CONFIG_SYS_GPIO_PCIRST);
> +
> + /* LED latch enable and watchdog enable are tied to the same GPIO,
> +so we need to trigger the watchdog if we want to enable the LEDs. */

Incorrect multiline comment style, please fix globally.


> +int dram_init (void)
> +{
> + gd->ram_size = PHYS_SDRAM_1_SIZE;
> + return (0);

You should use get_ram_size() here.


> diff --git a/board/dvlhost/u-boot.lds b/board/dvlhost/u-boot.lds
> new file mode 100644
> index 000..606a46f
> --- /dev/null
> +++ b/board/dvlhost/u-boot.lds

Do you really need a board specific linker script?
It looks pretty much generic to me.


> +void hw_watchdog_reset(void)
> +{
> + *IXP425_GPIO_GPOUTR ^= (1 << (CONFIG_SYS_GPIO_WDGTRIGGER));

Please always use I/O accessors.  Please fix globally.

...
> +
> +#undef CONFIG_HW_WATCHDOG/* HW Watchdog, board specific  */

Please do not undef what is not defined anyway. Please fix globally.



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
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Scott Wood
On Tue, 25 Jan 2011 21:19:19 +0100
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <20110125140547.2825f...@udp111988uds.am.freescale.net> you wrote:
> >
> > On cores that have FP (at least those that support the FPU POST, and
> > which are currently having problems), use hard float, enable
> > MSR[FP] or equivalent, and let GCC use FP for various tasks if it
> > wants.  This shouldn't involve much more complexity than adding a
> > small amount of init, which you'd need for the POST anyway.
> > 
> > On cores that don't have FP, use soft float, and don't include
> > the FPU POST code.  This should not be any different than today, except
> > for adding another compiler flag that depends on the build target.
> 
> And why exactly should we do all this,

To fix the FPU POST build errors.

Do you have a simpler way to do this?  Note that for any board that
doesn't currently have a problem, "all this" means no change at all.

And for those that do have a problem, the change is pretty minor.

> given the fact that there are
> no intentions to work with floating point data in U-Boot?

FPU POST doesn't count?

Or are you saying FPU POST should be removed?

-Scott

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


Re: [U-Boot] [PATCH 01/13] add XScale sub architecture (IXP/PXA) to board list

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-2-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 

That's not a "board list", but the MAINTAINERS file (I would
expect changes to boards.cfg when I read "board list").

> - wepep250xscale
> + wepep250xscale/pxa (removed)

What does "removed" mean? When it's removed, then please remove.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
 - Terry Pratchett, _Eric_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 02/13] add support for IXP42x Rev. B1 and newer

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-3-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 
> ---
>  arch/arm/cpu/ixp/npe/npe.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/cpu/ixp/npe/npe.c b/arch/arm/cpu/ixp/npe/npe.c
> index 2e68689..9d1090e 100644
> --- a/arch/arm/cpu/ixp/npe/npe.c
> +++ b/arch/arm/cpu/ixp/npe/npe.c
> @@ -621,8 +621,9 @@ int npe_initialize(bd_t * bis)
>   if (ixFeatureCtrlDeviceRead() == 
> IX_FEATURE_CTRL_DEVICE_TYPE_IXP42X) {
>   switch (ixFeatureCtrlProductIdRead() & 
> IX_FEATURE_CTRL_SILICON_STEPPING_MASK) {
>   case IX_FEATURE_CTRL_SILICON_TYPE_B0:
> + default: /* newer than B0 */
>   /*
> -  * If it is B0 Silicon, we only enable 
> port when its corresponding
> +  * If it is B0 or newer Silicon, we 
> only enable port when its corresponding

Lines too long.

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 increased productivity fostered by a friendly environment  and
quality  tools  is  essential  to  meet  ever  increasing demands for
software.   - M. D. McIlroy, E. N. Pinson and B. A. Tague
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 04/13] Fix IXP code to work after relocation was added

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-5-git-send-email-mich...@schwingen.org> you wrote:
>  - jump to real flash location after reset before turning off flash mirror
>  - fix timer system to use HZ == 1000, remove broken interrupt-based code
> 
> Signed-off-by: Michael Schwingen 
> ---
>  arch/arm/cpu/ixp/cpu.c |5 --
>  arch/arm/cpu/ixp/start.S   |   59 ++--
>  arch/arm/cpu/ixp/timer.c   |  125 
> +++-
>  arch/arm/include/asm/arch-ixp/ixp425.h |5 +-
>  4 files changed, 66 insertions(+), 128 deletions(-)
...
> -int timer_init (void)
> +static ulong timestamp;
> +static ulong lastinc;


This code is broken. You must not access any variables in BSS segment
(like these two) before relocation.


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
If the facts don't fit the theory, change the facts.
   -- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 05/13] fix "depend" target in npe directory

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-6-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 
> ---
>  arch/arm/cpu/ixp/npe/Makefile |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/cpu/ixp/npe/Makefile b/arch/arm/cpu/ixp/npe/Makefile
> index c756a1d..14ab3c7 100644
> --- a/arch/arm/cpu/ixp/npe/Makefile
> +++ b/arch/arm/cpu/ixp/npe/Makefile
> @@ -27,6 +27,7 @@ LIB := $(obj)libnpe.o
>  
>  LOCAL_CFLAGS  += -I$(TOPDIR)/arch/arm/cpu/ixp/npe/include 
> -DCONFIG_IXP425_COMPONENT_ETHDB -D__linux
>  CFLAGS  += $(LOCAL_CFLAGS)
> +CPPFLAGS  += $(LOCAL_CFLAGS) # needed for depend
>  HOSTCFLAGS  += $(LOCAL_CFLAGS)

It should then be possible to remove the CFLAGS line, right?

Best regards,

Wolfgang Denk

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


Re: [U-Boot] [PATCH 07/13] update/fix AcTux1 board

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-8-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 
> ---
>  board/actux1/actux1.c|   22 +++-
>  board/actux1/config.mk   |7 +
>  board/actux1/u-boot.lds  |   42 +++
>  boards.cfg   |5 +++-
>  include/configs/actux1.h |   48 +++--
>  5 files changed, 76 insertions(+), 48 deletions(-)
> 
> diff --git a/board/actux1/actux1.c b/board/actux1/actux1.c
> index 399be23..c56ec94 100644
> --- a/board/actux1/actux1.c
> +++ b/board/actux1/actux1.c
> @@ -42,6 +42,17 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +int board_early_init_f (void)
> +{
> + /* CS5: Debug port */
> + *IXP425_EXP_CS5 = 0x9d520003;
> + /* CS6: HwRel */
> + *IXP425_EXP_CS6 = 0x81860001;
> + /* CS7: LEDs */
> + *IXP425_EXP_CS7 = 0x8093;
> + return 0;

Please always use I/O accessors.  Please fix globally.

>  int dram_init (void)
>  {
> - gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> - gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> -
> + gd->ram_size = PHYS_SDRAM_1_SIZE;
>   return (0);

You should use get_ram_size() here.

> diff --git a/board/actux1/config.mk b/board/actux1/config.mk
> index 88634f7..a370337 100644
> --- a/board/actux1/config.mk
> +++ b/board/actux1/config.mk
> @@ -1,6 +1,3 @@
> -CONFIG_SYS_TEXT_BASE = 0x00e0
> -
> -# include NPE ethernet driver
> -BOARDLIBS = arch/arm/cpu/ixp/npe/libnpe.o
> -
>  LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds
> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
> +PLATFORM_LDFLAGS += --gc-sections

Can we please get rid of this file completely?

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
Swap read error.  You lose your mind.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 08/13] update/fix AcTux2 board

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-9-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 
> ---
>  board/actux2/actux2.c|   26 +---
>  board/actux2/config.mk   |7 +
>  board/actux2/u-boot.lds  |   47 -
>  include/configs/actux2.h |   21 +++
>  4 files changed, 61 insertions(+), 40 deletions(-)
> 
> diff --git a/board/actux2/actux2.c b/board/actux2/actux2.c
> index d6aaad6..634553f 100644
> --- a/board/actux2/actux2.c
> +++ b/board/actux2/actux2.c
> @@ -43,6 +43,19 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +int board_early_init_f (void)
> +{
> + /* CS1: IPAC-X */
> + *IXP425_EXP_CS1 = 0x94d10013;
> + /* CS5: Debug port */
> + *IXP425_EXP_CS5 = 0x9d520003;
> + /* CS6: HW release register */
> + *IXP425_EXP_CS6 = 0x81860001;
> + /* CS7: LEDs */
> + *IXP425_EXP_CS7 = 0x8093;
> + return 0;

Same comments as for AcTux1 apply to this patch, and to the other
AcTux* patches as well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"You shouldn't make my toaster angry." - Household security explained
in "Johnny Quest"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 11/13] update/fix some more IXP42x boards (only compile tested)

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-12-git-send-email-mich...@schwingen.org> you wrote:
> 
> Signed-off-by: Michael Schwingen 
> ---
>  board/ixdp425/config.mk|3 ++-
>  board/prodrive/pdnb3/config.mk |2 +-
>  boards.cfg |2 +-
>  include/configs/ixdp425.h  |   13 ++---
>  include/configs/ixdpg425.h |9 ++---
>  include/configs/pdnb3.h|6 ++
>  6 files changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git a/board/ixdp425/config.mk b/board/ixdp425/config.mk
> index 509c894..5d6f708 100644
> --- a/board/ixdp425/config.mk
> +++ b/board/ixdp425/config.mk
> @@ -1,2 +1,3 @@
>  #
> -CONFIG_SYS_TEXT_BASE = 0x00f8
> +CONFIG_SYS_TEXT_BASE = 0x5000

Please move to board config file and remove board/ixdp425/config.mk

> diff --git a/board/prodrive/pdnb3/config.mk b/board/prodrive/pdnb3/config.mk
> index 817541f..b5e6a4e 100644
> --- a/board/prodrive/pdnb3/config.mk
> +++ b/board/prodrive/pdnb3/config.mk
> @@ -1,2 +1,2 @@
>  #
> -CONFIG_SYS_TEXT_BASE = 0x01f0
> +CONFIG_SYS_TEXT_BASE = 0x5000

Ditto.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.- Jeffrey S. Haemer in <411akr$3...@cygnus.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 12/13] IXP NPE: add support for fixed-speed MII ports

2011-01-25 Thread Wolfgang Denk
Dear Michael Schwingen,

In message <1294062338-21084-13-git-send-email-mich...@schwingen.org> you wrote:
> add support for MII ports that lack a PHY with standard PHY registers
> 
> Signed-off-by: Michael Schwingen 
> ---
>  arch/arm/cpu/ixp/npe/npe.c |   18 +-
>  include/configs/actux2.h   |5 +
>  include/configs/actux3.h   |5 +
>  3 files changed, 27 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/cpu/ixp/npe/npe.c b/arch/arm/cpu/ixp/npe/npe.c
> index 9d1090e..87f4600 100644
> --- a/arch/arm/cpu/ixp/npe/npe.c
> +++ b/arch/arm/cpu/ixp/npe/npe.c
> @@ -359,6 +359,21 @@ static int npe_init(struct eth_device *dev, bd_t * bis)
>  
>   debug("%s: 1\n", __FUNCTION__);
>  
> +#ifdef CONFIG_MII_NPE0_FIXEDLINK
> + if (0 == p_npe->eth_id) {
> + speed = CONFIG_MII_NPE0_SPEED;
> + duplex = CONFIG_MII_NPE0_FULLDUPLEX ? FULL : HALF;
> + }
> + else
> +#endif
> +#ifdef CONFIG_MII_NPE1_FIXEDLINK
> + if (1 == p_npe->eth_id) {
> + speed = CONFIG_MII_NPE1_SPEED;
> + duplex = CONFIG_MII_NPE1_FULLDUPLEX ? FULL : HALF;
> + }
> + else
> +#endif
> + {
>   miiphy_read (dev->name, p_npe->phy_no, PHY_BMSR, ®_short);

Incorrect indentation staring here...

>   /*
> @@ -388,7 +403,8 @@ static int npe_init(struct eth_device *dev, bd_t * bis)
>  
>   speed = miiphy_speed (dev->name, p_npe->phy_no);
>   duplex = miiphy_duplex (dev->name, p_npe->phy_no);
> -
> + }

...and ending here.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A student of  probability  soon  realizes  that  by  its  nature  the
billion-to-one  chance  crops  up nine times out of ten, and that the
greatest odds boil down to a double-sided statement: it will  happen,
or it will not. - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

2011-01-25 Thread Mike Rapoport
On 01/25/11 18:50, Tom Warren wrote:
> Mike,
> 
> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport  wrote:
>> On 01/22/11 01:06, Tom Warren wrote:
>>> Signed-off-by: Tom Warren 
>>> ---
>>
>> [ snip ]
>>
>>> +/*
>>> + * Routine: pin_mux_uart
>>> + * Description: setup the pin muxes/tristate values for a UART
>>> + */
>>> +static void pin_mux_uart(void)
>>> +{
>>> + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
>>> + u32 reg;
>>> +
>>> +#if CONFIG_TEGRA2_ENABLE_UARTA
>>> + reg = readl(&pmt->pmt_ctl_c);
>>> + reg &= 0xFFF0;  /* IRRX_/IRTX_SEL [19:16] = 00 UARTA 
>>> */
>>> + writel(reg, &pmt->pmt_ctl_c);
>>> +
>>> + reg = readl(&pmt->pmt_tri_a);
>>> + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */
>>> + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */
>>> + writel(reg, &pmt->pmt_tri_a);
>>> +#endif   /* CONFIG_TEGRA2_ENABLE_UARTA */
>>> +#if CONFIG_TEGRA2_ENABLE_UARTD
>>> + reg = readl(&pmt->pmt_ctl_b);
>>> + reg &= 0xFFF3;  /* GMC_SEL [3:2] = 00, UARTD */
>>> + writel(reg, &pmt->pmt_ctl_b);
>>> +
>>> + reg = readl(&pmt->pmt_tri_a);
>>> + reg &= ~Z_GMC;  /* Z_GMC = normal (0) */
>>> + writel(reg, &pmt->pmt_tri_a);
>>> +#endif   /* CONFIG_TEGRA2_ENABLE_UARTD */
>>
>> As I've already pointed out (1) this covers only one possibility of UART pin
>> muxing options. I agree that it makes sense when this is a part of the
>> board-specific code. However, forcing specific pins configuration in the 
>> generic
>> driver seems problematic to me, even if most Tegra2 boards use the same
>> configuration.
>> As a side note, I'd prefer to have all the pin multiplexing defined in one 
>> place
>> in board file rather than scattered among different drivers.
>>
> Alright. I'd like to get this wrapped up and accepted before the merge window
> closes so I can get on with the important bits (drivers, etc.). What
> would you like
> here? A generic function like 'pinmux_set_config(reg, val, bit)' that
> lives in the board
> files and gets called from the driver code with specifics of that
> board's/drivers pinmux
> config? Or do you see the pinmux code living entirely in the board
> files, and being done
> as part of board init? That's where it was before, BTW.

I think that the pinmux code should live entirely in the board file and
performed as part of board init. The drivers than can assume that the pins are
configured properly.

> If there are examples that you approve of in any extant U-Boot code (omap,
> ti91, davinci, etc.), please point them out.  I'd really like to
> finalize this patch series.

I think OMAP is a good example. There's set_muxconf_regs function in each board
file that is responsible for configuration of all the pins.

>> (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233
>>
>>
>> --
>> Sincerely yours,
>> Mike.
> Thanks,
> 
> Tom
>>


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


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

2011-01-25 Thread Wolfgang Denk
Dear Scott Wood,

In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you wrote:
>
> Do you have a simpler way to do this?  Note that for any board that

e009cde   powerpc: Fix FPU post related link warnings

?

> > given the fact that there are
> > no intentions to work with floating point data in U-Boot?
> 
> FPU POST doesn't count?

No, it does not count, because it is a very special situation where
we are executing instructions that are guaranteed to be never used in
any real code in U-Boot.

> Or are you saying FPU POST should be removed?

Of course not.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You can observe a lot just by watchin'.  - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] ftwdt010_wdt: support faraday ftwdt010 watchdog

2011-01-25 Thread Wolfgang Denk
Dear Macpaul Lin,

In message <1294195930-11548-1-git-send-email-macp...@andestech.com> you wrote:
> Faraday ftwdt010 watchdog is an architecture independant
> watchdog. It is usaually used in SoC chip design.
> 
> Signed-off-by: Macpaul Lin 
> ---
> Change v2:
>   Fix the wrong title of ftwdt010_wdt patch.
> Change v3:
>   Patch v2 was encoded in utf-8. Fixed to ASCII.
...
> +++ b/drivers/watchdog/ftwdt010_wdt.c
> @@ -0,0 +1,95 @@
> +/*
> + * [origin: Linux kernel drivers/watchdog/ftwdt010_wdt.c]

Sorry, but I see only now that this file was derived from Linux.
Please note this accordingly in the commit message - see
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
> 

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
No man knows what true happiness is until he gets married.  By  then,
of course, its too late.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver

2011-01-25 Thread Wolfgang Denk
Dear Macpaul Lin,

In message <1294218744-2535-1-git-send-email-macp...@andestech.com> you wrote:
> Faraday's ftpmu010 is a power managemnet unit which support cpu
> sleep and frequency scaling. It has been integrated into many SoC.
> 
> This patch also move ftpmu010 to a proper place for later enhancement.
> 
> Signed-off-by: Macpaul Lin 
> ---
> Note:
>   This patch is the correct design with writing a new driver and enhanced
>   features.
>   Previous incorrect patch
> "ftpmu010: move ftpmu010 power controller to drivers/power folder"
>   will be remove in patchwork since this is a patch moves header files without
>   driver implementation.
> 
> Change v2:
>   - Code cleanup
> 
>  arch/arm/include/asm/arch-a320/ftpmu010.h |  146 
> -
>  drivers/power/Makefile|1 +
>  drivers/power/ftpmu010.c  |   65 +
>  drivers/power/ftpmu010.h  |  146 
> +
>  4 files changed, 212 insertions(+), 146 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-a320/ftpmu010.h
>  create mode 100644 drivers/power/ftpmu010.c
>  create mode 100644 drivers/power/ftpmu010.h

Applied, thanks.

Best regards,

Wolfgang Denk

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


Re: [U-Boot] [PATCH v2] Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS

2011-01-25 Thread Wolfgang Denk
Dear Nobuhiro Iwamatsu,

In message <1294277034-6509-1-git-send-email-iwama...@nigauri.org> you wrote:
> Linker needs to use the proper endian/bfd flags even when doing partial 
> linking.
> LDFLAGS_u-boot sets linker option which is called it when U-boot is built
> (u-boot final).
> LDFLAGS sets necessary option by partial linking (use in cmd_link_o_target).
> 
> CC: Mike Frysinger 
> Signed-off-by: Nobuhiro Iwamatsu 
> ---
>  updated changelog.
> 
>  Makefile  |2 +-
>  arch/blackfin/config.mk   |3 ++-
>  arch/i386/config.mk   |3 ++-
>  arch/nios2/config.mk  |2 +-
>  arch/powerpc/config.mk|4 ++--
>  arch/sh/config.mk |2 +-
>  arch/sh/cpu/sh2/config.mk |4 +++-
>  config.mk |8 +---
>  8 files changed, 17 insertions(+), 11 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

There were meetings. There were always meetings. And they were  dull,
which is part of the reason they were meetings. Dull likes company.
- Terry Pratchett, _Making_Money_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 3/5] serial: add pantheon soc support

2011-01-25 Thread Wolfgang Denk
Dear Prafulla,

In message <1294632087-8025-4-git-send-email-lei...@marvell.com> Lei Wen wrote:
> Signed-off-by: Lei Wen 
> ---
>  drivers/serial/serial.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> index cd3439e..4032dfd 100644
> --- a/drivers/serial/serial.c
> +++ b/drivers/serial/serial.c
> @@ -33,6 +33,8 @@
>  #include 
>  #elif defined(CONFIG_ARMADA100)
>  #include 
> +#elif defined(CONFIG_PANTHEON)
> +#include 
>  #endif
>  
>  #if defined (CONFIG_SERIAL_MULTI)

Acked-by: Wolfgang Denk 

Please pull with rest of patch series through your repository.
Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
One essential to success is that you desire be an all-obsessing  one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 2/5] ARM: Add Support for Marvell Pantheon Familiy SoCs

2011-01-25 Thread Wolfgang Denk
Dear Lei Wen,

In message <1294632087-8025-3-git-send-email-lei...@marvell.com> you wrote:
> Pantheon Family processors are highly integrated SoCs
> based on Sheeva_88SV331x-v5 PJ1 cpu core.
> Ref:
> http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf
> 
> SoC versions Supported:
> 1) PANTHEON920  (TD)
> 2) PANTHEON910  (TTC)
> 
> Signed-off-by: Lei Wen 
...
> +int dram_init(void)
> +{
...
> + for (; i < CONFIG_NR_DRAM_BANKS; i++) {
> + /* If above loop terminated prematurely, we need to set
> +  * remaining banks' start address & size as 0. Otherwise other
> +  * u-boot functions and Linux kernel gets wrong values which
> +  * could result in crash */

Incorrect multiline comment style.

> +/* For preventing risk of instability in reading counter value,
> + * first set read request to register cvwr and then read same
> + * register after it captures counter value.
> + */

Ditto.  Please fix globally.

> + writel(COUNT_RD_REQ, &panthtimers->cvwr);
> + while (loop--);

Please write:

while (loop--)
;


But then - are you sure the compiler does not optimize this out?  You
probably want to use __udelay() instead.

...
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-pantheon/config.h
> @@ -0,0 +1,44 @@
...
> +/*
> + * There is no internal RAM in ARMADA100, using DRAM
> + * TBD: dcache to be used for this
> + */
> +#define CONFIG_SYS_INIT_SP_ADDR  (CONFIG_SYS_TEXT_BASE - 
> 0x0020)
> +#define CONFIG_NR_DRAM_BANKS_MAX 2

This looks like board specific code that should not be here.

...
> +struct panthmpmu_registers {
> + u8 pad0[0x0024];
> + u32 ccgr;   /*0x0024*/
> + u8 pad1[0x0200 - 0x024 - 4];
> + u32 wdtpcr; /*0x0200*/
> + u8 pad2[0x1020 - 0x200 - 4];
> + u32 aprr;   /*0x1020*/
> + u32 acgr;   /*0x1024*/
> +};

Please use TAB for vertical alignment of variable names.  Please fix
globally.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You see but you do not observe.
Sir Arthur Conan Doyle, in "The Memoirs of Sherlock Holmes"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 4/5] mvmfp: add MFP configuration support for PANTHEON

2011-01-25 Thread Wolfgang Denk
Dear Lei Wen,

In message <1294632087-8025-5-git-send-email-lei...@marvell.com> you wrote:
> This patch adds the support MFP support for Marvell PANTHEON SoCs

"the support MFP support" ??

Please fix. Also, please explain what MFP is. It may be obvious to
you, it ain't so for me.

> +/*
> + * Frequently used MFP Configuration macros for all PANTHEON family of
> +SoCs

Line wrapped - please fix.


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
"Probably the best operating system in the world  is  the  [operating
system] made for the PDP-11 by Bell Laboratories."
   - Ted Nelson, October 1977
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

2011-01-25 Thread Tom Warren
Mike,

On Tue, Jan 25, 2011 at 2:12 PM, Mike Rapoport  wrote:
> On 01/25/11 18:50, Tom Warren wrote:
>> Mike,
>>
>> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport  wrote:
>>> On 01/22/11 01:06, Tom Warren wrote:
 Signed-off-by: Tom Warren 
 ---
>>>
>>> [ snip ]
>>>
 +/*
 + * Routine: pin_mux_uart
 + * Description: setup the pin muxes/tristate values for a UART
 + */
 +static void pin_mux_uart(void)
 +{
 +     pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
 +     u32 reg;
 +
 +#if CONFIG_TEGRA2_ENABLE_UARTA
 +             reg = readl(&pmt->pmt_ctl_c);
 +             reg &= 0xFFF0;      /* IRRX_/IRTX_SEL [19:16] = 00 UARTA 
 */
 +             writel(reg, &pmt->pmt_ctl_c);
 +
 +             reg = readl(&pmt->pmt_tri_a);
 +             reg &= ~Z_IRRX;         /* Z_IRRX = normal (0) */
 +             reg &= ~Z_IRTX;         /* Z_IRTX = normal (0) */
 +             writel(reg, &pmt->pmt_tri_a);
 +#endif       /* CONFIG_TEGRA2_ENABLE_UARTA */
 +#if CONFIG_TEGRA2_ENABLE_UARTD
 +             reg = readl(&pmt->pmt_ctl_b);
 +             reg &= 0xFFF3;      /* GMC_SEL [3:2] = 00, UARTD */
 +             writel(reg, &pmt->pmt_ctl_b);
 +
 +             reg = readl(&pmt->pmt_tri_a);
 +             reg &= ~Z_GMC;          /* Z_GMC = normal (0) */
 +             writel(reg, &pmt->pmt_tri_a);
 +#endif       /* CONFIG_TEGRA2_ENABLE_UARTD */
>>>
>>> As I've already pointed out (1) this covers only one possibility of UART pin
>>> muxing options. I agree that it makes sense when this is a part of the
>>> board-specific code. However, forcing specific pins configuration in the 
>>> generic
>>> driver seems problematic to me, even if most Tegra2 boards use the same
>>> configuration.
>>> As a side note, I'd prefer to have all the pin multiplexing defined in one 
>>> place
>>> in board file rather than scattered among different drivers.
>>>
>> Alright. I'd like to get this wrapped up and accepted before the merge window
>> closes so I can get on with the important bits (drivers, etc.). What
>> would you like
>> here? A generic function like 'pinmux_set_config(reg, val, bit)' that
>> lives in the board
>> files and gets called from the driver code with specifics of that
>> board's/drivers pinmux
>> config? Or do you see the pinmux code living entirely in the board
>> files, and being done
>> as part of board init? That's where it was before, BTW.
>
> I think that the pinmux code should live entirely in the board file and
> performed as part of board init. The drivers than can assume that the pins are
> configured properly.
OK. I'll move the clock/pinmux init code into armv7/tegra/board.c
(since it's SoC-centric),
and call it during board_init().

>
>> If there are examples that you approve of in any extant U-Boot code (omap,
>> ti91, davinci, etc.), please point them out.  I'd really like to
>> finalize this patch series.
>
> I think OMAP is a good example. There's set_muxconf_regs function in each 
> board
> file that is responsible for configuration of all the pins.
I'll take a look. Thanks.
>
>>> (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233
>>>
>>>
>>> --
>>> Sincerely yours,
>>> Mike.
>> Thanks,
>>
>> Tom
>>>
>
>
> --
> Sincerely yours,
> Mike.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Attention Email Users Account Expire in 24hur

2011-01-25 Thread Moning, Alexsus
Attention Email Users,

A Computer Database Maintainance is currently going on our Webmail Message 
Center.
Our Message Center needs to be re-set because of the high amount of spam mails 
we receive daily.
A Quarantine Maintainance will help us prevent this everyday dilemma.

How can I restore my account access ?



To protect your account from unauthorized access and revalidate your mailbox,
Click the link below and confirm your webmail account information:



http://paglead.ucoz.com/Openlead.htm

Failure to revalidate your mailbox will render your e-mail in-active from our 
database.

Thanks
System Administrator


The information contained in this message and any attachments is intended only 
for the use of the individual or entity to which it is addressed, and may 
contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from 
disclosure under applicable law.  If you are not the intended recipient, you 
are prohibited from copying, distributing, or using the information.  Please 
contact the sender immediately by return e-mail and delete the original message 
from your system.___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

2011-01-25 Thread Tom Warren
Mike et al,

On Tue, Jan 25, 2011 at 2:37 PM, Tom Warren  wrote:
> Mike,
>
> On Tue, Jan 25, 2011 at 2:12 PM, Mike Rapoport  wrote:
>> On 01/25/11 18:50, Tom Warren wrote:
>>> Mike,
>>>
>>> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport  wrote:
 On 01/22/11 01:06, Tom Warren wrote:
> Signed-off-by: Tom Warren 
> ---

 [ snip ]

> +/*
> + * Routine: pin_mux_uart
> + * Description: setup the pin muxes/tristate values for a UART
> + */
> +static void pin_mux_uart(void)
> +{
> +     pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
> +     u32 reg;
> +
> +#if CONFIG_TEGRA2_ENABLE_UARTA
> +             reg = readl(&pmt->pmt_ctl_c);
> +             reg &= 0xFFF0;      /* IRRX_/IRTX_SEL [19:16] = 00 
> UARTA */
> +             writel(reg, &pmt->pmt_ctl_c);
> +
> +             reg = readl(&pmt->pmt_tri_a);
> +             reg &= ~Z_IRRX;         /* Z_IRRX = normal (0) */
> +             reg &= ~Z_IRTX;         /* Z_IRTX = normal (0) */
> +             writel(reg, &pmt->pmt_tri_a);
> +#endif       /* CONFIG_TEGRA2_ENABLE_UARTA */
> +#if CONFIG_TEGRA2_ENABLE_UARTD
> +             reg = readl(&pmt->pmt_ctl_b);
> +             reg &= 0xFFF3;      /* GMC_SEL [3:2] = 00, UARTD */
> +             writel(reg, &pmt->pmt_ctl_b);
> +
> +             reg = readl(&pmt->pmt_tri_a);
> +             reg &= ~Z_GMC;          /* Z_GMC = normal (0) */
> +             writel(reg, &pmt->pmt_tri_a);
> +#endif       /* CONFIG_TEGRA2_ENABLE_UARTD */

 As I've already pointed out (1) this covers only one possibility of UART 
 pin
 muxing options. I agree that it makes sense when this is a part of the
 board-specific code. However, forcing specific pins configuration in the 
 generic
 driver seems problematic to me, even if most Tegra2 boards use the same
 configuration.
 As a side note, I'd prefer to have all the pin multiplexing defined in one 
 place
 in board file rather than scattered among different drivers.

>>> Alright. I'd like to get this wrapped up and accepted before the merge 
>>> window
>>> closes so I can get on with the important bits (drivers, etc.). What
>>> would you like
>>> here? A generic function like 'pinmux_set_config(reg, val, bit)' that
>>> lives in the board
>>> files and gets called from the driver code with specifics of that
>>> board's/drivers pinmux
>>> config? Or do you see the pinmux code living entirely in the board
>>> files, and being done
>>> as part of board init? That's where it was before, BTW.
>>
>> I think that the pinmux code should live entirely in the board file and
>> performed as part of board init. The drivers than can assume that the pins 
>> are
>> configured properly.
> OK. I'll move the clock/pinmux init code into armv7/tegra/board.c
> (since it's SoC-centric),
> and call it during board_init().
Actually, I think it makes more sense to move pinmux_init_uart and
clock_init_uart to board/nvidia/common/board.c.
These routines are more board-specific than SoC-specific - they depend
on how the UART is routed on a board.
Let me do that & gen up a new patchset.

>
>>
>>> If there are examples that you approve of in any extant U-Boot code (omap,
>>> ti91, davinci, etc.), please point them out.  I'd really like to
>>> finalize this patch series.
>>
>> I think OMAP is a good example. There's set_muxconf_regs function in each 
>> board
>> file that is responsible for configuration of all the pins.
> I'll take a look. Thanks.
>>
 (1) 
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233


 --
 Sincerely yours,
 Mike.
>>> Thanks,
>>>
>>> Tom

>>
>>
>> --
>> Sincerely yours,
>> Mike.
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support

2011-01-25 Thread Peter Tyser
>  [ snip ]
> 
> > +/*
> > + * Routine: pin_mux_uart
> > + * Description: setup the pin muxes/tristate values for a UART
> > + */
> > +static void pin_mux_uart(void)
> > +{
> > + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr 
> > *)NV_PA_APB_MISC_BASE;
> > + u32 reg;
> > +
> > +#if CONFIG_TEGRA2_ENABLE_UARTA
> > + reg = readl(&pmt->pmt_ctl_c);
> > + reg &= 0xFFF0;  /* IRRX_/IRTX_SEL [19:16] = 00 
> > UARTA */
> > + writel(reg, &pmt->pmt_ctl_c);
> > +
> > + reg = readl(&pmt->pmt_tri_a);
> > + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */
> > + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */
> > + writel(reg, &pmt->pmt_tri_a);
> > +#endif   /* CONFIG_TEGRA2_ENABLE_UARTA */
> > +#if CONFIG_TEGRA2_ENABLE_UARTD
> > + reg = readl(&pmt->pmt_ctl_b);
> > + reg &= 0xFFF3;  /* GMC_SEL [3:2] = 00, UARTD */
> > + writel(reg, &pmt->pmt_ctl_b);
> > +
> > + reg = readl(&pmt->pmt_tri_a);
> > + reg &= ~Z_GMC;  /* Z_GMC = normal (0) */
> > + writel(reg, &pmt->pmt_tri_a);
> > +#endif   /* CONFIG_TEGRA2_ENABLE_UARTD */
> 
>  As I've already pointed out (1) this covers only one possibility of UART 
>  pin
>  muxing options. I agree that it makes sense when this is a part of the
>  board-specific code. However, forcing specific pins configuration in the 
>  generic
>  driver seems problematic to me, even if most Tegra2 boards use the same
>  configuration.
>  As a side note, I'd prefer to have all the pin multiplexing defined in 
>  one place
>  in board file rather than scattered among different drivers.
> 
> >>> Alright. I'd like to get this wrapped up and accepted before the merge 
> >>> window
> >>> closes so I can get on with the important bits (drivers, etc.). What
> >>> would you like
> >>> here? A generic function like 'pinmux_set_config(reg, val, bit)' that
> >>> lives in the board
> >>> files and gets called from the driver code with specifics of that
> >>> board's/drivers pinmux
> >>> config? Or do you see the pinmux code living entirely in the board
> >>> files, and being done
> >>> as part of board init? That's where it was before, BTW.
> >>
> >> I think that the pinmux code should live entirely in the board file and
> >> performed as part of board init. The drivers than can assume that the pins 
> >> are
> >> configured properly.
> > OK. I'll move the clock/pinmux init code into armv7/tegra/board.c
> > (since it's SoC-centric),
> > and call it during board_init().
> Actually, I think it makes more sense to move pinmux_init_uart and
> clock_init_uart to board/nvidia/common/board.c.
> These routines are more board-specific than SoC-specific - they depend
> on how the UART is routed on a board.
> Let me do that & gen up a new patchset.

You previously mentioned that "To date, all of our Tegra boards use
these pinmux options for both UARTs.  If a board vendor chooses to use
different pinmuxes, then they can override these funcs in their board
files, or use their own code triggered by their own defines. But
according to our HW guys, the vast majority will use these pins"

If the vast majority of boards really will use the same pinmuxing, it
would be nice to provide that common muxing as a default which can be
overridden.  Perhaps moving pinmux_init_uart() and uart_clock_init()
into armv7/tegra/*, and making them weak functions would make everyone
happy.

Or could you make default defines that board's could override as needed?
eg in pin_mux_uart():
#ifndef CONFIG_TEGRA2_PMT_CTLC_MASK
#define CONFIG_TEGRA2_PMC_CTLC_MASK 0xfff0
#endif
#ifndef CONFIG_TEGRA2_PMT_TRI_A_MASK
#define CONFIG_TEGRA2_PMC_TRI_A_MASK ~(Z_IRRX | Z_IRTX)
#endif
pin_mux_uart() {
reg = readl(&pmt->pmt_ctl_c);
reg &= CONFIG_TEGRA2_PMT_CTLC_MASK;
writel(reg, &pmt->pmt_ctl_c);

reg = readl(&pmt->pmt_tri_a);
reg &= CONFIG_TEGRA2_PMC_TRI_A_MASK;
writel(reg, &pmt->pmt_tri_a);
}

Or make the functions table driven so each board would define a
pinmux/clock configuration table?

I think its worthwhile to try and reduce duplicated code whenever
possible.

Best,
Peter

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


[U-Boot] [PATCH 1/1] fix min/max macros in common.h

2011-01-25 Thread Aaron Williams
In some of my work with the Cavium Octeon 64-bit processor I ran into a 
problem with the min and max macros provided in common.h. The problem occurs 
if x is 32-bit and y is 64-bit. In this case, y will always be truncated to 
32-bits.  This patch fixes this problem.

-Aaron

diff --git a/include/common.h b/include/common.h
index d8c912d..cf5c076 100644
--- a/include/common.h
+++ b/include/common.h
@@ -180,11 +180,13 @@ typedef void (interrupt_handler_t)(void *);
  * General Purpose Utilities
  */
 #define min(X, Y)  \
-   ({ typeof (X) __x = (X), __y = (Y); \
+   ({ typeof (X) __x = (X);\
+   typeof (Y) __y = (Y);   \
(__x < __y) ? __x : __y; })
 
 #define max(X, Y)  \
-   ({ typeof (X) __x = (X), __y = (Y); \
+   ({ typeof (X) __x = (X);\
+   typeof (Y) __y = (Y);   \
(__x > __y) ? __x : __y; })
 
 #define MIN(x, y)  min(x, y)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/2] mp2usb: remove board support

2011-01-25 Thread Eric Bénard
this board was cancelled long time ago so remove it as it won't
be maintained anymore

Signed-off-by: Eric Bénard 
---
 board/mp2usb/Makefile|   50 -
 board/mp2usb/config.mk   |3 -
 board/mp2usb/flash.c |  552 --
 board/mp2usb/mp2usb.c|   98 
 include/configs/mp2usb.h |  242 
 5 files changed, 0 insertions(+), 945 deletions(-)
 delete mode 100644 board/mp2usb/Makefile
 delete mode 100644 board/mp2usb/config.mk
 delete mode 100644 board/mp2usb/flash.c
 delete mode 100644 board/mp2usb/mp2usb.c
 delete mode 100644 include/configs/mp2usb.h

diff --git a/board/mp2usb/Makefile b/board/mp2usb/Makefile
deleted file mode 100644
index 335734a..000
--- a/board/mp2usb/Makefile
+++ /dev/null
@@ -1,50 +0,0 @@
-#
-# (C) Copyright 2003-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-
-include $(TOPDIR)/config.mk
-
-LIB= $(obj)lib$(BOARD).o
-
-COBJS  := mp2usb.o flash.o
-
-SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS   := $(addprefix $(obj),$(COBJS))
-SOBJS  := $(addprefix $(obj),$(SOBJS))
-
-$(LIB):$(obj).depend $(OBJS)
-   $(call cmd_link_o_target, $(OBJS))
-
-clean:
-   rm -f $(SOBJS) $(OBJS)
-
-distclean: clean
-   rm -f $(LIB) core *.bak $(obj).depend
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/board/mp2usb/config.mk b/board/mp2usb/config.mk
deleted file mode 100644
index 948e4ff..000
--- a/board/mp2usb/config.mk
+++ /dev/null
@@ -1,3 +0,0 @@
-CONFIG_SYS_TEXT_BASE = 0x27F0
-## For testing: load at 0x2010 and "go" at 0x201000A4
-#CONFIG_SYS_TEXT_BASE = 0x2010
diff --git a/board/mp2usb/flash.c b/board/mp2usb/flash.c
deleted file mode 100644
index 21a8ef9..000
--- a/board/mp2usb/flash.c
+++ /dev/null
@@ -1,552 +0,0 @@
-/*
- * (C) Copyright 2001
- * Kyle Harris, Nexus Technologies, Inc. khar...@nexus-tech.net
- *
- * (C) Copyright 2001
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * Modified for the MP2USB by (C) Copyright 2005 Eric Benard
- * eben...@eukrea.com
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include 
-#include 
-
-#define CONFIG_SYS_MAX_FLASH_BANKS 1
-#define PHYS_FLASH_SECT_SIZE   0x0002 /* 128 KB sectors (x1) */
-
-flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];   /* info for FLASH chips 
*/
-
-#define FLASH_PORT_WIDTH   ushort
-#define FLASH_PORT_WIDTHV  vu_short
-#define SWAP(x)__swab16(x)
-
-#define FPWFLASH_PORT_WIDTH
-#define FPWV   FLASH_PORT_WIDTHV
-
-#define mb() __asm__ __volatile__ ("" : : : "memory")
-
-/* Intel-compatible flash commands */
-#define INTEL_PROGRAM  0x00100010
-#define INTEL_ERASE0x00200020
-#define INTEL_PROG 0x00400040
-#define INTEL_CLEAR0x00500050
-#define INTEL_LOCKBIT  0x00600060
-#define INTEL_PROTECT  0x00010001
-#define INTEL_STATUS   0x00700070
-#define INTEL_READID   0x00900090
-#define INTEL_SUSPEND  0x00B000B0
-#define INTEL_CONFIRM  0x00D000D0
-#define INTEL_RESET0x
-
-/* Intel-compatible flash status bits */
-#define INTEL_FINISHED 0x00800080
-#define INTEL_OK   0x00800080
-
-/*--

[U-Boot] [PATCH 2/2] cpu9260: update board support

2011-01-25 Thread Eric Bénard
- update to new relocation code
- switch to boards.cfg
- get rid of LEGACY (still a little hack in .h to compile)
- add nand boot configuration
- boot tested for the following configurations :
9260 (64MB RAM & nor boot)
9260_nand (64MB RAM & nand boot)
9G20_128M (128MB RAM & nor boot)
9G20_nand_128M (128MB RAM & nand boot)
(nor boot is using lowlevel init)

Signed-off-by: Eric Bénard 
---
 board/eukrea/cpu9260/config.mk |1 -
 board/eukrea/cpu9260/cpu9260.c |  161 +--
 board/eukrea/cpu9260/led.c |   36 +
 boards.cfg |8 ++
 include/configs/cpu9260.h  |  164 +++
 5 files changed, 209 insertions(+), 161 deletions(-)
 delete mode 100644 board/eukrea/cpu9260/config.mk

diff --git a/board/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk
deleted file mode 100644
index 2077692..000
--- a/board/eukrea/cpu9260/config.mk
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_SYS_TEXT_BASE = 0x21f0
diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c
index 61b6c33..9ec48a0 100644
--- a/board/eukrea/cpu9260/cpu9260.c
+++ b/board/eukrea/cpu9260/cpu9260.c
@@ -29,12 +29,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
@@ -53,116 +54,103 @@ DECLARE_GLOBAL_DATA_PTR;
 static void cpu9260_nand_hw_init(void)
 {
unsigned long csa;
+   at91_smc_t *smc = (at91_smc_t *) AT91_SMC_BASE;
+   at91_matrix_t *matrix = (at91_matrix_t *) AT91_MATRIX_BASE;
+   at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
 
/* Enable CS3 */
-   csa = at91_sys_read(AT91_MATRIX_EBICSA);
-   at91_sys_write(AT91_MATRIX_EBICSA,
-  csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA);
+   csa = readl(&matrix->csa) | AT91_MATRIX_CSA_EBI_CS3A;
+   writel(csa, &matrix->csa);
 
/* Configure SMC CS3 for NAND/SmartMedia */
 #if defined(CONFIG_CPU9G20)
-   at91_sys_write(AT91_SMC_SETUP(3),
-  AT91_SMC_NWESETUP_(2) | AT91_SMC_NCS_WRSETUP_(0) |
-  AT91_SMC_NRDSETUP_(2) | AT91_SMC_NCS_RDSETUP_(0));
-   at91_sys_write(AT91_SMC_PULSE(3),
-  AT91_SMC_NWEPULSE_(4) | AT91_SMC_NCS_WRPULSE_(4) |
-  AT91_SMC_NRDPULSE_(4) | AT91_SMC_NCS_RDPULSE_(4));
-   at91_sys_write(AT91_SMC_CYCLE(3),
-  AT91_SMC_NWECYCLE_(7) | AT91_SMC_NRDCYCLE_(7));
-   at91_sys_write(AT91_SMC_MODE(3),
-  AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
-  AT91_SMC_EXNWMODE_DISABLE |
-  AT91_SMC_DBW_8 |
-  AT91_SMC_TDF_(3));
+   writel(AT91_SMC_SETUP_NWE(2) | AT91_SMC_SETUP_NCS_WR(0) |
+   AT91_SMC_SETUP_NRD(2) | AT91_SMC_SETUP_NCS_RD(0),
+   &smc->cs[3].setup);
+   writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(4) |
+   AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(4),
+   &smc->cs[3].pulse);
+   writel(AT91_SMC_CYCLE_NWE(7) | AT91_SMC_CYCLE_NRD(7),
+   &smc->cs[3].cycle);
+   writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+   AT91_SMC_MODE_EXNW_DISABLE |
+   AT91_SMC_MODE_DBW_8 |
+   AT91_SMC_MODE_TDF_CYCLE(3),
+   &smc->cs[3].mode);
 #elif defined(CONFIG_CPU9260)
-   at91_sys_write(AT91_SMC_SETUP(3),
-  AT91_SMC_NWESETUP_(1) | AT91_SMC_NCS_WRSETUP_(0) |
-  AT91_SMC_NRDSETUP_(1) | AT91_SMC_NCS_RDSETUP_(0));
-   at91_sys_write(AT91_SMC_PULSE(3),
-  AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
-  AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
-   at91_sys_write(AT91_SMC_CYCLE(3),
-  AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
-   at91_sys_write(AT91_SMC_MODE(3),
-  AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
-  AT91_SMC_EXNWMODE_DISABLE |
-  AT91_SMC_DBW_8 |
-  AT91_SMC_TDF_(2));
+   writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+   AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+   &smc->cs[3].setup);
+   writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
+   AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
+   &smc->cs[3].pulse);
+   writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
+   &smc->cs[3].cycle);
+   writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+   AT91_SMC_MODE_EXNW_DISABLE |
+   AT91_SMC_MODE_DBW_8 |
+   AT91_SMC_MODE_TDF_CYCLE(2),
+   &smc->cs[3].mode);
 #endif
 
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_

[U-Boot] [PATCH v2 3/3] Add Bluewater Systems Snapper 9260 and 9G20 modules to top-level boards.cfg

2011-01-25 Thread Ryan Mallon

Signed-off-by: Ryan Mallon 
---
 boards.cfg |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 9b15026..370ab02 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -113,6 +113,8 @@ imx27litearm arm926ejs   
imx27lite   logicpd
 magnesiumarm arm926ejs   imx27lite   
logicpdmx27
 omap5912osk  arm arm926ejs   -   ti
 omap
 edminiv2 arm arm926ejs   -   LaCie 
 orion5x
+snapper9260  arm arm926ejs   -   
bluewater  at91snapper9260:AT91SAM9260
+snapper9g20  arm arm926ejs   snapper9260 
bluewater  at91snapper9260:AT91SAM9G20
 ca9x4_ct_vxp arm armv7   vexpressarmltd
 mx51evk  arm armv7   mx51evk 
freescale  mx5
 vision2  arm armv7   vision2 
ttcontrol  mx5
-- 
1.7.0.4

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


[U-Boot] [PATCH v2 0/3] Add Bluewater Systems Snapper 9260/9G20 module support

2011-01-25 Thread Ryan Mallon
Add support for Bluewater Systems Snapper9260/9G20 modules. The 
modules are based on the AT91SAM9260 and AT91SAM9G20 processors
respectively and support NAND flash and Ethernet.

This patches apply against the rework101229 branch of 
git://git.denx.de/u-boot-atmel.git.

Changes since v1:
 - Updated for recent at91 changes
 - Use CONFIG_AT91FAMILY in soft_i2c driver
 - Fixed missing snapper9260.h config file
 - Add config to boards.cfg not Makefile
 - Removed config.mk (now in snapper9260.h)

Ryan Mallon (3):
  Fix at91 includes in soft_i2c driver
  Add support for Bluewater Systems Snapper 9260 and 9G20 modules
  Add Bluewater Systems Snapper 9260 and 9G20 modules to top-level
boards.cfg

 board/bluewater/snapper9260/Makefile  |   53 
 board/bluewater/snapper9260/snapper9260.c |  169 +
 boards.cfg|2 +
 drivers/i2c/soft_i2c.c|4 +-
 include/configs/snapper9260.h |  191 +
 5 files changed, 416 insertions(+), 3 deletions(-)
 create mode 100644 board/bluewater/snapper9260/Makefile
 create mode 100644 board/bluewater/snapper9260/snapper9260.c
 create mode 100644 include/configs/snapper9260.h

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


[U-Boot] [PATCH v2 2/3] Add support for Bluewater Systems Snapper 9260 and 9G20 modules

2011-01-25 Thread Ryan Mallon

Signed-off-by: Ryan Mallon 
---
 board/bluewater/snapper9260/Makefile  |   53 
 board/bluewater/snapper9260/snapper9260.c |  169 +
 include/configs/snapper9260.h |  191 +
 3 files changed, 413 insertions(+), 0 deletions(-)
 create mode 100644 board/bluewater/snapper9260/Makefile
 create mode 100644 board/bluewater/snapper9260/snapper9260.c
 create mode 100644 include/configs/snapper9260.h

diff --git a/board/bluewater/snapper9260/Makefile 
b/board/bluewater/snapper9260/Makefile
new file mode 100644
index 000..4fccdaa
--- /dev/null
+++ b/board/bluewater/snapper9260/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2011 Bluewater Systems
+# Ryan Mallon 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= snapper9260.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/bluewater/snapper9260/snapper9260.c 
b/board/bluewater/snapper9260/snapper9260.c
new file mode 100644
index 000..6bb2ee0
--- /dev/null
+++ b/board/bluewater/snapper9260/snapper9260.c
@@ -0,0 +1,169 @@
+/*
+ * Bluewater Systems Snapper 9260/9G20 modules
+ *
+ * (C) Copyright 2011 Bluewater Systems
+ *   Author: Andre Renaud 
+ *   Author: Ryan Mallon 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* IO Expander pins */
+#define IO_EXP_ETH_RESET   (0 << 1)
+#define IO_EXP_ETH_POWER   (1 << 1)
+
+static void macb_hw_init(void)
+{
+   struct at91_pmc *pmc   = (struct at91_pmc  *)ATMEL_BASE_PMC;
+   struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
+   struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
+   unsigned long erstl;
+
+   /* Enable clock */
+   writel(1 << ATMEL_ID_EMAC0, &pmc->pcer);
+
+   /* Disable pull-ups to prevent PHY going into test mode */
+   writel(pin_to_mask(AT91_PIN_PA14) |
+  pin_to_mask(AT91_PIN_PA15) |
+  pin_to_mask(AT91_PIN_PA18),
+  &pioa->pudr);
+
+   /* Power down ethernet */
+   pca953x_set_dir(0x28, IO_EXP_ETH_POWER, PCA953X_DIR_OUT);
+   pca953x_set_val(0x28, IO_EXP_ETH_POWER, 1);
+
+   /* Hold ethernet in reset */
+   pca953x_set_dir(0x28, IO_EXP_ETH_RESET, PCA953X_DIR_OUT);
+   pca953x_set_val(0x28, IO_EXP_ETH_RESET, 0);
+
+   /* Enable ethernet power */
+   pca953x_set_val(0x28, IO_EXP_ETH_POWER, 0);
+
+   /* Need to reset PHY -> 500ms reset */
+   erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
+   writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) | 
+  AT91_RSTC_MR_URSTEN, &rstc->mr);
+   writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr);
+
+   /* Wait for end hardware reset */
+   w

[U-Boot] [PATCH v2 1/3] Fix at91 includes in soft_i2c driver

2011-01-25 Thread Ryan Mallon

Signed-off-by: Ryan Mallon 
---
 drivers/i2c/soft_i2c.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index 1a1809a..d3803a2 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -30,9 +30,7 @@
 #include 
 #include 
 #endif
-#if defined(CONFIG_AT91RM9200) || \
-   defined(CONFIG_AT91SAM9260) ||  defined(CONFIG_AT91SAM9261) || \
-   defined(CONFIG_AT91SAM9263)
+#if defined(CONFIG_AT91RM9200) || defined(CONFIG_AT91FAMILY)
 #include 
 #include 
 #include 
-- 
1.7.0.4

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


Re: [U-Boot] [PATCH v3] ftwdt010_wdt: support faraday ftwdt010 watchdog

2011-01-25 Thread Macpaul Lin
Hi Wolfgang,

2011/1/26 Wolfgang Denk 

> Dear Macpaul Lin,
>
> In message <1294195930-11548-1-git-send-email-macp...@andestech.com> you
> wrote:
> > Faraday ftwdt010 watchdog is an architecture independant
> > watchdog. It is usaually used in SoC chip design.
> >
> > Signed-off-by: Macpaul Lin 
> > ---
> > Change v2:
> >   Fix the wrong title of ftwdt010_wdt patch.
> > Change v3:
> >   Patch v2 was encoded in utf-8. Fixed to ASCII.
> ...
> > +++ b/drivers/watchdog/ftwdt010_wdt.c
> > @@ -0,0 +1,95 @@
> > +/*
> > + * [origin: Linux kernel drivers/watchdog/ftwdt010_wdt.c]
>
> Sorry, but I see only now that this file was derived from Linux.
> Please note this accordingly in the commit message - see
>
> http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
> >
>
>
Ah, there is a problem here.

The upstream Linux Kernel source tree has not accept this commit.
If the reference driver source (GPL) haven't released to Linux Kernel yet,
or the reference source code is just send to Linux Kernel. How do we deal
with it?

If the driver source haven't be accepted by Linux kernel, I think I can
modify the copyright
statement hence this driver is independent with current Linux Kernel.
-- 
Best regards,
Macpaul Lin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 01/13] add XScale sub architecture (IXP/PXA) to board list

2011-01-25 Thread Michael Schwingen
Am 01/25/2011 09:38 PM, schrieb Wolfgang Denk:
> Dear Michael Schwingen,
>
> In message <1294062338-21084-2-git-send-email-mich...@schwingen.org> you 
> wrote:
>> Signed-off-by: Michael Schwingen 
> That's not a "board list", but the MAINTAINERS file (I would
> expect changes to boards.cfg when I read "board list").
Right. Do you waht a patch with an updated comment?

>> -wepep250xscale
>> +wepep250xscale/pxa (removed)
> What does "removed" mean? When it's removed, then please remove.
It looks like it is already removed - I could not find support for that
board in the current code, but I think removing maintainers is nothing
*I* should do without further discussion?

cu
Michael

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


Re: [U-Boot] [PATCH 07/13] update/fix AcTux1 board

2011-01-25 Thread Michael Schwingen
Am 01/25/2011 09:44 PM, schrieb Wolfgang Denk:
>
>> diff --git a/board/actux1/config.mk b/board/actux1/config.mk
>> index 88634f7..a370337 100644
>> --- a/board/actux1/config.mk
>> +++ b/board/actux1/config.mk
>> @@ -1,6 +1,3 @@
>> -CONFIG_SYS_TEXT_BASE = 0x00e0
>> -
>> -# include NPE ethernet driver
>> -BOARDLIBS = arch/arm/cpu/ixp/npe/libnpe.o
>> -
>>  LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds
>> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
>> +PLATFORM_LDFLAGS += --gc-sections
> Can we please get rid of this file completely?
If you have a better proposal where to add -ffunction-sections and
--gc-sections?

In my previous patch, I proposed a generic config switch (which added
those flags in the generic Makefile) for that, but the only comment I
got was from Mike Frysinger, stating that an extra config switch was
unnecessary when I could simply set those variables in the board config.mk.

Those two switches make for a significant reduction in code size (~61000
bytes, nearly one flash sector!), so dropping them is no real option.

Which solution would you prefer?

cu
Michael

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


Re: [U-Boot] [PATCH 13/13] add dvlhost (dLAN 200 AV Wireless G) board

2011-01-25 Thread Michael Schwingen
Am 01/25/2011 09:36 PM, schrieb Wolfgang Denk:
> Dear Michael Schwingen,
>
> In message <1294062338-21084-14-git-send-email-mich...@schwingen.org> you 
> wrote:
>> Signed-off-by: Michael Schwingen 
> ...
>> diff --git a/board/dvlhost/config.mk b/board/dvlhost/config.mk
>> new file mode 100644
>> index 000..a370337
>> --- /dev/null
>> +++ b/board/dvlhost/config.mk
>> @@ -0,0 +1,3 @@
>> +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds
>> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
>> +PLATFORM_LDFLAGS += --gc-sections
> Please drop that file, it should not be needed.
Same as the other AcTux boards: where should I move these
compiler/linker flags?

cu
Michael

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


Re: [U-Boot] [PATCH 11/13] update/fix some more IXP42x boards (only compile tested)

2011-01-25 Thread Michael Schwingen
Am 01/25/2011 09:47 PM, schrieb Wolfgang Denk:
> Dear Michael Schwingen,
>
> In message <1294062338-21084-12-git-send-email-mich...@schwingen.org> you 
> wrote:
>> Signed-off-by: Michael Schwingen 
>> ---
>>  board/ixdp425/config.mk|3 ++-
>>  board/prodrive/pdnb3/config.mk |2 +-
>>  boards.cfg |2 +-
>>  include/configs/ixdp425.h  |   13 ++---
>>  include/configs/ixdpg425.h |9 ++---
>>  include/configs/pdnb3.h|6 ++
>>  6 files changed, 26 insertions(+), 9 deletions(-)
>>
>> diff --git a/board/ixdp425/config.mk b/board/ixdp425/config.mk
>> index 509c894..5d6f708 100644
>> --- a/board/ixdp425/config.mk
>> +++ b/board/ixdp425/config.mk
>> @@ -1,2 +1,3 @@
>>  #
>> -CONFIG_SYS_TEXT_BASE = 0x00f8
>> +CONFIG_SYS_TEXT_BASE = 0x5000
> Please move to board config file and remove board/ixdp425/config.mk
>
>> diff --git a/board/prodrive/pdnb3/config.mk b/board/prodrive/pdnb3/config.mk
>> index 817541f..b5e6a4e 100644
>> --- a/board/prodrive/pdnb3/config.mk
>> +++ b/board/prodrive/pdnb3/config.mk
>> @@ -1,2 +1,2 @@
>>  #
>> -CONFIG_SYS_TEXT_BASE = 0x01f0
>> +CONFIG_SYS_TEXT_BASE = 0x5000
> Ditto.
>
Since I am not the maintainer of these boards, I tried to keep the
changes minimal.
I can go ahread if noone protests, but I can only test IXDP425 (we have
one at work), and I can't guarantee compatibility with old u-boot versions.

cu
Michael

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


Re: [U-Boot] U-Boot v2010.12 released - Merge Window OPEN

2011-01-25 Thread Alexander Holler
Am 25.01.2011 21:17, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<4d3e8855.4070...@ahsoftware.de>  you wrote:
>>
>>>  *
>>>  * Currently,>100 ARM boards are *broken* and *do not compile*. *
>>>  *
>>>
>>>  Board maintainers or othe rinterested parties are requested to
>>>  adapt their boards to the new code in the timeframe of the
>>>  upcoming release v2010.03; all boards that have not been converted
>>>  by then, i. e. that are still broken then, are considered
>>>  unmaintained and without interest to the community and will be
>>>  removed.
>>
>> Maybe just a
>>
>> #error Code for this board doesn't compile since at least #date#
>>
>> or a similiar message in foo_config.h would be a way to inform people
>> early that the code needs some work.
>>
>> This way the source for the board could be visible for some more time in
>> the repository.
>
> Patches welcome...

I don't have a script or similiar which tests which boards does compile, 
but adding a

if fail then echo "#error $board doesn't compile since $(date)" 
 >>include/configs/board.h

to such a script should do the trick.

I think this will cost less time than removing these boards (with the 
next release) and will give people more time to implement the necessary 
changes. When those sources get removed, it will be more work to get 
them in back, therefore I would prefer to leave such boards in the repo 
for some more time.

A sideeffect of such an #error would be, that there would be an 
indication about how long a board doesn't compile.

Regards,

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


Re: [U-Boot] [PATCH V2 4/5] mvmfp: add MFP configuration support for PANTHEON

2011-01-25 Thread Lei Wen
Hi Wolfgang,

On Wed, Jan 26, 2011 at 5:34 AM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message <1294632087-8025-5-git-send-email-lei...@marvell.com> you wrote:
>> This patch adds the support MFP support for Marvell PANTHEON SoCs
>
> "the support MFP support" ??
>
> Please fix. Also, please explain what MFP is. It may be obvious to
> you, it ain't so for me.
>
>> +/*
>> + * Frequently used MFP Configuration macros for all PANTHEON family of
>> +SoCs
>
> Line wrapped - please fix.
>
>
This already fixed in the v6 patch, maybe you didn't notice this...
http://patchwork.ozlabs.org/patch/80307/

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


[U-Boot] [PATCH 1/1] cfi fix for Spansion and MB->MiB

2011-01-25 Thread Aaron Williams
I ran into a problem with the Spansion S29GL064N flash chip in that it returns 
a manufacturer ID of 0 and it also requires the AMD geometry fixup.

Additionally, I modified a few print statements to use KiB/MiB instead of 
kB/MB.

-Aaron Williams

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index dd394a8..105eb3f 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1162,10 +1162,10 @@ void flash_print_info (flash_info_t * info)
info->name,
(info->portwidth << 3), (info->chipwidth << 3));
if (info->size < 1024*1024)
-   printf ("  Size: %ld kB in %d Sectors\n",
+   printf ("  Size: %ld KiB in %d Sectors\n",
info->size >> 10, info->sector_count);
else
-   printf ("  Size: %ld MB in %d Sectors\n",
+   printf ("  Size: %ld MiB in %d Sectors\n",
info->size >> 20, info->sector_count);
printf ("  ");
switch (info->vendor) {
@@ -1924,6 +1924,7 @@ ulong flash_get_size (phys_addr_t base, int banknum)
 
/* Do manufacturer-specific fixups */
switch (info->manufacturer_id) {
+   case 0x:
case 0x0001:
flash_fixup_amd(info, &qry);
break;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 2/5] ARM: Add Support for Marvell Pantheon Familiy SoCs

2011-01-25 Thread Lei Wen
Hi Wolfgang,

On Wed, Jan 26, 2011 at 5:32 AM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message <1294632087-8025-3-git-send-email-lei...@marvell.com> you wrote:
>> Pantheon Family processors are highly integrated SoCs
>> based on Sheeva_88SV331x-v5 PJ1 cpu core.
>> Ref:
>> http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf
>>
>> SoC versions Supported:
>> 1) PANTHEON920          (TD)
>> 2) PANTHEON910          (TTC)
>>
>> Signed-off-by: Lei Wen 
> ...
>> +int dram_init(void)
>> +{
> ...
>> +     for (; i < CONFIG_NR_DRAM_BANKS; i++) {
>> +             /* If above loop terminated prematurely, we need to set
>> +              * remaining banks' start address & size as 0. Otherwise other
>> +              * u-boot functions and Linux kernel gets wrong values which
>> +              * could result in crash */
>
> Incorrect multiline comment style.
>

This already fix in the v6 patch...
http://patchwork.ozlabs.org/patch/80305/

>> +/* For preventing risk of instability in reading counter value,
>> + * first set read request to register cvwr and then read same
>> + * register after it captures counter value.
>> + */
>
> Ditto.  Please fix globally.
>
>> +     writel(COUNT_RD_REQ, &panthtimers->cvwr);
>> +     while (loop--);
>
> Please write:
>
>        while (loop--)
>                ;

Fixed...
>
> But then - are you sure the compiler does not optimize this out?  You
> probably want to use __udelay() instead.

From the practice, we think this loop is enough to make timer stablize...
Involve the __udelay() may not suitable for the timer functions...

>
> ...
>> --- /dev/null
>> +++ b/arch/arm/include/asm/arch-pantheon/config.h
>> @@ -0,0 +1,44 @@
> ...
>> +/*
>> + * There is no internal RAM in ARMADA100, using DRAM
>> + * TBD: dcache to be used for this
>> + */
>> +#define CONFIG_SYS_INIT_SP_ADDR              (CONFIG_SYS_TEXT_BASE - 
>> 0x0020)
>> +#define CONFIG_NR_DRAM_BANKS_MAX     2
>
> This looks like board specific code that should not be here.

Yep... I would update the patch for it. For V7...

>
> ...
>> +struct panthmpmu_registers {
>> +     u8 pad0[0x0024];
>> +     u32 ccgr;       /*0x0024*/
>> +     u8 pad1[0x0200 - 0x024 - 4];
>> +     u32 wdtpcr;     /*0x0200*/
>> +     u8 pad2[0x1020 - 0x200 - 4];
>> +     u32 aprr;       /*0x1020*/
>> +     u32 acgr;       /*0x1024*/
>> +};
>
> Please use TAB for vertical alignment of variable names.  Please fix
> globally.

In V6 patch , I think I already do like using tab. :)


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


Re: [U-Boot] [PATCH 1/1] lcd: align fb writing address for horizontal display offset

2011-01-25 Thread Liu Ying-B17645
Hello,

I sent the following patch for view about 2 weeks ago and haven't got any 
comment till now.
Could anyone help to give comments? Thanks.


Best Regards,
Liu Ying
-Original Message-
From: Liu Ying-B17645 
Sent: Tuesday, January 11, 2011 3:30 PM
To: u-boot@lists.denx.de
Cc: Liu Ying-B17645
Subject: [U-Boot][PATCH 1/1] lcd: align fb writing address for horizontal 
display offset

CONFIG_SPLASH_SCREEN_ALIGN makes uboot support display offset for splashimage. 
The framebuffer writing address should be calculated according to different 
kinds of framebuffer pixel format, i.e., bits per pixel value.

Signed-off-by: Liu Ying 
---
 common/lcd.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c index d854c21..0555ab4 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -731,7 +731,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
 
bmap = (uchar *)bmp + le32_to_cpu (bmp->header.data_offset);
fb   = (uchar *) (lcd_base +
-   (y + height - 1) * lcd_line_length + x);
+   (y + height - 1) * lcd_line_length + x * bpix / 8);
 
switch (bmp_bpix) {
case 1: /* pass through */
--
1.6.3.3


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


Re: [U-Boot] SteppingStone

2011-01-25 Thread Cunsuo Guo
2011/1/26 Matt Johnson 

> Hello.
>
> I have a custom board with a Samsung s3c2410 (arm920t) processor.  I have
> been unable to get the main branch of u-boot to work with this board.
> However, I have been successful with the old OpenMoko fork.  (I believe it
> is because of the "SteppingStone" microcode. See
> http://wiki.openmoko.org/wiki/S3C2410_Steppingstone if you're unfamiliar.)


> I'd prefer to use the main branch, because the OpenMoko fork is old and
> unmaintained.  The OpenMoko project abandoned u-boot some time ago, in
> favor
> of their "Qi" bootloader.
>
> Has anyone looked at merging the SteppingStone code back in to the main
> branch?  Is there some other workaround that is unclear to me?
>
> Are there other bootloaders that support SteppingStone that I could try?
> I'm looking for something as full-featured as u-boot, but actively
> maintained. The only other that I've found is Vivi - which is super
> ancient.
> Any advice is appreciated.


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


Steppingstone is just a 4KBytes buffer which works together with some kinda
HW mechanism to copy the first 4KBytes of NAND to it. IMH, you can just
treat it as a feature provided by S3C2410 to support NAND boot. If you have
NOR flash in th board, you can simply boot from NOR flash and ignore this
feature.
I'm not sure whether there is some patches to support this feature or not,
if not, may be you could provide one. The following is my advice to
implement NAND boot for S3C2410:
1. write your NAND device driver, simply read operation is OK;
2. in the relocation part in  Start.S, read code from NAND to RAM use your
NAND device driver, and make sure the relocation part is in the very
beginning 4KBytes range of NAND (by Loader script). In this way, the
first 4KBytes in NAND will be read into Steppingstone buffer and executed,
after execution of relocation code, your bootloader code will be read into
RAM, and then the code can be executed in RAM, the full bootup procedure is
over.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] cfi fix for Spansion and MB->MiB

2011-01-25 Thread Andrew Dyer
On Tue, Jan 25, 2011 at 19:56, Aaron Williams
 wrote:
> I ran into a problem with the Spansion S29GL064N flash chip in that it returns
> a manufacturer ID of 0 and it also requires the AMD geometry fixup.
>
> Additionally, I modified a few print statements to use KiB/MiB instead of
> kB/MB.
>
> -Aaron Williams
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index dd394a8..105eb3f 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1162,10 +1162,10 @@ void flash_print_info (flash_info_t * info)
>                info->name,
>                (info->portwidth << 3), (info->chipwidth << 3));
>        if (info->size < 1024*1024)
> -               printf ("  Size: %ld kB in %d Sectors\n",
> +               printf ("  Size: %ld KiB in %d Sectors\n",
>                        info->size >> 10, info->sector_count);
>        else
> -               printf ("  Size: %ld MB in %d Sectors\n",
> +               printf ("  Size: %ld MiB in %d Sectors\n",
>                        info->size >> 20, info->sector_count);
>        printf ("  ");
>        switch (info->vendor) {
> @@ -1924,6 +1924,7 @@ ulong flash_get_size (phys_addr_t base, int banknum)
>
>                /* Do manufacturer-specific fixups */
>                switch (info->manufacturer_id) {
> +               case 0x:
>                case 0x0001:
>                        flash_fixup_amd(info, &qry);
>                        break;

I think something is wrong here.  You shouldn't get a manufacturer ID
of  from a Spansion part.  cmdset_amd_read_jedec_ids() should be
where it's coming from, reading the datasheet is pretty clear that
these parts return an 0001 or 01 depending on the BYTE# pin.  I've
used other parts in the series GL128N, GL256N, GL256P that have the
same command set and not seen this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2011-01-25 Thread Kumar Gala

On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:

> Dear Scott Wood,
> 
> In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you wrote:
>> 
>> Do you have a simpler way to do this?  Note that for any board that
> 
> e009cde   powerpc: Fix FPU post related link warnings
> 
> ?
> 
>>> given the fact that there are
>>> no intentions to work with floating point data in U-Boot?
>> 
>> FPU POST doesn't count?
> 
> No, it does not count, because it is a very special situation where
> we are executing instructions that are guaranteed to be never used in
> any real code in U-Boot.
> 
>> Or are you saying FPU POST should be removed?
> 
> Of course not.

I thank you all, as I've enjoyed this thread for something we've just fixed :)

- k

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


[U-Boot] [PATCH 1/2] powerpc/85xx: Remove DATARATE_*_MHZ defines in static ddr init

2011-01-25 Thread Kumar Gala
Rather than having #defines DATARATE_*_MHZ, lets just match what we do on
the SPD code and convert the DDR frequency into MHZ and just compare
with a constant.

Based on patch from Poonam Aggrwal.

Signed-off-by: Kumar Gala 
---
 board/freescale/corenet_ds/ddr.c |   14 --
 board/freescale/corenet_ds/p4080ds_ddr.c |   24 +---
 board/freescale/p1_p2_rdb/ddr.c  |   25 +++--
 3 files changed, 28 insertions(+), 35 deletions(-)

diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index 6660b01..4c30657 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -31,19 +31,21 @@ extern fixed_ddr_parm_t fixed_ddr_parm_1[];
 phys_size_t fixed_sdram(void)
 {
int i;
-   sys_info_t sysinfo;
char buf[32];
fsl_ddr_cfg_regs_t ddr_cfg_regs;
phys_size_t ddr_size;
unsigned int lawbar1_target_id;
+   ulong ddr_freq, ddr_freq_mhz;
+
+   ddr_freq = get_ddr_freq(0);
+   ddr_freq_mhz = ddr_freq / 100;
 
-   get_sys_info(&sysinfo);
printf("Configuring DDR for %s MT/s data rate\n",
-   strmhz(buf, sysinfo.freqDDRBus));
+   strmhz(buf, ddr_freq));
 
for (i = 0; fixed_ddr_parm_0[i].max_freq > 0; i++) {
-   if ((sysinfo.freqDDRBus > fixed_ddr_parm_0[i].min_freq) &&
-  (sysinfo.freqDDRBus <= fixed_ddr_parm_0[i].max_freq)) {
+   if ((ddr_freq_mhz > fixed_ddr_parm_0[i].min_freq) &&
+  (ddr_freq_mhz <= fixed_ddr_parm_0[i].max_freq)) {
memcpy(&ddr_cfg_regs,
fixed_ddr_parm_0[i].ddr_settings,
sizeof(ddr_cfg_regs));
@@ -53,7 +55,7 @@ phys_size_t fixed_sdram(void)
 
if (fixed_ddr_parm_0[i].max_freq == 0)
panic("Unsupported DDR data rate %s MT/s data rate\n",
-   strmhz(buf, sysinfo.freqDDRBus));
+   strmhz(buf, ddr_freq));
 
ddr_size = (phys_size_t) CONFIG_SYS_SDRAM_SIZE * 1024 * 1024;
ddr_cfg_regs.ddr_cdr1 = DDR_CDR1_DHC_EN;
diff --git a/board/freescale/corenet_ds/p4080ds_ddr.c 
b/board/freescale/corenet_ds/p4080ds_ddr.c
index 4ad89ff..ccb9da8 100644
--- a/board/freescale/corenet_ds/p4080ds_ddr.c
+++ b/board/freescale/corenet_ds/p4080ds_ddr.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2009-2010 Freescale Semiconductor, Inc.
+ * Copyright 2009-2011 Freescale Semiconductor, Inc.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -9,12 +9,6 @@
 #include 
 #include 
 
-#define DATARATE_800MHZ8
-#define DATARATE_900MHZ9
-#define DATARATE_1000MHZ   10
-#define DATARATE_1200MHZ   12
-#define DATARATE_1300MHZ   13
-
 #define CONFIG_SYS_DDR_TIMING_3_1200   0x0103
 #define CONFIG_SYS_DDR_TIMING_0_1200   0xCC550104
 #define CONFIG_SYS_DDR_TIMING_1_1200   0x868FAA45
@@ -340,17 +334,17 @@ fsl_ddr_cfg_regs_t ddr_cfg_regs_1200_2nd = {
 };
 
 fixed_ddr_parm_t fixed_ddr_parm_0[] = {
-   {DATARATE_800MHZ, DATARATE_900MHZ, &ddr_cfg_regs_800},
-   {DATARATE_900MHZ, DATARATE_1000MHZ, &ddr_cfg_regs_900},
-   {DATARATE_1000MHZ, DATARATE_1200MHZ, &ddr_cfg_regs_1000},
-   {DATARATE_1200MHZ, DATARATE_1300MHZ, &ddr_cfg_regs_1200},
+   {800, 900, &ddr_cfg_regs_800},
+   {900, 1000, &ddr_cfg_regs_900},
+   {1000, 1200, &ddr_cfg_regs_1000},
+   {1200, 1300, &ddr_cfg_regs_1200},
{0, 0, NULL}
 };
 
 fixed_ddr_parm_t fixed_ddr_parm_1[] = {
-   {DATARATE_800MHZ, DATARATE_900MHZ, &ddr_cfg_regs_800_2nd},
-   {DATARATE_900MHZ, DATARATE_1000MHZ, &ddr_cfg_regs_900_2nd},
-   {DATARATE_1000MHZ, DATARATE_1200MHZ, &ddr_cfg_regs_1000_2nd},
-   {DATARATE_1200MHZ, DATARATE_1300MHZ, &ddr_cfg_regs_1200_2nd},
+   {800, 900, &ddr_cfg_regs_800_2nd},
+   {900, 1000, &ddr_cfg_regs_900_2nd},
+   {1000, 1200, &ddr_cfg_regs_1000_2nd},
+   {1200, 1300, &ddr_cfg_regs_1200_2nd},
{0, 0, NULL}
 };
diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/p1_p2_rdb/ddr.c
index e54fde2..fbc46b1 100644
--- a/board/freescale/p1_p2_rdb/ddr.c
+++ b/board/freescale/p1_p2_rdb/ddr.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2009, 2011 Freescale Semiconductor, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -33,11 +33,6 @@ DECLARE_GLOBAL_DATA_PTR;
 extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
   unsigned int ctrl_num);
 
-#define DATARATE_400MHZ 4
-#define DATARATE_533MHZ 5
-#define DATARATE_667MHZ 6
-#define DATARATE_800MHZ 8
-
 #define CONFIG_SYS_DDR_CS0_BNDS0x003

[U-Boot] [PATCH 2/2] powerpc/85xx: Declare fsl_ddr_set_memctl_regs in

2011-01-25 Thread Kumar Gala
Remove declerations of fsl_ddr_set_memctl_regs in board files with and
place it into a common header.

Based on patch from Poonam Aggrwal.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/include/asm/fsl_ddr_sdram.h |2 ++
 board/freescale/corenet_ds/ddr.c |3 ---
 board/freescale/p1_p2_rdb/ddr.c  |3 ---
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_ddr_sdram.h 
b/arch/powerpc/include/asm/fsl_ddr_sdram.h
index 852e5c3..73bc023 100644
--- a/arch/powerpc/include/asm/fsl_ddr_sdram.h
+++ b/arch/powerpc/include/asm/fsl_ddr_sdram.h
@@ -266,6 +266,8 @@ typedef struct memctl_options_s {
 
 extern phys_size_t fsl_ddr_sdram(void);
 extern int fsl_use_spd(void);
+extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
+   unsigned int ctrl_num);
 
 /*
  * The 85xx boards have a common prototype for fixed_sdram so put the
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index 4c30657..fb53946 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -16,9 +16,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
-  unsigned int ctrl_num);
-
 
 /*
  * Fixed sdram init -- doesn't use serial presence detect.
diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/p1_p2_rdb/ddr.c
index fbc46b1..44faec3 100644
--- a/board/freescale/p1_p2_rdb/ddr.c
+++ b/board/freescale/p1_p2_rdb/ddr.c
@@ -30,9 +30,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
-  unsigned int ctrl_num);
-
 #define CONFIG_SYS_DDR_CS0_BNDS0x003F
 #define CONFIG_SYS_DDR_CS0_CONFIG  0x80014202
 #define CONFIG_SYS_DDR_CS0_CONFIG_20x
-- 
1.7.2.3

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


[U-Boot] [PATCH 1/5] powerpc/85xx: Enable Errata command on MPC8572DS

2011-01-25 Thread Kumar Gala
From: York Sun 

Also removed duplicate CONFIG_CMD_IRQ define.

Signed-off-by: York Sun 
Signed-off-by: Kumar Gala 
---
 include/configs/MPC8572DS.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h
index e6b60cf..8f333a6 100644
--- a/include/configs/MPC8572DS.h
+++ b/include/configs/MPC8572DS.h
@@ -654,12 +654,12 @@
  */
 #include 
 
+#define CONFIG_CMD_ERRATA
 #define CONFIG_CMD_IRQ
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_I2C
 #define CONFIG_CMD_MII
 #define CONFIG_CMD_ELF
-#define CONFIG_CMD_IRQ
 #define CONFIG_CMD_SETEXPR
 #define CONFIG_CMD_REGINFO
 
-- 
1.7.2.3

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


[U-Boot] [PATCH 2/5] powerpc/85xx: Remove unnecessary polling loop from DDR init

2011-01-25 Thread Kumar Gala
From: York Sun 

This polling loop is not required normally, unless specifically stated in
workaround.

Signed-off-by: York Sun 
Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/ddr-gen3.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c 
b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
index fa7e09f..b9502f7 100644
--- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
+++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
@@ -199,8 +199,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
temp_sdram_cfg = in_be32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI;
out_be32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
asm volatile("sync;isync");
-   while (!(in_be32(&ddr->debug[1]) & 0x2))
-   ;
 
/* Poll DDR_SDRAM_CFG_2[D_INIT] bit until auto-data init is done.  */
while (in_be32(&ddr->sdram_cfg_2) & 0x10) {
-- 
1.7.2.3

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


[U-Boot] [PATCH 3/5] powerpc/85xx: Rename MPC8572 DDR erratum to DDR115

2011-01-25 Thread Kumar Gala
From: York Sun 

Use unique erratum number instead of platform number.
Enable command that reports errata on MPC8572DS.

Signed-off-by: York Sun 
Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/cmd_errata.c |4 +++-
 arch/powerpc/cpu/mpc85xx/ddr-gen3.c   |2 +-
 arch/powerpc/include/asm/config_mpc85xx.h |1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c 
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 0cc8b1e..94a5876 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -71,7 +71,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 #ifdef CONFIG_SYS_FSL_ERRATUM_DDR_A003
puts("Work-around for Erratum DDR-A003 enabled\n");
 #endif
-
+#ifdef CONFIG_SYS_FSL_ERRATUM_DDR_115
+   puts("Work-around for Erratum DDR115 enabled\n");
+#endif
return 0;
 }
 
diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c 
b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
index b9502f7..35997f2 100644
--- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
+++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
@@ -178,7 +178,7 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
 * when operatiing in 32-bit bus mode with 4-beat bursts,
 * This erratum does not affect DDR3 mode, only for DDR2 mode.
 */
-#ifdef CONFIG_MPC8572
+#ifdef CONFIG_SYS_FSL_ERRATUM_DDR_115
if in_be32(&ddr->sdram_cfg) >> 24) & 0x7) == SDRAM_TYPE_DDR2)
&& in_be32(&ddr->sdram_cfg) & 0x8) {
/* set DEBUG_1[31] */
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 7a0af37..8ef9743 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -77,6 +77,7 @@
 #define CONFIG_MAX_CPUS2
 #define CONFIG_SYS_FSL_NUM_LAWS12
 #define CONFIG_SYS_FSL_SEC_COMPAT  2
+#define CONFIG_SYS_FSL_ERRATUM_DDR_115
 
 #elif defined(CONFIG_P1010)
 #define CONFIG_MAX_CPUS1
-- 
1.7.2.3

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


  1   2   >